Commit is the latest for 4.3: 48d78ce87e2f42bdc77e688a0f45ff725ea97de5
Here is the backtrace:
```
Program terminated with signal 11, Segmentation fault.
#0 0x00007f3b4fd779da in update_dialog_vars_dbinfo (cell=0x7f3b3c3aa958, var=0x3433) at dlg_db_handler.c:651
651 SET_STR_VALUE(values+2, var->key);
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-7.el6_0.x86_64 db4-4.7.25-19.el6_6.x86_64 elfutils-libelf-0.161-3.el6.x86_64 glibc-2.12-1.166.el6_7.1.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-42.el6.x86_64 libacl-2.2.49-6.el6.x86_64 libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libgcc-4.4.7-16.el6.x86_64 libselinux-2.0.94-5.8.el6.x86_64 lm_sensors-libs-3.1.1-17.el6.x86_64 lua-5.1.4-4.1.el6.x86_64 mysql-libs-5.1.73-5.el6_6.x86_64 net-snmp-libs-5.5-54.el6_7.1.x86_64 nspr-4.10.8-1.el6_6.x86_64 nss-3.19.1-3.el6_6.x86_64 nss-softokn-freebl-3.14.3-22.el6_6.x86_64 nss-util-3.19.1-1.el6_6.x86_64 openssl-1.0.1e-42.el6.x86_64 pcre-7.8-7.el6.x86_64 perl-libs-5.10.1-141.el6.x86_64 popt-1.13-7.el6.x86_64 rpm-libs-4.8.0-47.el6.x86_64 tcp_wrappers-libs-7.6-57.el6.x86_64 xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x00007f3b4fd779da in update_dialog_vars_dbinfo (cell=0x7f3b3c3aa958, var=0x3433) at dlg_db_handler.c:651
#1 0x00007f3b4fd78511 in update_dialog_dbinfo_unsafe (cell=0x7f3b3c3aa958) at dlg_db_handler.c:718
#2 0x00007f3b4fd79afc in update_dialog_dbinfo (cell=0x7f3b3c3aa958) at dlg_db_handler.c:861
#3 0x00007f3b4fdb93dc in set_dlg_variable (dlg=0x7f3b3c3aa958, key=0x7f3b508b8760, val=0x7fff7efaae60) at dlg_var.c:305
#4 0x00007f3b50696a9c in set_start_time (dialog=0x7f3b3c3aa958) at acc_cdr.c:523
#5 0x00007f3b5069c932 in cdr_on_create (dialog=0x7f3b3c3aa958, type=2, params=0x7f3b4ffda0a0) at acc_cdr.c:790
#6 0x00007f3b4fd68398 in run_create_callbacks (dlg=0x7f3b3c3aa958, msg=0x7f3b530498f0) at dlg_cb.c:230
#7 0x00007f3b4fd82590 in dlg_new_dialog (req=0x7f3b530498f0, t=0x7f3b3c7b89a8, run_initial_cbs=1) at dlg_handlers.c:865
#8 0x00007f3b4fd81006 in dlg_onreq (t=0x7f3b3c7b89a8, type=1, param=0x7f3b52df2760) at dlg_handlers.c:717
#9 0x00007f3b52b36c3a in run_reqin_callbacks_internal (hl=0x7f3b3b7eb480, trans=0x7f3b3c7b89a8, params=0x7f3b52df2760) at t_hooks.c:360
#10 0x00007f3b52b36d48 in run_reqin_callbacks (trans=0x7f3b3c7b89a8, req=0x7f3b530498f0, code=1) at t_hooks.c:385
#11 0x00007f3b52af7b58 in build_cell (p_msg=0x7f3b530498f0) at h_table.c:356
#12 0x00007f3b52b48283 in new_t (p_msg=0x7f3b530498f0) at t_lookup.c:1269
#13 0x00007f3b52b494b3 in t_newtran (p_msg=0x7f3b530498f0) at t_lookup.c:1409
#14 0x00007f3b52b1de9c in t_relay_to (p_msg=0x7f3b530498f0, proxy=0x0, proto=0, replicate=0) at t_funcs.c:236
#15 0x00007f3b52b5cbbb in _w_t_relay_to (p_msg=0x7f3b530498f0, proxy=0x0, force_proto=0) at tm.c:1476
#16 0x00007f3b52b5dd20 in w_t_relay (p_msg=0x7f3b530498f0, _foo=0x0, _bar=0x0) at tm.c:1677
#17 0x000000000041ddad in do_action (h=0x7fff7efabc80, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1053
#18 0x000000000042a4c3 in run_actions (h=0x7fff7efabc80, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1548
#19 0x000000000042ab28 in run_actions_safe (h=0x7fff7efac8a0, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1613
#20 0x0000000000543c94 in rval_get_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, i=0x7fff7efac158, rv=0x7f3b52efd008, cache=0x0) at rvalue.c:912
#21 0x0000000000547ecc in rval_expr_eval_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, res=0x7fff7efac158, rve=0x7f3b52efd000) at rvalue.c:1906
#22 0x00000000005482c2 in rval_expr_eval_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, res=0x7fff7efac5e0, rve=0x7f3b52efd700) at rvalue.c:1914
#23 0x000000000041d897 in do_action (h=0x7fff7efac8a0, a=0x7f3b52efccb0, msg=0x7f3b530498f0) at action.c:1029
#24 0x000000000042a4c3 in run_actions (h=0x7fff7efac8a0, a=0x7f3b52e45308, msg=0x7f3b530498f0) at action.c:1548
#25 0x000000000042abf0 in run_top_route (a=0x7f3b52e45308, msg=0x7f3b530498f0, c=0x0) at action.c:1634
#26 0x000000000050a938 in receive_msg (
buf=0xa6fee0 "INVITE sip:09011112222@192.168.2.185:5060 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.0.186:5010;rport;branch=z9hG4bK-13146-256700-4\r\nFrom: \"user1\" <sip:user1@test1.com>;tag=13146SIPpTag00256700\r\nTo: <sip:09011"..., len=947, rcv_info=0x7fff7efacb90) at receive.c:196
#27 0x000000000060a3ea in udp_rcv_loop () at udp_server.c:495
#28 0x00000000004a7ef7 in main_loop () at main.c:1573
#29 0x00000000004ae2d2 in main (argc=7, argv=0x7fff7efacfc8) at main.c:2533
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/301
Module: kamailio
Branch: master
Commit: 74c84c7cd52347fcd1c90e75dca239b5f758169b
URL: https://github.com/kamailio/kamailio/commit/74c84c7cd52347fcd1c90e75dca239b…
Author: Carsten Bock <carsten(a)ng-voice.com>
Committer: Carsten Bock <carsten(a)ng-voice.com>
Date: 2015-08-28T12:11:25+02:00
db_postgres: Fix heap use after free error in db_postgres module
The result structure for a query holds a pointer returned by
PQfname. When sql_do_query executes the query it gets this
database result structure returned but the PQfname pointer
has already been free'd by a call to db_postgres_free_query
from within db_postgres_store_result.
sql_do_query then tries to copy the free'd string into another
result structure resulting in a heap use after free.
The fix here copies the PQfname result.
Fix by Chris Double
---
Modified: modules/db_postgres/km_pg_con.c
Modified: modules/db_postgres/km_res.c
---
Diff: https://github.com/kamailio/kamailio/commit/74c84c7cd52347fcd1c90e75dca239b…
Patch: https://github.com/kamailio/kamailio/commit/74c84c7cd52347fcd1c90e75dca239b…
---
diff --git a/modules/db_postgres/km_pg_con.c b/modules/db_postgres/km_pg_con.c
index ec98add..d053c55 100644
--- a/modules/db_postgres/km_pg_con.c
+++ b/modules/db_postgres/km_pg_con.c
@@ -71,10 +71,6 @@ struct pg_con* db_postgres_new_connection(struct db_id* id)
memset(ptr, 0, sizeof(struct pg_con));
ptr->ref = 1;
- memset(keywords, 0, (sizeof(char*) * 10));
- memset(values, 0, (sizeof(char*) * 10));
- memset(to, 0, (sizeof(char) * 16));
-
if (id->port) {
ports = int2str(id->port, 0);
keywords[i] = "port";
diff --git a/modules/db_postgres/km_res.c b/modules/db_postgres/km_res.c
index e9aa232..912206b 100644
--- a/modules/db_postgres/km_res.c
+++ b/modules/db_postgres/km_res.c
@@ -126,8 +126,14 @@ int db_postgres_get_columns(const db1_con_t* _h, db1_res_t* _r)
RES_NAMES(_r)[col]);
/* The pointer that is here returned is part of the result structure. */
- RES_NAMES(_r)[col]->s = PQfname(CON_RESULT(_h), col);
- RES_NAMES(_r)[col]->len = strlen(PQfname(CON_RESULT(_h), col));
+ RES_NAMES(_r)[col]->s = pkg_malloc(strlen(PQfname(CON_RESULT(_h), col))+1);
+ if (! RES_NAMES(_r)[col]->s) {
+ LM_ERR("no private memory left\n");
+ db_free_columns(_r);
+ return -4;
+ }
+ strcpy(RES_NAMES(_r)[col]->s, PQfname(CON_RESULT(_h), col));
+ RES_NAMES(_r)[col]->len = strlen(RES_NAMES(_r)[col]->s);
LM_DBG("RES_NAMES(%p)[%d]=[%.*s]\n", RES_NAMES(_r)[col], col,
RES_NAMES(_r)[col]->len, RES_NAMES(_r)[col]->s);
Hi Daniel,
I must admit this run_onsend() patch for stateful replies creation was
not quite a success story. However, I think it serves a practical
purpose, for example in Homer tracing and could be useful for the
community. Again, I propose my past solution, with some questions:
1. I am unsure if the place I introduced the run_onsend call is
appropriate since the buf used for msg_send is constructed
build_res_buf_from_sip_req and build_res_buf_from_sip_res calls.
2. Also, we can maybe unite these if call branches I created:
send_res = msg_send(&uas_rb->dst, buf, res_len);
send_res = SEND_PR_BUFFER( uas_rb, buf, res_len );
3. Do you think a get_send_socket snippet as follows should be inserted
before the /*if (onsend_route_enabled(SIP_REPLY)){*/ :
if(dst.send_sock == NULL) {
dst.send_sock=get_send_socket(msg, &dst.to, dst.proto);
if (dst.send_sock==0){
LM_ERR("cannot forward reply\n");
}
}
Thank you,
Lucian
On 10/29/2014 02:15 PM, Daniel-Constantin Mierla wrote:
> Hello Lucian,
>
> I applied your patch with some fixes.
>
> I haven't checked with stateful replies, at some point a function from
> core should be used. You can go ahead and see if it works, if not, let
> me know and I can look into it as well. You can follow the callbacks
> for TMCB_RESPONSE_OUT or TMCB_RESPONSE_FWDED inside tm code, they
> should lead to the place where a sip response is going to be sent out.
>
> Cheers,
> Daniel
>
> On 27/10/14 12:51, Lucian Balaceanu wrote:
>> Hello Daniel,
>>
>> I must admit I only saw your mail last Friday. Until the 10th of
>> October I was also on vacation. I know that you actually committed
>> some of the changes together with your comments on the 12th this month.
>>
>> I don't know if we can consider the topic of the patch closed. As far
>> as I understand, the state-full replies have not been addressed,
>> right? (There should be a change in the t_reply.c) I followed the
>> code to the relay_reply but I did not yet come to find the send
>> function. Should I pursue further?
>>
>> Thank you,
>> Lucian Balaceanu
>>
>>> Hi Lucian,
>>>
>>> somehow I forgot to follow up on this. But we need to get sorted out
>>> soon, before we release, so it works as expected with the new
>>> version. See more comments inline.
>>>
>>>
>>> On 17/09/14 18:09, Lucian Balaceanu wrote:
>>>> Hi Daniel,
>>>>
>>>> Please forgive me for my delay in responding to your mail.
>>>> Please find attached a second version of the onsend_route_reply
>>>> patch (which again has some problems). As per your previous
>>>> indications I did the following:
>>>>
>>>> *Issue1*
>>>>> From performances point of view, there can be added a config
>>>>> parameter to enable running of onsend_route for replies:
>>>>>
>>>>> onsend_route_reply = 0|1
>>>>
>>>> Following
>>>> http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters I
>>>> have tried to add onsend_route_reply parameter. The code compiles,
>>>> but when trying to start kamailio with this parameter inside, the
>>>> parsing fails with syntax errors signaling:
>>>>
>>>> / 0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse error in config
>>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108,
>>>> column 0: syntax error
>>>> 0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse error in config
>>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108,
>>>> column 0:
>>>> ERROR: bad config file (2 errors)/
>>>
>>> The issue is:
>>>
>>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext);
>>> + yy_number_str=yytext; return NUMBER; }
>>>
>>> It should be:
>>>
>>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext);
>>> + yy_number_str=yytext; return ONSEND_RT_REPLY; }
>>>
>>>>
>>>> *Issue2*
>>>>> #define onsend_enabled(rtype)
>>>>> (onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0)
>>>> That is to say you see it best to take the chek for
>>>> onsend_rt.list[DEFAULT_RT] from inside run_onsend() function and
>>>> call this onsend_enabled(...) before the run_onsend()?
>>>
>>> This is to detect whether the onsend_route should be executed for
>>> SIP replies. The condition being:
>>>
>>> - if is a sip reply and onsend_route is set and the
>>> onsend_route_reply parameter is 1
>>>>
>>>> *Issue3*
>>>>> On the other hand, is onsend_route also executed for local
>>>>> requests? I had in mind it is only for received requests that are
>>>>> forwarded ... Iirc, on onsend_route, the sip message is the one
>>>>> received, the outgoing content being accessible via $snd(buf).
>>>>>
>>>> I agree with you with taking out the locally generated requests and
>>>> only left the run_onsend call in do_forward_reply function (inside
>>>> forward.c).
>>>> Could you point me to the reply relaying function that is called
>>>> for state-full processing?
>>> Stateful processing for replies is mainly done in t_reply.c from tm
>>> module. At some point there should be a send buffer function call.
>>>
>>> Cheers,
>>> Daniel
>>>>
>>>> Thank you and sorry again for my late answer,
>>>> Lucian
>>>
>>> --
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>>>
>>>
>>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
For some registered users the kamctl ul show subscriber@domain does not find the AOR, however in a full listing it shows up, the ul.lookup rpc method has the same issue.
Kamailio version is 4.3.1
For example, here is a full listing:
```
Domain:: location table=1024 records=4 max_slot=1
AOR:: subscriber1(a)domain.com
Contact:: sip:subscriber1@192.168.1.238:32989;alias=212.2.160.202~37476~1;rinstance=5e040b71a89dace0;transport=UDP Q=
Expires:: 45
Callid:: Q9tQDalSnHzw78gSlpDC6g..
Cseq:: 783
User-agent:: Z 3.7.30891 r30851
Received:: sip:212.2.160.202:37476
Path:: <sip:10.7.0.109;lr;received=sip:212.2.160.202:37476>
State:: CS_NEW
Flags:: 0
Cflag:: 64
Socket:: udp:10.7.0.175:5060
Methods:: 5087
Ruid:: uloc-55b11002-2df0-82a2
Reg-Id:: 0
Last-Keepalive:: 1437721166
Last-Modified:: 1437721166
AOR:: subscriber2(a)domain.com
Contact:: sip:subscriber2@172.16.0.110:5060;alias=78.143.152.30~21183~1 Q=
Expires:: 107
Callid:: 7c5fd25f-c2583f1d63761b4f099e0080f0d14465(a)172.16.0.110
Cseq:: 7
User-agent:: BFH_IE_Panasonic_KX-UT133X/01.278 (0080F0D14465)
Received:: sip:78.143.152.30:21183
Path:: <sip:10.7.0.109;lr;received=sip:78.143.152.30:21183>
State:: CS_NEW
Flags:: 2
Cflag:: 64
Methods:: 6815
Ruid:: uloc-55b10ff9-1f87-45
Reg-Id:: 0
Last-Keepalive:: 1437721228
Last-Modified:: 1437721228
```
if I lookup subscriber1, then kamctl ul show works:
```
# kamctl ul show subscriber1(a)domain.com
Contact:: <sip:subscriber1@192.168.1.238:32989;alias=212.2.160.202~37476~1;rinstance=5e040b71a89dace0;transport=UDP>;q=;expires=21;flags=0x0;cflags=0x40;state=0;socket=<udp:10.7.0.175:5060>;methods=0x13DF;received=<sip:212.2.160.202:37476>;user_agent=<Z 3.7.30891 r30851>;path=<<sip:10.7.0.109;lr;received=sip:212.2.160.202:37476>>;reg-id=0
```
However, if I lookup sibscriber2, then it cannot find it:
```
# kamctl ul show subscriber2(a)domain.com
404 AOR not found
```
I have masked the subscriber information, but if it is of use for you, I can send the actual data directly to you.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/264