Module: sip-router Branch: master Commit: 9fc34aad6328a92b7572ae077d9ff4d2699dbb48 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9fc34aad...
Author: Alex Balashov abalashov@evaristesys.com Committer: Alex Balashov abalashov@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");
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=9fc34aad...
Author: Alex Balashov abalashov@evaristesys.com Committer: Alex Balashov abalashov@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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