Re: [reSIProcate] resiprocate crash due to no free memory when receiving sip message with large header

[Alan Hawrylyshen <alan@xxxxxxxxxxxx>]

On Jul 10, 2008, at 06:38 , Markus Eriksson wrote:

In the failing case the header is >1MB, so there will be approximately 500 buffers in the SipMessage containing part of the large header.

This doesn't sound quite right, but in theory we do not let a header span buffers, so there will be a buffer that ends up being large enough for that header. 

SIP (the specification) does not have a  maximum header size defined, nor is there a maximum message size. I think it would be reasonable to incorporate soft-limits in reSIProcate, but I am not in favor of modifying the stack with a hard coded limit. We've seen applications that use chunkLengths > 50K legitimately.

What I want to know is why the buffers are given to the SipMessage in this way. I could not even find a place where the buffers stored in SipMessage was actually used.

As per Byron's message, they are used  by the Message Header Scanner (formerly Preparser) to build a table of pointers to the header field values. (The buffers are what the header fields 'point at'.) If left un changed,this prevents the  need to parse and store these headers in a more semantic (vs syntactic) form.

What I did to "fix" this is I check if chunkLength (buffer size) is bigger than 50kb. If so, the header is too big and the connection is dropped.

See above -- a good workaround locally, but not a great fix for the project. I think we should make this configurable and off by default.

Someone with more in-depth knowledge of how the pre-parser works and what it is meant to do, should probably fix the memory leak properly though. If a header is just big enough so that the last allocation succeeds, the SipMessage would end up owning buffers that has allocated all your memory and something else could crash from a failed allocation.

Thanks for pointing this out.

Alan Hawrylyshen