[asterisk-bugs] [JIRA] (ASTERISK-27262) res_ari: Leaking eventfds when using ARI Dial

[Richard Mudgett (JIRA)]

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

Richard Mudgett edited comment on ASTERISK-27262 at 9/8/17 10:45 AM:
---------------------------------------------------------------------

One channel is hung up by A or C party, the application hangs up the other leg. (So no need for RemoveChannel() from bridge)
The bridges are created initially and are kept as a pool in our app.

This might be related:
ASTERISK-26718


was (Author: wirum):
One channel is hung up by A or C party, the application hangs up the other leg. (So no need for RemoveChannel() from bridge)
The bridges are created initially and are kept as a pool in our app.

This might be related:
https://issues.asterisk.org/jira/browse/ASTERISK-26718

> res_ari: Leaking eventfds when using ARI Dial
> ---------------------------------------------
>
>                 Key: ASTERISK-27262
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27262
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_ari
>    Affects Versions: 14.6.1
>         Environment: Ubuntu 17.04
>            Reporter: Thomas Wirum Larsen
>            Assignee: Unassigned
>
> When using ARI4Java bindings and their Dial() method, Asterisk leaks (fails to close?) an eventfd, leading to a crash once the underlying OS' ulimit is reached.
> This behavior is only seen using dial(). When using originate(), asterisk behaves correctly.
> This bug is reproducible on Asterisk 13x and 14x using Ari4Java 0.4.3 and 0.4.4 and ARI protocol version 1.7 through 1.10. We have been unsuccessful in testing 2.0.0 or 3.0.0 protocol variants, thus we cannot guarantee this behavior exists in the 2x and 3x protocol branches.
> While the actual bug may be in Ari4Java, it is arguable that a REST interface should not be allowed to cause the host to leak file descriptors as this a potential DOS attack (or worse). This is thus clearly a bug in Asterisks implementation of ARI and requires immediate attention.
> We have filed an issue with Ari4Java as well.



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