#462 Segfault in registrar module

trunk
closed-accepted
modules (454)
5
2012-02-15
2012-01-23
saghul
No

Hi,

I run into the following crash on a system using trunk r8673:

#0 0xb7216bfa in calc_buf_len (c=0xaf773ce0) at reply.c:146
#1 build_contact (c=0xaf773ce0) at reply.c:215
#2 0xb721aae5 in add_contacts (_m=0x84eeb50, forced_binding=0x0, _d=0xaf710ebc "@\016q�", _f=0x0, _s=0x0) at save.c:678
#3 save_aux (_m=0x84eeb50, forced_binding=0x0, _d=0xaf710ebc "@\016q�", _f=0x0, _s=0x0) at save.c:800
#4 0xb721b347 in save (_m=0x84eeb50, _d=0xaf710ebc "@\016q�", _f=0x0, _s=0x0) at save.c:847
#5 0x0805a345 in do_action (a=0x843f0d0, msg=0x84eeb50) at action.c:1454

I inspected the trace and I saw that the ucontact struct (c) does have the instance field set, but the REGISTER didn't contain any GRUU. It actually contains the domain part of the AoR.

It segfaults because the sock element of the structure is NULL and calc_buf_len assumes it's not in case instance is set, but how instance got set without a +sip.instance parameter in the Contact header eludes me.

I did try to reproduce this, but couldn't. It happened on a production server which I had to downgrade to avoid this.

I saved several coredumps exactly like this, so if more information is needed please let me know.

Thanks and regards,

Discussion

  • Hi Saúl,

    Can you please provide the SIP trace for such a crash ?
    Also, it would help if you could privately provide access to the core file & OpenSIPS binary, so I can look through it.

    I'm thinking that maybe there was an overflow that overwritten the sip_instance pointer, but not sure until I can see more from gdb and trace.

    Regards,
    Vlad

     
    • assigned_to: nobody --> vladut-paiu
    • status: open --> open-accepted
     
  • saghul
    saghul
    2012-01-23

    Hi Vlad,

    Here is the received message (i extracted it from the coredump):

    REGISTER sip:sip2sip.info SIP/2.0\r\n
    Via: SIP/2.0/UDP 192.168.1.100:36773;branch=z9hG4bK6c02300FBZNXm\r\n
    Max-Forwards: 69\r\n
    From: <sip:abcd@sip2sip.info>;tag=2QXUFpKeejjSa\r\n
    To: <sip:abcd@sip2sip.info>\r\n
    Call-ID: 91547b7f-beb2-122f-5792-00173190395a\r\n
    CSeq: 23232445 REGISTER\r\n
    Contact: <sip:abcd@W.X.Y.Z:36773;transport=udp>\r\n
    Contact: <sip:abcd@W.X.Y.Z:55780;transport=tcp>;expires=0\r\n
    User-Agent: Telepathy-SofiaSIP/0.6.2 sofia-sip/1.12.10\r\n
    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, UPDATE\r\n
    Supported: timer, 100rel, path\r\n
    Authorization: Digest username=\"abcd\", realm=\"sip2sip.info\", nonce=\"xxx\", algorithm=MD5, uri=\"sip:sip2sip.info\", response=\"xxxx\"\r\n
    Content-Length: 0\r\n
    \r\n

    At first I thought it had to do with the 2 contact headers, but I have other core dumps with a single contact header.

    I'll email you the core files and the binary.

    Thanks,

     
  • saghul
    saghul
    2012-01-24

    Hi Vlad,

    Today I got this estrange SIP trace which seems somehow related, though I didn't get any more coredums:

    REGISTER sip:acbd.info SIP/2.0
    Via: SIP/2.0/UDP 192.168.1.122:49382;rport;branch=z9hG4bKPj2d-nsuKqf-.aFLe2QO1WFwTMER0JM2-2
    Max-Forwards: 70
    From: "Adrian Georgescu" <sip:adrian@abcd.info>;tag=zO-2EPNQpfaR3sA3oxTTaFuAvMSgkNli
    To: "Adrian Georgescu" <sip:adrian@abcd.info>
    Contact: <sip:ovgkbeia@192.168.1.122:49382>
    Call-ID: m6h2H6v.SAuj.aAaQLIUUkBVpoDyZJf9
    CSeq: 42 REGISTER
    Expires: 300
    User-Agent: Blink Pro 1.7.1 (MacOSX)
    Authorization: Digest username="adrian", realm="abcd.info", nonce="xxx", uri="sip:abcd.info", response="yyy"
    Content-Length: 0

    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 192.168.1.122:49382;received=A.B.C.D;rport=49382;branch=z9hG4bKPj2d-nsuKqf-.aFLe2QO1WFwTMER0JM2-2
    From: "Adrian Georgescu" <sip:adrian@abcd.info>;tag=zO-2EPNQpfaR3sA3oxTTaFuAvMSgkNli
    To: "Adrian Georgescu" <sip:adrian@abcd.info>;tag=e7d4d6b46afb9bf88242924a8d869ebf.0457
    Call-ID: m6h2H6v.SAuj.aAaQLIUUkBVpoDyZJf9
    CSeq: 42 REGISTER
    Contact: <sip:ovgkbeia@192.168.1.122:49382>;expires=300;received="sip:85.17.186.7:5060;target=sip:A.B.C.D:49382";pub-gruu="sip:adrian@abcd.info;gr=eorgescu.inf";temp-gruu="sip:tgruu.AUMBWWAESGUAQxMPN0MZMl4wVAs8Qxc2QxNGQDpfFjwQFVwcNFQDMEVeWgA1ER1lWEJ7WCUfIxJFGh0PElAhH3klZgURZwA8dAlpJDUI@81.23.228.150:5060;gr"
    Content-Length: 0

    As you can see the response contains both a public and a temporary GRUU though the REGISTER no GRUU is used. I thought it might be relevant.

    Regards,

     
  • Hi Saul,

    Can you please try the latest OpenSIPS trunk ? We recently found an ugly bug that lead to the un-proper loading of SIP instances.

    Regards,
    Vlad

     
  • saghul
    saghul
    2012-02-01

    Hi Vlad,

    I spotted the patch, I'll rebuild our packages and let it run.

    Thanks!

     
  • Hi Saúl,

    Any updates on this ?

    Regards,
    Vlad

     
  • saghul
    saghul
    2012-02-15

    Hi Vlad,

    We didn't get any more crashes and I didn't see the broken GRUU again, so I think we can close this :-)

    Regards,

     
    • status: open-accepted --> closed-accepted