[OpenSIPS-Devel] [ opensips-Bugs-2868113 ] crash in encode_contact

Wed Sep 30 14:15:00 CEST 2009

Bugs item #2868113, was opened at 2009-09-27 17:04
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2868113&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sergey Okhapkin (sokhapkin)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: crash in encode_contact

Initial Comment:
if (is_method("INVITE")) {
       encode_contact("enc_prefix","IP.Add.re.ss");

leads to

CRITICAL:core:del_lump: offset exceeds message size (653092 > 1031) aborting...

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-09-30 15:14

Message:
OK, I made a fix to detect such cases and to avoid the crash - you will get
an error message in the logs that you are doing something wrong in the
script.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Sergey Okhapkin (sokhapkin)
Date: 2009-09-28 18:27

Message:
I agree with both sentences :-)

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-09-28 17:57

Message:
actually is more a bug in your script - do you want to replace the contact
with the net ip (via fixed_nated_contact) or do you want to encode it?

Of course, whatever you want to do, it showed not crash opensips :D..

regards,
bogdan

----------------------------------------------------------------------

Comment By: Sergey Okhapkin (sokhapkin)
Date: 2009-09-28 16:44

Message:
Sounds like a bug in fix_nated_contact(), it shouldn't set c->uri.s
pointing outside msg->buf, the check for "fix_nated_contact twice" is just
a workaround for the bug.

----------------------------------------------------------------------

Comment By: Sergey Okhapkin (sokhapkin)
Date: 2009-09-28 16:33

Message:
Yes, I do... Nice catch...

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-09-28 16:27

Message:
are you doing a fix_nated_contact() op before the mangling? 

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Sergey Okhapkin (sokhapkin)
Date: 2009-09-28 14:29

Message:
It's outside:

(gdb) fr 5
#5  0xb775b577 in encode_contact (msg=0x8237ecc, encoding_prefix=0x81fe644
"enc_prefix", public_ip=0x81fe6f4 "38.99.108.126")
    at contact_ops.c:99
99                                      if (patch (msg, uri.s, uri.len,
newUri.s, newUri.len) < 0)
(gdb) p msg->buf
$1 = 0x8199280 "INVITE sip:18004444444 at tf.callwithus.com:5070
SIP/2.0\r\nVia: SIP/2.0/UDP
192.168.1.2:5066;rport;branch=z9hG4bKtvuncyid\r\nMax-Forwards:
69\r\nProxy-Authorization: Digest
username=\"167147511\",realm=\"tf.call"...
(gdb) p msg->len
$2 = 1030
(gdb) p uri.s
$3 = 0x82389a4 "sip:7323775277 at 71.59.87.156:5066;transport=udp"

I'm getting error on the following event sequence: INVITE (without auth)
-> 407 -> INVITE (with auth).

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-09-28 11:30

Message:
not really....The parser in OpenSIPS is keeping references inside the
buffer (for the parsed stuff), so the cb->contacts->uri.s should point
inside the buffer,

Try printing the following vals:
    msg->buf
    msg->len
    uri.s

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Sergey Okhapkin (sokhapkin)
Date: 2009-09-28 00:59

Message:
I found the root cause, functions patch and del_lump expect that patch()
parameter oldstr points into inside msg->buf, but in

cb = (contact_body_t *) msg->contact->parsed;
c = cb->contacts;
uri = c->uri;

uri.s is outside msg->buf

----------------------------------------------------------------------

Comment By: Sergey Okhapkin (sokhapkin)
Date: 2009-09-27 23:58

Message:
I can't reproduce it with a simple script. gdb shows

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e1c101 in raise () from /lib/libc.so.6
#2  0xb7e1d8e8 in abort () from /lib/libc.so.6
#3  0x08064589 in del_lump (msg=0x8237ecc, offset=653092, len=46,
type=HDR_OTHER_T) at data_lump.c:292
#4  0xb775ed64 in patch (msg=0x6, oldstr=0x82389a4
"sip:7323775277 at 71.59.87.156:5066;transport=udp", oldlen=46,
    newstr=0x823a36c
"sip:enc_prefix*7323775277**71.59.87.156*5066*udp at 38.99.108.126",
newlen=62) at utils.c:53
#5  0xb775b577 in encode_contact (msg=0x8237ecc, encoding_prefix=0x81fe644
"enc_prefix", public_ip=0x81fe6f4 "38.99.108.126")
    at contact_ops.c:99
#6  0x0805631d in do_action (a=0x81fe7a4, msg=0x8237ecc) at action.c:962
#7  0x080590b7 in run_action_list (a=0x81fe7a4, msg=0x8237ecc) at
action.c:139
#8  0x0805728c in do_action (a=0x82160ac, msg=0x8237ecc) at action.c:706
#9  0x080590b7 in run_action_list (a=0x81f8110, msg=0x8237ecc) at
action.c:139
#10 0x08059453 in run_top_route (a=0x81f8110, msg=0x8237ecc) at
action.c:119
#11 0x080a0cfa in receive_msg (
    buf=0x8199280 "INVITE sip:18004444444 at tf.callwithus.com:5070
SIP/2.0\r\nVia: SIP/2.0/UDP
192.168.1.2:5066;rport;branch=z9hG4bKtvuncyid\r\nMax-Forwards:
69\r\nProxy-Authorization: Digest
username=\"167147511\",realm=\"tf.call"..., len=1030,
    rcv_info=0xbfe40ae4) at receive.c:162
#12 0x080e8ebc in udp_rcv_loop () at udp_server.c:492
#13 0x08072c1b in main (argc=1, argv=0xbfe40ce4) at main.c:711

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-09-27 23:35

Message:
Does this crash happens all the time? what is the way to reproduce it as I
tried a simple script but with no luck.

Also did you get a corefile after the crash?

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2868113&group_id=232389