2 Sep
2010
2 Sep
'10
5:27 p.m.
Hi,
I'm using kamailio 1.5.4-notls and I'm experimenting crashes when an UAC
sends an INVITE with a content-length greater then the effective body
length.
The error messages written on the logs is:
CRITICAL:core:del_lump: offset exceeds message size (1266 > 1161)
aborting...
and this is the backtrace of the generated core file:
#0 0x00002ad718ab307b in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00002ad718ab307b in raise () from /lib/libc.so.6
#1 0x00002ad718ab484e in abort () from /lib/libc.so.6
#2 0x0000000000418f53 in del_lump (msg=0x66de00, offset=1266, len=12,
type=HDR_OTHER_T) at data_lump.c:292
#3 0x00002ad71a8145ba in alter_mediaip (msg=0x66de00, body=<value optimized
out>, oldip=0x7fff81fe6700, oldpf=<value optimized out>,
newip=0x7fff81fe66e0, newpf=2, preserve=0)
at nathelper.c:1857
#4 0x00002ad71a821a3a in force_rtp_proxy (msg=0x66de00, str1=<value
optimized out>, str2=<value optimized out>, offer=<value optimized out>)
at
nathelper.c:2871
#5 0x00002ad71a8238df in rtpproxy_offer1_f (msg=0x66de00, str1=0x65f370
"cof", str2=<value optimized out>) at nathelper.c:2391
#6 0x000000000040cc5a in do_action (a=0x65f400, msg=0x66de00) at
action.c:874
#7 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#8 0x0000000000454155 in eval_expr (e=0x65f4d0, msg=0x66de00, val=0x0) at
route.c:1171
#9 0x0000000000453bd7 in eval_expr (e=0x65f518, msg=0x66de00, val=0x0) at
route.c:1488
#10 0x0000000000453b7f in eval_expr (e=0x65f560, msg=0x66de00, val=0x0) at
route.c:1493
#11 0x000000000040c4c9 in do_action (a=0x65ffe8, msg=0x66de00) at
action.c:729
#12 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#13 0x000000000040dbc9 in do_action (a=0x660528, msg=0x66de00) at
action.c:746
#14 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#15 0x000000000040dbc9 in do_action (a=0x6606c8, msg=0x66de00) at
action.c:746
#16 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#17 0x000000000040dac5 in do_action (a=0x656790, msg=0x66de00) at
action.c:120
#18 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#19 0x000000000040dbc9 in do_action (a=0x656860, msg=0x66de00) at
action.c:746
#20 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#21 0x000000000040dac5 in do_action (a=0x6560b0, msg=0x66de00) at
action.c:120
#22 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#23 0x000000000040f4f3 in run_top_route (a=0x64b870, msg=0x66de00) at
action.c:120
#24 0x0000000000444e90 in receive_msg (
buf=0x619a20 "INVITE sip:xxxxxxxx@xxxxxxxxxxxx SIP/2.0\r\nVia:
SIP/2.0/UDP
xxx.xxx.xxx.xxx:xxxx;branch=z9hG4bK-d8754z-24245342621eb55b-1---d8754z-;rport\r\nMax-Forwards:
69\r\nContact: <sip:xxxxxxxx@xxx.xxx.xxx.xxx"..., len=1161,
rcv_info=0x7fff81fe86e0) at receive.c:175
#25 0x0000000000479254 in udp_rcv_loop () at udp_server.c:449
#26 0x0000000000427237 in main (argc=7, argv=0x7fff81fe88e8) at main.c:774
I couldn't get to reproduce this behavior in my test development (it has
newer version of glibc) in which I only get the messages:
ERROR:core:anchor_lump: offset exceeds message size (1125 > 714)...
ERROR:nathelper:force_rtp_proxy: anchor_lump failed
Looking into nathelper code, extract_body function I found that the
body->len value is taken from Content-Length header, so i added the
following piece of code:
--- nhelpr_funcs.c.orig 2010-09-02 14:04:09.891649254 +0200
+++ nhelpr_funcs.c 2010-09-02 14:17:40.183747107 +0200
@@ -196,6 +196,12 @@
LM_ERR("message body has length zero\n");
goto error;
}
+
+ if (body->len + body->s > msg->buf + msg->len) {
+ LM_ERR("content-length exceeds packet-length by %d\n",
+ (body->len + body->s) - (msg->buf +
msg->len));
+ body->len=strlen(body->s);
+ }
/* no need for parse_headers(msg, EOH), get_body will
* parse everything */
This way if the Content-Length header is greater then the effective body
length body->len is corrected with the real value.
This solved for the moment, but I'm not sure if this is a good approach and
I still don't understand why in the test platform I cannot reproduce the
crash.
Regards,
Federico Cabiddu
7 Sep
7 Sep
9:17 p.m.
Hello,
have you tried with latest SVN branch 1.5?
The issue should have been solved by a commit couple of months ago:
http://openser.svn.sourceforge.net/viewvc/openser/branches/1.5/modules/nath…
If does not work with latest SVN, let us know.
Thanks,
Daniel
On 9/2/10 2:27 PM, federico cabiddu wrote:
Hi,
I'm using kamailio 1.5.4-notls and I'm experimenting crashes when an
UAC sends an INVITE with a content-length greater then the effective
body length.
The error messages written on the logs is:
CRITICAL:core:del_lump: offset exceeds message size (1266 > 1161)
aborting...
and this is the backtrace of the generated core file:
#0 0x00002ad718ab307b in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00002ad718ab307b in raise () from /lib/libc.so.6
#1 0x00002ad718ab484e in abort () from /lib/libc.so.6
#2 0x0000000000418f53 in del_lump (msg=0x66de00, offset=1266, len=12,
type=HDR_OTHER_T) at data_lump.c:292
#3 0x00002ad71a8145ba in alter_mediaip (msg=0x66de00, body=<value
optimized out>, oldip=0x7fff81fe6700, oldpf=<value optimized out>,
newip=0x7fff81fe66e0, newpf=2, preserve=0)
at nathelper.c:1857
#4 0x00002ad71a821a3a in force_rtp_proxy (msg=0x66de00, str1=<value
optimized out>, str2=<value optimized out>, offer=<value optimized
out>) at nathelper.c:2871
#5 0x00002ad71a8238df in rtpproxy_offer1_f (msg=0x66de00,
str1=0x65f370 "cof", str2=<value optimized out>) at nathelper.c:2391
#6 0x000000000040cc5a in do_action (a=0x65f400, msg=0x66de00) at
action.c:874
#7 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#8 0x0000000000454155 in eval_expr (e=0x65f4d0, msg=0x66de00,
val=0x0) at route.c:1171
#9 0x0000000000453bd7 in eval_expr (e=0x65f518, msg=0x66de00,
val=0x0) at route.c:1488
#10 0x0000000000453b7f in eval_expr (e=0x65f560, msg=0x66de00,
val=0x0) at route.c:1493
#11 0x000000000040c4c9 in do_action (a=0x65ffe8, msg=0x66de00) at
action.c:729
#12 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#13 0x000000000040dbc9 in do_action (a=0x660528, msg=0x66de00) at
action.c:746
#14 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#15 0x000000000040dbc9 in do_action (a=0x6606c8, msg=0x66de00) at
action.c:746
#16 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#17 0x000000000040dac5 in do_action (a=0x656790, msg=0x66de00) at
action.c:120
#18 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#19 0x000000000040dbc9 in do_action (a=0x656860, msg=0x66de00) at
action.c:746
#20 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#21 0x000000000040dac5 in do_action (a=0x6560b0, msg=0x66de00) at
action.c:120
#22 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#23 0x000000000040f4f3 in run_top_route (a=0x64b870, msg=0x66de00) at
action.c:120
#24 0x0000000000444e90 in receive_msg (
buf=0x619a20 "INVITE sip:xxxxxxxx@xxxxxxxxxxxx SIP/2.0\r\nVia:
SIP/2.0/UDP
xxx.xxx.xxx.xxx:xxxx;branch=z9hG4bK-d8754z-24245342621eb55b-1---d8754z-;rport\r\nMax-Forwards:
69\r\nContact: <sip:xxxxxxxx@xxx.xxx.xxx.xxx"..., len=1161,
rcv_info=0x7fff81fe86e0) at receive.c:175
#25 0x0000000000479254 in udp_rcv_loop () at udp_server.c:449
#26 0x0000000000427237 in main (argc=7, argv=0x7fff81fe88e8) at main.c:774
I couldn't get to reproduce this behavior in my test development (it
has newer version of glibc) in which I only get the messages:
ERROR:core:anchor_lump: offset exceeds message size (1125 > 714)...
ERROR:nathelper:force_rtp_proxy: anchor_lump failed
Looking into nathelper code, extract_body function I found that the
body->len value is taken from Content-Length header, so i added the
following piece of code:
--- nhelpr_funcs.c.orig 2010-09-02 14:04:09.891649254 +0200
+++ nhelpr_funcs.c 2010-09-02 14:17:40.183747107 +0200
@@ -196,6 +196,12 @@
LM_ERR("message body has length zero\n");
goto error;
}
+
+ if (body->len + body->s > msg->buf + msg->len) {
+ LM_ERR("content-length exceeds packet-length by %d\n",
+ (body->len + body->s) - (msg->buf +
msg->len));
+ body->len=strlen(body->s);
+ }
/* no need for parse_headers(msg, EOH), get_body will
* parse everything */
This way if the Content-Length header is greater then the effective
body length body->len is corrected with the real value.
This solved for the moment, but I'm not sure if this is a good
approach and I still don't understand why in the test platform I
cannot reproduce the crash.
Regards,
Federico Cabiddu
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
8 Sep
8 Sep
2:14 p.m.
Hi,
sorry I should have read better previous posts. I tried latest SVN branch
and it works.
My modification (which in fact was inspired by nhelper_funcs.c of release
3.0.3) differs in that if the content-length is greater then the effective
body length the latter is used. I recognize that this is not a good approach
even if it worked for my customer (which by the way is using Bria 2.2, that
sometimes sends incorrect content-length).
Thanks,
Federico
2010/9/7 Daniel-Constantin Mierla <miconda(a)gmail.com>
Hello,
have you tried with latest SVN branch 1.5?
The issue should have been solved by a commit couple of months ago:
http://openser.svn.sourceforge.net/viewvc/openser/branches/1.5/modules/nath…
If does not work with latest SVN, let us know.
Thanks,
Daniel
On 9/2/10 2:27 PM, federico cabiddu wrote:
Hi,
I'm using kamailio 1.5.4-notls and I'm experimenting crashes when an UAC
sends an INVITE with a content-length greater then the effective body
length.
The error messages written on the logs is:
CRITICAL:core:del_lump: offset exceeds message size (1266 > 1161)
aborting...
and this is the backtrace of the generated core file:
#0 0x00002ad718ab307b in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00002ad718ab307b in raise () from /lib/libc.so.6
#1 0x00002ad718ab484e in abort () from /lib/libc.so.6
#2 0x0000000000418f53 in del_lump (msg=0x66de00, offset=1266, len=12,
type=HDR_OTHER_T) at data_lump.c:292
#3 0x00002ad71a8145ba in alter_mediaip (msg=0x66de00, body=<value
optimized out>, oldip=0x7fff81fe6700, oldpf=<value optimized out>,
newip=0x7fff81fe66e0, newpf=2, preserve=0)
at nathelper.c:1857
#4 0x00002ad71a821a3a in force_rtp_proxy (msg=0x66de00, str1=<value
optimized out>, str2=<value optimized out>, offer=<value optimized out>)
at
nathelper.c:2871
#5 0x00002ad71a8238df in rtpproxy_offer1_f (msg=0x66de00, str1=0x65f370
"cof", str2=<value optimized out>) at nathelper.c:2391
#6 0x000000000040cc5a in do_action (a=0x65f400, msg=0x66de00) at
action.c:874
#7 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#8 0x0000000000454155 in eval_expr (e=0x65f4d0, msg=0x66de00, val=0x0) at
route.c:1171
#9 0x0000000000453bd7 in eval_expr (e=0x65f518, msg=0x66de00, val=0x0) at
route.c:1488
#10 0x0000000000453b7f in eval_expr (e=0x65f560, msg=0x66de00, val=0x0) at
route.c:1493
#11 0x000000000040c4c9 in do_action (a=0x65ffe8, msg=0x66de00) at
action.c:729
#12 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#13 0x000000000040dbc9 in do_action (a=0x660528, msg=0x66de00) at
action.c:746
#14 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#15 0x000000000040dbc9 in do_action (a=0x6606c8, msg=0x66de00) at
action.c:746
#16 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#17 0x000000000040dac5 in do_action (a=0x656790, msg=0x66de00) at
action.c:120
#18 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#19 0x000000000040dbc9 in do_action (a=0x656860, msg=0x66de00) at
action.c:746
#20 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#21 0x000000000040dac5 in do_action (a=0x6560b0, msg=0x66de00) at
action.c:120
#22 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#23 0x000000000040f4f3 in run_top_route (a=0x64b870, msg=0x66de00) at
action.c:120
#24 0x0000000000444e90 in receive_msg (
buf=0x619a20 "INVITE sip:xxxxxxxx@xxxxxxxxxxxx SIP/2.0\r\nVia:
SIP/2.0/UDP
xxx.xxx.xxx.xxx:xxxx;branch=z9hG4bK-d8754z-24245342621eb55b-1---d8754z-;rport\r\nMax-Forwards:
69\r\nContact: <sip:xxxxxxxx@xxx.xxx.xxx.xxx"..., len=1161,
rcv_info=0x7fff81fe86e0) at receive.c:175
#25 0x0000000000479254 in udp_rcv_loop () at udp_server.c:449
#26 0x0000000000427237 in main (argc=7, argv=0x7fff81fe88e8) at main.c:774
I couldn't get to reproduce this behavior in my test development (it has
newer version of glibc) in which I only get the messages:
ERROR:core:anchor_lump: offset exceeds message size (1125 > 714)...
ERROR:nathelper:force_rtp_proxy: anchor_lump failed
Looking into nathelper code, extract_body function I found that the
body->len value is taken from Content-Length header, so i added the
following piece of code:
--- nhelpr_funcs.c.orig 2010-09-02 14:04:09.891649254 +0200
+++ nhelpr_funcs.c 2010-09-02 14:17:40.183747107 +0200
@@ -196,6 +196,12 @@
LM_ERR("message body has length zero\n");
goto error;
}
+
+ if (body->len + body->s > msg->buf + msg->len) {
+ LM_ERR("content-length exceeds packet-length by %d\n",
+ (body->len + body->s) - (msg->buf +
msg->len));
+ body->len=strlen(body->s);
+ }
/* no need for parse_headers(msg, EOH), get_body will
* parse everything */
This way if the Content-Length header is greater then the effective body
length body->len is corrected with the real value.
This solved for the moment, but I'm not sure if this is a good approach and
I still don't understand why in the test platform I cannot reproduce the
crash.
Regards,
Federico Cabiddu
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlahttp://www.asipto.com
4980
days inactive
4986
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
federico cabiddu