[asterisk-bugs] [JIRA] (ASTERISK-21211) chan_iax2 - unprotected access of iaxs[peer->callno] potentially results in segfault
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Wed Apr 8 07:02:33 CDT 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-21211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Jordan closed ASTERISK-21211.
----------------------------------
Resolution: Fixed
> chan_iax2 - unprotected access of iaxs[peer->callno] potentially results in segfault
> ------------------------------------------------------------------------------------
>
> Key: ASTERISK-21211
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-21211
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_iax2
> Affects Versions: 11.2.1
> Reporter: Jaco Kroon
> Severity: Critical
> Attachments: asterisk-11.2.1-iax2_poke-segfault.diff
>
>
> chan_iax2.c, specifically in function iax2_poke_peer, a completely unprotected access to iaxs[peer->callno] is made. Specifically I had a segfault trigger on line 12230, an access to iaxs[peer->callno] - the second in a sequence, so peer->callno can definitely change between the two
> It is my understanding that:
> 1. peer->callno can change outside of the function , thus it's probably unsafe to use the raw value as per lines 12223, 12229 and 12230. I believe this should be callno, and not peer->callno. Please correct me if I'm wrong. This can either happen by us calling iax2_destroy, or simply another thread also scheduling a POKE on the same peer.
> 2. All reads and writes to iaxs[X] should be protected by a lock of iaxsl[X]. Lines 12229 and 12230 violates this currently.
> I suspect my crash resulted from a sequence where a POKE was in process of being scheduled, another thread then called iax2_poke_peer for the same peer, called iax2_destroy on the iaxs[] busy being set up, and *boom* major catastrophe.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list