< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

[reSIProcate] bug in SipFrag.cxx


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