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

[Alan Hawrylyshen]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080710/e7d89d7b/attachment.htm>