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

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-19550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-19550:
-----------------------------------

    Affects Version/s: 13.18.4

> 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, 13.18.4
>         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 was sent by Atlassian JIRA
(v6.2#6252)