5 Aug
2012
5 Aug
'12
8:40 a.m.
Module: sip-router
Branch: master
Commit: 9fc34aad6328a92b7572ae077d9ff4d2699dbb48
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9fc34aa…
Author: Alex Balashov <abalashov(a)evaristesys.com>
Committer: Alex Balashov <abalashov(a)evaristesys.com>
Date: Sun Aug 5 08:22:12 2012 -0400
core: Added null pointer check to parser/msg_parser.c:get_hdr_field().
Encountered crash bug in which 'buf' pointer passed to get_hdr_field()
was null. There is no null check, so attempts to dereference it lead to
a crash:
Core was generated by `/usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 1024 -u root
-g root -f /r'.
Program terminated with signal 11, Segmentation fault.
at parser/msg_parser.c:102
102 if ((*buf)=='\n' || (*buf)=='\r'){
Fixed by adding a check for buf == NULL to top of function.
---
parser/msg_parser.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/parser/msg_parser.c b/parser/msg_parser.c
index 803ee07..b279e47 100644
--- a/parser/msg_parser.c
+++ b/parser/msg_parser.c
@@ -96,6 +96,11 @@ char* get_hdr_field(char* const buf, char* const end, struct hdr_field*
const hd
int integer, err;
unsigned uval;
+ if(!buf) {
+ DBG("null buffer pointer\n");
+ goto error;
+ }
+
if ((*buf)=='\n' || (*buf)=='\r'){
/* double crlf or lflf or crcr */
DBG("found end of header\n");
5 Aug
5 Aug
8:54 a.m.
I wish I could tell what exotic SIP message caused this, bug I am not
crafty enough with GDB, and a lot of values are optimised out because I
did not specifically compile with all debugging symbols in. But here's
what I've got:
#0 get_hdr_field (buf=0x0, end=0x8d88b1 "", hdr=0x2acdfc282048)
at parser/msg_parser.c:102
#1 0x00000000005425ff in parse_headers (msg=0x2acdfc275330, flags=64,
next=<value optimized out>) at parser/msg_parser.c:349
#2 0x00002acdfcc56e2c in pv_get_callid (msg=0x0, param=0x2acdfc27d468,
res=0x7fff5362ccf0) at pv_core.c:587
#3 0x000000000049082c in pv_get_spec_value (msg=0x2acdfc275330,
sp=0x2acdfc27d450, value=0x7fff5362ccf0) at pvapi.c:1180
#4 0x0000000000491188 in pv_printf (msg=0x2acdfc275330,
list=<value optimized out>, buf=<value optimized out>,
len=0x7fff5362cd78)
at pvapi.c:1238
#5 0x00002acdfe1974ef in xlog_helper (msg=0x0, xm=0x2acdfc25d2e8, level=2,
line=0, facility=48) at xlog.c:175
#6 0x00002acdfe1992d2 in xlog_2_helper (msg=0x2acdfc275330,
lev=<value optimized out>, frm=0x2acdfc25d2e8 "@\324'\374\315*",
mode=0,
facility=-1) at xlog.c:244
#7 0x00000000004142d3 in do_action (h=0x7fff5362f2e0, a=0x2acdfc262d88,
msg=0x2acdfc275330) at action.c:1151
#8 0x000000000041bc7c in run_actions (h=0x7fff5362f2e0, a=0x2acdfc25af40,
msg=0x2acdfc275330) at action.c:1644
#9 0x00000000004140ec in do_action (h=0x7fff5362f2e0,
a=<value optimized out>, msg=0x2acdfc275330) at action.c:761
#10 0x000000000041bc7c in run_actions (h=0x7fff5362f2e0, a=0x2acdfc245748,
msg=0x2acdfc275330) at action.c:1644
#11 0x00000000004140ec in do_action (h=0x7fff5362f2e0,
a=<value optimized out>, msg=0x2acdfc275330) at action.c:761
#12 0x000000000041bc7c in run_actions (h=0x7fff5362f2e0, a=0x2acdfc232988,
msg=0x2acdfc275330) at action.c:1644
#13 0x00000000004140ec in do_action (h=0x7fff5362f2e0,
a=<value optimized out>, msg=0x2acdfc275330) at action.c:761
#14 0x000000000041bc7c in run_actions (h=0x7fff5362f2e0, a=0x2acdfc228b50,
msg=0x2acdfc275330) at action.c:1644
#15 0x000000000041428f in do_action (h=0x7fff5362f2e0, a=0x2acdfc229b58,
msg=0x2acdfc275330) at action.c:1140
#16 0x000000000041bc7c in run_actions (h=0x7fff5362f2e0, a=0x2acdfc229b58,
msg=0x2acdfc275330) at action.c:1644
#17 0x000000000041428f in do_action (h=0x7fff5362f2e0, a=0x2acdfc229c48,
msg=0x2acdfc275330) at action.c:1140
#18 0x000000000041bc7c in run_actions (h=0x7fff5362f2e0, a=0x2acdfc2275a0,
msg=0x2acdfc275330) at action.c:1644
#19 0x000000000041428f in do_action (h=0x7fff5362f2e0, a=0x2acdfc22a100,
msg=0x2acdfc275330) at action.c:1140
#20 0x000000000041bc7c in run_actions (h=0x7fff5362f2e0, a=0x2acdfc21ca50,
msg=0x2acdfc275330) at action.c:1644
#21 0x000000000041c252 in run_top_route (a=0x2acdfc21ca50,
msg=0x2acdfc275330,
c=<value optimized out>) at action.c:1729
#22 0x000000000049eb9e in receive_msg (
buf=0x8d84e0 "INVITE sip:19378983606 710@207.239.33.68:5060
SIP/2.0\r\nRecord-Route:
<sip:67.202.68.216;lr=on;ftag=16tymU8a0r00F;vsf=", 'A' <repeats 40
times>, "OjUwNjA->\r\nVia: SIP/2.0/UDP 74.117.36.132;r"...,
len=<value optimized out>, rcv_info=0x7fff5362f540) at receive.c:209
#23 0x0000000000531eb5 in udp_rcv_loop () at udp_server.c:544
#24 0x000000000046c094 in main_loop () at main.c:1633
#25 0x000000000046fa49 in main (argc=<value optimized out>,
argv=<value optimized out>) at main.c:2546
More concretely:
(gdb) set print elements 0
(gdb) frame 22
#22 0x000000000049eb9e in receive_msg (
buf=0x8d84e0 "INVITE sip:19378983606 710@207.239.33.68:5060
SIP/2.0\r\nRecord-Route:
<sip:67.202.68.216;lr=on;ftag=16tymU8a0r00F;vsf=", 'A' <repeats 40
times>, "OjUwNjA->\r\nVia: SIP/2.0/UDP
74.117.36.132;rport;branch=z9hG4bKS3HNBgF9eZg1B\r\nMax-Forwards:
32\r\nFrom: <sip:447946638460@74.117.36.132>;tag=16tymU8a0r00F\r\nTo:
<sip:19378983606+710@67.202.68.216:5060>\r\nCall-ID:
c7af1039-5520-1230-c785-0022192283b7\r\nCSeq: 31502447
INVITE\r\nContact: <sip:447946638460@74.117.36.132:5060>\r\nUser-Agent:
DNL-Switch\r\nAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO,
PRACK\r\nSupported: 100rel\r\nContent-Type:
application/sdp\r\nContent-Length: 351\r\n\r\nv=0\r\no=- 1098630309 1 IN
IP4 74.117.36.132\r\ns=DNL-SDP\r\nc=IN IP4 74.117.36.132\r\nt=0
0\r\nm=audio 45872 RTP/AVP 8 18 4 0 101\r\na=rtpmap:8
PCMA/8000/1\r\na=rtpmap:18 G729/8000/1\r\na=fmtp:18
annexb=no\r\na=rtpmap:4 G723/8000/1\r\na=fmtp:4 annexa=no\r\na=rtpmap:0
PCMU/8000/1\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101
0-15\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\n", len=<value
optimized out>, rcv_info=0x7fff5362f540) at receive.c:209
209 if (run_top_route(main_rt.rlist[DEFAULT_RT], msg, 0)<0)
However, I can't really make heads or tails of this value. If any GDB
pros have tips for analysing this buffer?
On 08/05/2012 08:40 AM, Alex Balashov wrote:
Module: sip-router
Branch: master
Commit: 9fc34aad6328a92b7572ae077d9ff4d2699dbb48
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9fc34aa…
Author: Alex Balashov <abalashov(a)evaristesys.com>
Committer: Alex Balashov <abalashov(a)evaristesys.com>
Date: Sun Aug 5 08:22:12 2012 -0400
core: Added null pointer check to parser/msg_parser.c:get_hdr_field().
Encountered crash bug in which 'buf' pointer passed to get_hdr_field()
was null. There is no null check, so attempts to dereference it lead to
a crash:
Core was generated by `/usr/local/sbin/kamailio -P /var/run/kamailio.pid -m 1024 -u root
-g root -f /r'.
Program terminated with signal 11, Segmentation fault.
at parser/msg_parser.c:102
102 if ((*buf)=='\n' || (*buf)=='\r'){
Fixed by adding a check for buf == NULL to top of function.
---
parser/msg_parser.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/parser/msg_parser.c b/parser/msg_parser.c
index 803ee07..b279e47 100644
--- a/parser/msg_parser.c
+++ b/parser/msg_parser.c
@@ -96,6 +96,11 @@ char* get_hdr_field(char* const buf, char* const end, struct
hdr_field* const hd
int integer, err;
unsigned uval;
+ if(!buf) {
+ DBG("null buffer pointer\n");
+ goto error;
+ }
+
if ((*buf)=='\n' || (*buf)=='\r'){
/* double crlf or lflf or crcr */
DBG("found end of header\n");
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
6 Aug
6 Aug
5:32 a.m.
New subject: git:master: core: Added null pointer check to parser/msg_parser.c: get_hdr_field().
Am Sonntag, 5. August 2012, 14:54:55 schrieb Alex Balashov:
I wish I could tell what exotic SIP message caused
this, bug I am not
crafty enough with GDB, and a lot of values are optimised out because I
did not specifically compile with all debugging symbols in. But here's
what I've got:
[..]
More concretely:
(gdb) set print elements 0
(gdb) frame 22
#22 0x000000000049eb9e in receive_msg (
buf=0x8d84e0 "INVITE sip:19378983606 710@207.239.33.68:5060
SIP/2.0\r\nRecord-Route:
Hello Alex,
you could try to print the buf string explicitely. If you then copy this in a
text editor and remove the line breaks (/r/n) you should be able to recover
the SIP message.
Cheers,
Henning Westerholt
4525
days inactive
4526
days old
2 comments
2 participants
participants (2)
-
Alex Balashov -
Henning Westerholt