[asterisk-bugs] [JIRA] (ASTERISK-19550) Segfault in ast_readaudio_callback

[Steve Davies (JIRA)]

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

Steve Davies commented on ASTERISK-19550:
-----------------------------------------

Has this issue been resolved in 11.4.0 ? Looking at the code, it has not, but perhaps I am missing it? Neither the patch for 1.6 above, nor the alternative suggested by Mark Michelson appears to have been applied.

Has it been fixed in some other way that I am missing?

                
> Segfault in ast_readaudio_callback
> ----------------------------------
>
>                 Key: ASTERISK-19550
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19550
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/FileFormatInterface
>    Affects Versions: 1.4.43, 1.6.2.22, 1.8.10.0, 1.8.22.0, 10.2.0, 10.12.2, 11.4.0
>         Environment: Easier to reproduce in Intel multi-core servers.
>            Reporter: Steve Davies
>         Attachments: readaudio_callback_workaround
>
>
> Issue believed to occur on all versions. Raised here after email from Mark Michelson on -dev mailing list
> Cause:
> - SIP Refer (attended transfer) a caller into a Queue while the
> position announce is playing.
> - The crash happens more easily on a fast multi-core server.
> Under-the-hood:
> The Queue position announce is being played using
> ast_readaudio_callback, which is called with an ast_filestream*,
> usually every 20ms.
> In the meantime, The SIP Refer sets up a masquerade from within a
> separate thread. If that masquerade is picked-up by ast_read() or
> ast_waitfor_nandfs(), then all is happy, BUT, the
> ast_readaudio_callback() function uses ast_write, which can also
> trigger the ast_do_masquerade().
> Depending on thread scheduling, the call to ast_do_masquerade can
> cause the stream's channel to be freed, or sometimes just marked as a
> ZOMBIE, but either way, the ast_filestream is usually closed using
> ast_closestream(), setting it's ao2 refcount to zero, destroying it,
> and allowing the memory to be re-used.
> At this point execution passes back from the ast_write() to
> ast_readaudio_callback() where it tries to use the freed
> ast_filestream, which in my testing, generally points at garbage data,
> and if it survives that experience, it tries to access the freed
> channel instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira