[asterisk-bugs] [JIRA] (ASTERISK-25374) Crash in cdr handle_dial_message where peer is null

[Scott Griepentrog (JIRA)]

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

Scott Griepentrog commented on ASTERISK-25374:
----------------------------------------------

Notes from [~mjordan]:
{noformat}
caller can legitimately be NULL
peer should never be NULL
When we get a Dial message, one of two things has happened
 It's a normal Dial, in which case you have a caller and a peer
Or it is an Originate, in which case you only have a peer
Soo.....
peer being NULL is actually terrifying
Someone made a VERY bad Dial message.
So, it really isn't the CDR code's fault.
My guess is that in our app_dial code, we have a bug on receiving a CANCEL
That could be a race
Things are definitely the most wonky there. Anyway, I'd check to see if we have code in the construction of the Stasis Dial message that makes sure that we have a peer, and doesn't publish if we don't
CDR was the first one to crash, but I'd bet AMI or others would as well
{noformat}

> Crash in cdr handle_dial_message where peer is null
> ---------------------------------------------------
>
>                 Key: ASTERISK-25374
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25374
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>         Environment: CentOS 7 VPS with Asterisk 13 current GIT
>            Reporter: Scott Griepentrog
>         Attachments: backtrace-core.20280.txt, full-log-core.20280.txt
>
>
> Crash in handle_dial_message() on null peer passed to filter_channel_snapshot.
> Crash happened during stress caused by rapid influx of SIP invite exploit attempts.
> Note: dialplan involved is able to pass h extension to Dial(): {{exten => _.,1,Dial(PJSIP/100,6)}}



--
This message was sent by Atlassian JIRA
(v6.2#6252)