[asterisk-bugs] [JIRA] (ASTERISK-20499) Crash in libsrtp srtp_unprotect_rtcp when SIP channel is bridged with non-optimizing Local channel

[Jonathan Rose (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200457#comment-200457 ] 

Jonathan Rose commented on ASTERISK-20499:
------------------------------------------

Before you do that, can you confirm for me that you are in fact using a completely fresh 10.10.0 for the purpose of the backtraces from before?  I've been trying to match some line numbers to some calls in 10.10.0 against the backtrace you provided and one of the lines in particular doesn't seem to make a great deal of sense:

#6  0x00007f78259425aa in sdp_crypto_process (p=0xd2e6060, attr=0xd28f339 "crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PHWJdnd8Sx9fa8a7SkqGRxYxYwiEpXZrXI8w1Y7Y", rtp=0xd2d12c8, 
    srtp=0xfe9830) at sip/sdp_crypto.c:275
        str = 0x0
        tag = 0x7f7808fd4b27 "1"
        suite = 0x7f7808fd4b29 "AES_CM_128_HMAC_SHA1_80"
        key_params = 0x0
        key_param = 0x0
        session_params = 0x0
        key_salt = 0x7f7808fd4b48 "PHWJdnd8Sx9fa8a7SkqGRxYxYwiEpXZrXI8w1Y7Y"
        lifetime = 0x0
        found = 1
        attr_len = 80
        key_len = 30
        suite_val = 1
        remote_key = "<u\211vw|K\037_kƻJJ\206G\026\061c\b\204\245vk\\\217\060", <incomplete sequence \330>
        __PRETTY_FUNCTION__ = "sdp_crypto_process"
#7  0x00007f7825934384 in process_crypto (p=0xd2bdcf8, rtp=0xd2d12c8, srtp=0xd2c13b0, 
    a=0xd28f339 "crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PHWJdnd8Sx9fa8a7SkqGRxYxYwiEpXZrXI8w1Y7Y") at chan_sip.c:30938
        __PRETTY_FUNCTION__ = "process_crypto"

When I checked line 30938 I noticed that that the nearest call to sdp_crypto_process was actually occurring at 30930 8 lines before that one and that was as close as it came in any of the versions we've been looking at for this issue and that would seem to suggest that there are local modifications to chan_sip (which hasn't been the subject of any of my patches) for all of the first three backtraces.

Following that further back I saw more line number discrepencies such as right here:

#9  0x00007f782590d873 in handle_request_invite (p=0xd2bdcf8, req=0x7f7808ff9150, debug=0, seqno=1, addr=0xffa4a8, recount=0x7f7808ff81ec, 
    e=0xd28ef9f "sip:800 at sip3.tootai.net;user=phone", nounlock=0x7f7808ff81e8) at chan_sip.c:23571

which should have been process_sdp, but the closest instance of that call was at 23563 (again, 8 lines off).

Aside from that though, I'm curious, is the new crash occurring on all three of your systems?  I'm a little confused by how you still could have gotten a crash on the system that generated this backtrace (without the new patches applied) since no reading or writing of frames should have been handled at this point. process_sdp should have failed here and the call should have ended... or at least it does on my box when I force ast_srtp_create to fail.
                
> Crash in libsrtp srtp_unprotect_rtcp when SIP channel is bridged with non-optimizing Local channel
> --------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20499
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20499
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/SRTP
>    Affects Versions: 10.8.0
>         Environment: RHEL 5.8 on IBM X3650 M4 - 12 core - Xeon E5-2640 @ 2,50 ghz
>            Reporter: tootai
>            Assignee: Jonathan Rose
>            Severity: Critical
>         Attachments: asterisk-20499_20121127.log, asterisk-20499_20121127.pcap, asterisk-20499_20121129_01.txt, asterisk-20499.txt, backtrace20121205.txt, backtrace.txt, backtrace.txt, backtrace.txt, backtrace.txt, coredump20121001205609.txt, gdb20121205.txt, gdb.txt, gdb.txt, gdb.txt, gdb.txt, libsrtp-1.4.4-fix_crash_on_rtcp_decode.patch, srtp_diagnostic_patch_policy_breakdown.diff, srtp_diagnostic_with_sleep.diff, srtp_fixes_it_maybe.diff
>
>
> A call from snom320 in SRTP mode to echo test or to another phone *NOT* using SRTP is OK. Now we installed PhonerLite softphone with TLS/SRTP stuf and test with echo test: everything is OK too.
> Now PhonerLite calls the snom: asterisk coredump after 3~5 seconds and we are NOT able to make anymore SRTP calls after this, they all crash asterisk. We had this issue with 10.7.0 and 10.8.0
> We have logfiel from strace as well as coredump.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira