[sr-dev] Bug in exported function by ser modules(segmentation fault)

[marius zbihlei]

Hello,
Bear with me for a second long e-mail

First the Core dump:

Program terminated with signal 11, Segmentation fault.
#0  0x00000020 in ?? ()
(gdb) bt
#0  0x00000020 in ?? ()
#1  0x080bab93 in pv_printf (msg=0xbfdda43c, list=0xbfdda434, 
buf=0x820c220 "", len=0xbfdd9f08) at pvapi.c:975
#2  0x080baea7 in pv_printf_s (msg=0x82ac978, list=0xbfdda434, 
s=0xbfdd9f04) at pvapi.c:1126
#3  0xb7d27baf in check_user_list (msg=0x82ac978, str1=<value optimized 
out>, str2=0x82a977c "\344K*\b", str3=0x0, str4=0xbfdda434 "\200y&\b", 
listtype=0)
    at userblacklist.c:247
#4  0x0805a424 in do_action (h=0xbfdda698, a=0x82a4a90, msg=0x82ac978) 
at action.c:866
#5  0x0805ce28 in run_actions (h=0xbfdda698, a=0x82a4a90, msg=0x82ac978) 
at action.c:1301
#6  0x080dd405 in rval_get_int (h=0xbfdda698, msg=0x82ac978, 
i=0xbfdda388, rv=0xbfdd9e3c, cache=0x0) at rvalue.c:866
#7  0x080e08ad in rval_expr_eval_int (h=0xbfdda698, msg=0x82ac978, 
res=0xbfdda388, rve=0x82a4c94) at rvalue.c:1752
#8  0x080e08d5 in rval_expr_eval_int (h=0xbfdda698, msg=0x82ac978, 
res=0xbfdda634, rve=0x82a5048) at rvalue.c:1757
#9  0x08059819 in do_action (h=0xbfdda698, a=0x82a5958, msg=0x82ac978) 
at action.c:840
#10 0x0805ce28 in run_actions (h=0xbfdda698, a=0x82a1cd8, msg=0x82ac978) 
at action.c:1301
#11 0x0805d184 in run_top_route (a=0x82a1cd8, msg=0x82ac978, c=0x0) at 
action.c:1349
#12 0x080c3f1e in receive_msg (
    buf=0x8254560 "INVITE sip:49721123456789 at 127.0.0.1:5059 
SIP/2.0\r\nVia: SIP/2.0/UDP 
127.0.0.1:5061;branch=z9hG4bK-21468-1-0\r\nFrom: sipp 
<sip:sipp at 127.0.0.1:5061>;tag=21468SIPpTag001\r\nTo: sut 
<sip:49721123456789 at 127.0."..., len=519, rcv_info=0xbfdda818) at 
receive.c:195
#13 0x0814416b in udp_rcv_loop () at udp_server.c:527
#14 0x08098d49 in main_loop () at main.c:1454
#15 0x0809ba98 in main (argc=5, argv=0xbfddaaa4) at main.c:2251

(Check that str4 is not null even if the usage is as below)

How to replicate:
Load userblacklist module (or other kamailio module) and call 
check_user_blacklist with 2 
parameters(check_user_blacklist("$avp(i:80)", "$avp(i:81)")) (doesn't 
work every time, depends on compilation and what pointer lies there)


Problem
The userblacklist module has the exports for the check_user_blacklist :
 { "check_user_blacklist", (cmd_function)check_user_blacklist, 2, 
check_user_blacklist_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE },
{ "check_user_blacklist", (cmd_function)check_user_blacklist, 3, 
check_user_blacklist_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE },
{"check_user_blacklist", (cmd_function)check_user_blacklist, 4, 
check_user_blacklist_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE },

The function check_user_blacklist in userblacklist.c has the signature :
int check_user_blacklist(struct sip_msg *msg, char* str1, char* str2, 
char* str3, char* str4)

This is cast to a cmd_function (struct sip_msg* msg, char* str1, char* 
str2) witch is called with 2 parameters(or casted to cmd_function3 and 
called with 3 parameters depending of the case) in the action.c 
do_action method. This actually leaves the rest of the pointers having 
some random not NULL values, causing the application to crash.

I've seen that sr doesn't use the same function for various number of 
parameters. I've made a patch that registered for each number of 
parameters an internal function matching the configured number
(
   
int check_user_blacklist2(struct sip_msg *msg, char* str1, char* str2)
{                                                                    
        return check_user_list(msg, str1, str2, 0, 0, 0);            
}   
)
. With this everything is ok.

Another solution is to define cmd_function like in kamailio (haveing 6 
(max) numbers of char*)

Any suggestions from devs is most welcome. (The problem plagues also 
cr_route call with 5 parameters)

P.S.
#0  0xb7d746b2 in actually_rewrite (_msg=0x82b34f4, _carrier=0x82b02f4, 
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc,
    _hsrc=shs_call_id, _halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:345
345                     if (add_avp(AVP_VAL_STR | 
descavp->v.pve->spec.pvp.pvn.u.isname.type,
(gdb) bt
#0  0xb7d746b2 in actually_rewrite (_msg=0x82b34f4, _carrier=0x82b02f4, 
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc,
    _hsrc=shs_call_id, _halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:345
#1  rewrite_on_rule (_msg=0x82b34f4, _carrier=0x82b02f4, 
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc, 
_hsrc=shs_call_id,
    _halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:460
#2  rewrite_uri_recursor (_msg=0x82b34f4, _carrier=0x82b02f4, 
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc, 
_hsrc=shs_call_id,
    _halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:499
#3  cr_do_route (_msg=0x82b34f4, _carrier=0x82b02f4, _domain=0x82b03a4, 
_prefix_matching=0x82b034c, _rewrite_user=0x82b03fc, _hsrc=shs_call_id,
    _halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:591
#4  0xb7d761bf in cr_route (_msg=0x82b34f4, _carrier=0x82b02f4, 
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc, 
_hsrc=shs_call_id,
    _descavp=0x868f2ea) at cr_func.c:676
#5  0x0805a0aa in do_action (h=0xbf80a0c8, a=0x82a4124, msg=0x82b34f4) 
at action.c:917
#6  0x0805ce28 in run_actions (h=0xbf80a0c8, a=0x82a4124, msg=0x82b34f4) 
at action.c:1301
#7  0x080dd405 in rval_get_int (h=0xbf80a0c8, msg=0x82b34f4, 
i=0xbf809ad8, rv=0x2e2e2030, cache=0x0) at rvalue.c:866
#8  0x080e08ad in rval_expr_eval_int (h=0xbf80a0c8, msg=0x82b34f4, 
res=0xbf809ad8, rve=0x82a4538) at rvalue.c:1752
#9  0x080e08d5 in rval_expr_eval_int (h=0xbf80a0c8, msg=0x82b34f4, 
res=0xbf809d84, rve=0x82a48ec) at rvalue.c:1757
#10 0x08059819 in do_action (h=0xbf80a0c8, a=0x82a50a8, msg=0x82b34f4) 
at action.c:840
#11 0x0805ce28 in run_actions (h=0xbf80a0c8, a=0x82a3fd0, msg=0x82b34f4) 
at action.c:1301
#12 0x08059872 in do_action (h=0xbf80a0c8, a=0x82a7968, msg=0x82b34f4) 
at action.c:855
#13 0x0805ce28 in run_actions (h=0xbf80a0c8, a=0x82a24ac, msg=0x82b34f4) 
at action.c:1301
#14 0x0805d184 in run_top_route (a=0x82a24ac, msg=0x82b34f4, c=0x0) at 
action.c:1349
#15 0x080c3f1e in receive_msg (
    buf=0x8254560 "INVITE sip:49721123456785 at 127.0.0.1:5060 
SIP/2.0\r\nVia: SIP/2.0/UDP 
127.0.0.1:5061;branch=z9hG4bK-28495-1-0\r\nFrom: sipp 
<sip:sipp at 127.0.0.1:5061>;tag=28495SIPpTag001\r\nTo: sut 
<sip:49721123456785 at 127.0."..., len=519, rcv_info=0xbf80a248) at 
receive.c:195
#16 0x0814416b in udp_rcv_loop () at udp_server.c:527
#17 0x08098d49 in main_loop () at main.c:1454
#18 0x0809ba98 in main (argc=5, argv=0xbf80a4d4) at main.c:2251

Another core dump by using cr_route without the last avp