[asterisk-bugs] [JIRA] (ASTERISK-27952) Segfault after pjsip hdr linked list corruption
Asterisk Team (JIRA)
noreply at issues.asterisk.org
Tue Jul 3 09:01:54 CDT 2018
[ https://issues.asterisk.org/jira/browse/ASTERISK-27952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=244007#comment-244007 ]
Asterisk Team commented on ASTERISK-27952:
------------------------------------------
Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.
A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.
Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
> Segfault after pjsip hdr linked list corruption
> -----------------------------------------------
>
> Key: ASTERISK-27952
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-27952
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: pjproject/pjsip
> Affects Versions: 15.3.0
> Reporter: lvl
> Labels: pjsip
>
> Twice now, we've experienced an Asterisk segfault which was caused by a corrupted "hdr" linked list. This only happens once every thousands of calls so I'm not able to draw a connection yet, but as far as I can see there was nothing out of the ordinary for the affected calls.
> Might be related to https://issues.asterisk.org/jira/browse/ASTERISK-27792 and https://issues.asterisk.org/jira/browse/ASTERISK-26832.
> As you can see the first couple of header entries in the list are completely normal, but eventually hdr.next points to an invalid memory address.
> Case 1:
> {code}
> #0 pj_stricmp (str1=str1 at entry=0x1e, str2=str2 at entry=0x7f17a4baead0) at ../include/pj/string_i.h:216
> #1 0x00007f18d1d549a5 in pjsip_msg_find_hdr_by_name (msg=0x7f181c245180, name=name at entry=0x7f17a4baead0, start=start at entry=0x0) at ../src/pjsip/sip_msg.c:363
> hdr = 0x6
> end = 0x7f181c2451a8
> {code}
> {code}
> (gdb) print *msg.hdr.next.next.next.next.next.next.next.next.next.next
> $23 = {
> prev = 0x7f187406d368,
> next = 0x7f18741e3568,
> type = PJSIP_H_OTHER,
> name = {
> ptr = 0x7f18d1ddfedd "Min-SE",
> slen = 6
> },
> sname = {
> ptr = 0x0,
> slen = 0
> },
> vptr = 0x7f18d2022d00 <min_se_hdr_vptr>
> }
> (gdb) print *msg.hdr.next.next.next.next.next.next.next.next.next.next.next
> $24 = {
> prev = 0x7f1874041098,
> next = 0x6,
> type = 177,
> name = {
> ptr = 0x7f1874036040 "al-queuemember-0006aa1a;2\033[0m\", \"\033[1;35mARRAY(target_username xxxx \001",
> slen = 139743010334336
> },
> sname = {
> ptr = 0x0,
> slen = 4294967295
> },
> vptr = 0x0
> }
> {code}
> Case 2:
> {code}
> #0 pjsip_hdr_print_on (hdr_ptr=0x7f3133322e36, buf=0x7f0fbc1f3430 "Content-Type: application/sdprnContent-Length: 261rnrnv=0rno=- 572496747 572496749 xxxx"..., len=31096) at ../src/pjsip/sip_msg.c:584
> hdr = 0x7f3133322e36
> #1 0x00007f1034e4ac85 in pjsip_msg_print (msg=0x7f0f180bff30, buf=0x7f0fbc1f30a8 "SIP/2.0 183 Session ProgressrnVia: xxxx"..., size=<optimized out>) at ../src/pjsip/sip_msg.c:464
> p = 0x7f0fbc1f3430 "Content-Type: application/sdprnContent-Length: 261rnrnv=0rno=- 572496747 572496749 xxxx"...
> end = 0x7f0fbc1fada8 "250255037274017177"
> len = <optimized out>
> hdr = 0x7f3133322e36
> clen_hdr = {ptr = 0x7f1034ed8eef "Content-Length: ", slen = 16}
> {code}
> {code}
> (gdb) p *msg.hdr.next.next.next.next.next.next.next.next.next.next.next
> $14 = {
> prev = 0x7f0fbc34a730,
> next = 0x7f0fbc1fb9e8,
> type = PJSIP_H_ALLOW,
> name = {
> ptr = 0x7f1034ed9284 "Allow",
> slen = 5
> },
> sname = {
> ptr = 0x7f1034ed9284 "Allow",
> slen = 5
> },
> vptr = 0x7f103511b3a0 <generic_array_hdr_vptr>
> }
> (gdb) p *msg.hdr.next.next.next.next.next.next.next.next.next.next.next.next
> $15 = {
> prev = 0x362e3333322e3738,
> next = 0x7f3133322e36,
> type = PJSIP_H_CONTACT,
> name = {
> ptr = 0x7f1034ed27eb "Contact",
> slen = 7
> },
> sname = {
> ptr = 0x7f1034eec21a "m",
> slen = 1
> },
> vptr = 0x7f103511b340 <contact_hdr_vptr>
> }
> (gdb) p *msg.hdr.next.next.next.next.next.next.next.next.next.next.next.next.next
> Cannot access memory at address 0x7f3133322e36
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list