[asterisk-bugs] [JIRA] (ASTERISK-24726) Cleaned ast_channel in file.c waitstream_core

[Walter Doekes (JIRA)]

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

Walter Doekes updated ASTERISK-24726:
-------------------------------------

    Description: 
For asterisk 13.1.0, I have this backtrace:

{noformat}
...
waitstream_core at file.c:1547
ast_waitstream_full at file.c:1610
handle_streamfile at res_agi.c:2228
agi_handle_command ... buf=... "STREAM" ... at res_agi.c:3671
run_agi ... request=... "agi://127.0.0.1:17902" ... at res_agi.c:3868
{noformat}
.. for a crash that happens in {{ast_sched_runq}} because it is fed a
NULL pointer which came from chan->sched.

Barring memory corruption, this means that {{ast_hangup()}} has been
called -- because it's the only function that sets chan->sched to NULL
on the channel object while it is in this loop in file.c:

{noformat}
static int waitstream_core(struct ast_channel *c,
...
        while (ast_channel_stream(c)) {
...
                ms = ast_sched_wait(ast_channel_sched(c));
...
...
                ast_sched_runq(ast_channel_sched(c)); // CRASH!
        }
{noformat}

Somewhere in that loop, most attributes of 'c' got unset, resulting
in a NULL dereference.

The channel appears to be unlocked here (right?).

So, who has the power to {{ast_hangup()}} this channel while we're in this loop?

----

Additional info:

* c is mostly empty (c->chan is NULL, c->generator is NULL), so my best
  guess is that ast_hangup() was called.

* Hangupsource is set {{hangupsource = 0x3bb2bb8 "PJSIP/proxy-00002e65"}}.

* A few chanvars are set:
{noformat}
{entries = {next = 0x7f7adca95b60}, value = 0x3b223ca "HANGUP", name = 0x3b223c0 "AGISTATUS"}
{entries = {next = 0x349f4b0}, value = 0x7f7adca95b7f "FAILED", name = 0x7f7adca95b70 "PLAYBACKSTATUS"}
{entries = {next = 0x0}, value = 0x349f4cf "inbound", name = 0x349f4c0 "call-direction"}
{noformat}

* run_agi was called from pbx_exec by {{AGI("agi://127.0.0.1:17902")}} dialplan code.


  was:
For asterisk 13.1.0, I have this backtrace:

{noformat}
...
waitstream_core at file.c:1547
ast_waitstream_full at file.c:1610
handle_streamfile at res_agi.c:2228
agi_handle_command ... buf=... "STREAM" ... at res_agi.c:3671
run_agi ... request=... "agi://127.0.0.1:17902" ... at res_agi.c:3868
{noformat}
.. for a crash that happens in {{ast_sched_runq}} because it is fed a
NULL pointer which came from chan->sched.

Barring memory corruption, this means that {{ast_hangup()}} has been
called -- because it's the only function that sets chan->sched to NULL
on the channel object while it is in this loop in file.c:

{noformat}
static int waitstream_core(struct ast_channel *c,
...
        while (ast_channel_stream(c)) {
...
                ms = ast_sched_wait(ast_channel_sched(c));
...
...
                ast_sched_runq(ast_channel_sched(c)); // CRASH!
        }
{noformat}

Somewhere in that loop, most attributes of 'c' got unset, resulting
in a NULL dereference.

The channel appears to be unlocked here (right?).

So, who has the power to {{ast_hangup()}} this channel while we're in this loop?

----

Additional info:

* c is mostly empty (c->chan is NULL, c->generator is NULL), so my best
  guess is that ast_hangup() was called.

* Hangupsource is set {{hangupsource = 0x3bb2bb8 "PJSIP/proxy-00002e65"}}.

* A few chanvars are set:
{noformat}
{entries = {next = 0x7f7adca95b60}, value = 0x3b223ca "HANGUP", name = 0x3b223c0 "AGISTATUS"}
{entries = {next = 0x349f4b0}, value = 0x7f7adca95b7f "FAILED", name = 0x7f7adca95b70 "PLAYBACKSTATUS"}
{entries = {next = 0x0}, value = 0x349f4cf "inbound", name = 0x349f4c0 "call-direction"}
{noformat}



> Cleaned ast_channel in file.c waitstream_core
> ---------------------------------------------
>
>                 Key: ASTERISK-24726
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24726
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/General, Resources/res_agi
>    Affects Versions: 13.1.0
>            Reporter: Walter Doekes
>
> For asterisk 13.1.0, I have this backtrace:
> {noformat}
> ...
> waitstream_core at file.c:1547
> ast_waitstream_full at file.c:1610
> handle_streamfile at res_agi.c:2228
> agi_handle_command ... buf=... "STREAM" ... at res_agi.c:3671
> run_agi ... request=... "agi://127.0.0.1:17902" ... at res_agi.c:3868
> {noformat}
> .. for a crash that happens in {{ast_sched_runq}} because it is fed a
> NULL pointer which came from chan->sched.
> Barring memory corruption, this means that {{ast_hangup()}} has been
> called -- because it's the only function that sets chan->sched to NULL
> on the channel object while it is in this loop in file.c:
> {noformat}
> static int waitstream_core(struct ast_channel *c,
> ...
>         while (ast_channel_stream(c)) {
> ...
>                 ms = ast_sched_wait(ast_channel_sched(c));
> ...
> ...
>                 ast_sched_runq(ast_channel_sched(c)); // CRASH!
>         }
> {noformat}
> Somewhere in that loop, most attributes of 'c' got unset, resulting
> in a NULL dereference.
> The channel appears to be unlocked here (right?).
> So, who has the power to {{ast_hangup()}} this channel while we're in this loop?
> ----
> Additional info:
> * c is mostly empty (c->chan is NULL, c->generator is NULL), so my best
>   guess is that ast_hangup() was called.
> * Hangupsource is set {{hangupsource = 0x3bb2bb8 "PJSIP/proxy-00002e65"}}.
> * A few chanvars are set:
> {noformat}
> {entries = {next = 0x7f7adca95b60}, value = 0x3b223ca "HANGUP", name = 0x3b223c0 "AGISTATUS"}
> {entries = {next = 0x349f4b0}, value = 0x7f7adca95b7f "FAILED", name = 0x7f7adca95b70 "PLAYBACKSTATUS"}
> {entries = {next = 0x0}, value = 0x349f4cf "inbound", name = 0x349f4c0 "call-direction"}
> {noformat}
> * run_agi was called from pbx_exec by {{AGI("agi://127.0.0.1:17902")}} dialplan code.



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