[ http://nagoya.apache.org/jira/browse/XERCESC-1319?page=comments#action_57102 ] Alberto Massari commented on XERCESC-1319: ------------------------------------------
Hi Alex, the file you are looking at seems to come from the old directory structure (src/util/Transcoders) instead of the new one (src/xercesc/util/Transcoders). Have a look at the current version (rev. 1.16, tag Xerces-C_2_6_0) available from http://cvs.apache.org/viewcvs.cgi/xml-xerces/c/src/xercesc/util/Transcoders/ICU/ICUTransService.cpp?rev=1.16&view=markup Alberto > Buffer overflow in ICULCPTranscoder::transcode > ---------------------------------------------- > > Key: XERCESC-1319 > URL: http://nagoya.apache.org/jira/browse/XERCESC-1319 > Project: Xerces-C++ > Type: Bug > Components: Utilities > Environment: All Platforms > Reporter: Alex R. Herbstritt > Attachments: saxbug01cz.xml > > I have found a bug in the transcoder code when transcoding from UTF-16 to > UTF-8. We use Xerces against an in house library so I cannot include the code > that reproduces the bug. But the bug has been reproduced on Windows and > HPUX32. Instead I will give the details of the bug - along with the fix. > The bug is a buffer over run that happens in a very special case. The fix for > it is very simple. I find it hard to believe that nobody has seen this bug > before. > The problem is located in the file > xercesc/util/Transcoders/ICU/ICUTranService.cpp > in the method > XMLCh* ICULCPTranscoder::transcode(const char* const toTranscode) > with the function call ucnv_fromUChars: > targetCap = ucnv_fromUChars > ( > fConverter > , retBuf > , targetLen + 1 > , actualSrc > , -1 > , &err > ); > This is the function that is doing the actual conversion. The problem is with > the "targetLen + 1" - this should be replaced with "targetLen". (Note that > the call that follows has "targetCap", not "targetCap + 1".) > The problem is that ucnv_fromUChars can fill the buffer up, including the > space held for the null term. That is, targetCap is returned equaling > targetLen+1, along with a U_STRING_NOT_TERMINATED_WARNING. This is all fine, > until the end of the method where, > // Cap it off and return > retBuf[targetCap] = 0; > return retBuf; > will place the null term outside of the buffer. That is, we should never let > targetCap be larger than targetLen. (The buffer overflow will only happen > when targetCap==targetLen+1.) > Replacing "targetLen + 1" with "targetLen" results in a > U_BUFFER_OVERFLOW_ERROR. This is correct, because in the overflow case the > problem is that the new string created is one byte longer than the buffer > that was allocated. So we want the error to cause a new buffer to be > allocated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
