[ http://nagoya.apache.org/jira/browse/XERCESC-1319?page=comments#action_57103 ] Alex R. Herbstritt commented on XERCESC-1319: ---------------------------------------------
Ah! Excellent - Thank you. So my bug is a DUP. I am actually using the XML4C version 5.2.0 - which is Xerces 2.2. I obviously can't figure out the Apache CVS. I see now that the bug I noticed was fixed with version 1.11 of ICUTransService.cpp (Xerces 2.4.0). Issue http://nagoya.apache.org/jira/browse/XERCESC-964 It is interesting that they chose to make the fix this way. Since Xerces was going to be null terming it anyway they could have just ignored the warning - and left the code the way that it was with the targetLen (not targetLen+1) passed in, as I recommended above. Now the other bug mentioned above can happen - i.e. the second time around it gets no null term. It might be a good idea to make my change instead - better safe than sorry. And go back to null terming it in Xerces for good measure. That is put back in the null term at the end and leave the targetCap (not targetCap+1) being passed, i.e. not the change recommended by http://nagoya.apache.org/jira/browse/XERCESC-1300. If we are sure that ICU will null term it every time when it is passed the extra byte (targetCap+1) then I guess the two fixes are the same. Sorry about the mess up with the CVS. Also, sorry about the DUP. I don't know why I couldn't find the previous bug. I guess that I am inept with Jira as well. -- Alex > 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]
