[Serdev] [BUG] Closed: (SER-53) Possible memory corruption when dst_uri changes in a cloned message

[Andrei Pelinescu - Onciul (JIRA)]

     [ http://bugs.sip-router.org/browse/SER-53?page=history ]
     
Andrei Pelinescu - Onciul closed SER-53:
----------------------------------------

     Resolution: Fixed
    Fix Version: 0.9.4

fixed on HEAD and rel_0_9_0:
http://lists.iptel.org/pipermail/serdev/2005-September/005487.html

> Possible memory corruption when dst_uri changes in a cloned message
> -------------------------------------------------------------------
>
>          Key: SER-53
>          URL: http://bugs.sip-router.org/browse/SER-53
>      Project: SIP Express Router
>         Type: Bug
>   Components: tm
>     Versions: 0.9.3, 0.8.14, HEAD
>  Environment: white box linux 3
>     Reporter: Phil D'Amore
>     Assignee: Andrei Pelinescu - Onciul
>      Fix For: HEAD, 0.9.4
>  Attachments: sip_router-msg_clone_dst_uri.patch
>
> I noticed the following happening in a scenario where we are doing serial forking:
> PROCESS_A send the first message
> 1.  the dst_uri in the message structure is set by a call to lookup("location") in the config
> 2.  the message is cloned using sip_msg_cloner so it can be saved in the transaction's request field.
> 2a. sip_msg_cloner copies the message structure, including the dst_uri pointer.  The dst_uri pointer is left at its original value.
> PROCESS_B catches the reply, sends the second request to a new destination
> 3.  retrieves the saved request from the transaction
> 4.  lookup("location") is called again for the new request uri, which calls set_dst_uri again
> 5.  set_dst_uri sees that the dst_uri.s pointer is set and the len is > the new dst_uri, so it "re-uses" the memory
> Trouble in 5 is that this is different memory since it is a different process, so when set_dst_uri writes the new dst_uri, it clobbers another process' memory.  This is also a problem is PROCESS_A and PROCESS_B are the same, because the memory pointed to by dst_uri has already been freed when the original message (the one from which the clone was made) is cleaned up.
> This was causing all sorts of unpredictable behavior for us, including core dumps thanks to the memory debugging code calling abort() when one of the corrupted fragments was re-referenced.
> The patch attached takes the cautious approach of handling dst_uri the same as new_uri, making a copy of it in the shared memory of the clone.  I'm not sure if this is needed, or it would suffice to just zero out that pointer so later calls to set_dst_uri don't try to "re-use" the memory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://bugs.sip-router.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira