[reSIProcate] bug in SipFrag.cxx
Kath, Heiner
heiner.kath at swyx.com
Thu Aug 31 11:21:19 CDT 2006
Hi,
I found this in SipFrag.cxx:
void
SipFrag::parse(ParseBuffer& pb)
{
// DebugLog(<< "SipFrag::parse: " << pb.position());
mMessage = new SipMessage();
pb.assertNotEof();
const char *constBuffer = pb.position();
char *buffer = const_cast<char *>(constBuffer);
size_t size = pb.end() - pb.position();
// !ah! removed size check .. process() cannot process more
// than size bytes of the message.
MsgHeaderScanner msgHeaderScanner;
msgHeaderScanner.prepareForFrag(mMessage, hasStartLine(buffer,
size));
enum { sentinelLength = 4 }; // Two carriage return / line feed
pairs.
char saveTermCharArray[sentinelLength];
char *termCharArray = buffer + size;
saveTermCharArray[0] = termCharArray[0];
saveTermCharArray[1] = termCharArray[1];
saveTermCharArray[2] = termCharArray[2];
saveTermCharArray[3] = termCharArray[3];
termCharArray[0] = '\r';
termCharArray[1] = '\n';
termCharArray[2] = '\r';
termCharArray[3] = '\n';
char *scanTermCharPtr;
MsgHeaderScanner::ScanChunkResult scanChunkResult =
msgHeaderScanner.scanChunk(buffer,
size + sentinelLength,
&scanTermCharPtr);
termCharArray[0] = saveTermCharArray[0];
termCharArray[1] = saveTermCharArray[1];
termCharArray[2] = saveTermCharArray[2];
termCharArray[3] = saveTermCharArray[3];
The problem with this code is that the sentinel is wrote *behind* the
ParseBuffer. If the ParseBuffer stands at the very end of an allocated
buffer, this code writes 4 bytes behind it. So it happened in our
application. As a consequence a further allocation of memory inside of
scanChunk() failed - probably because some administration information of
the memory heap was overwritten.
I can easily reproduce this using the gflags tool of the Mircosoft
debugging tools.
My solution consists in allocating a new buffer that has the required
size (+4), copying the content of the ParseBuffer to it. The new buffer
is referenced by the SipFrag object and is freed on destruction of the
latter. It is up to the resip-pro's to find a smarter solution.
I like resip :-)
Heiner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060831/ed8eeacc/attachment.htm>
More information about the resiprocate-devel
mailing list