[asterisk-bugs] [JIRA] (ASTERISK-26252) Segfault when using SendFax / ReceiveFax via T.38

[Michal Rybarik (JIRA)]

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

Michal Rybarik commented on ASTERISK-26252:
-------------------------------------------

I have compared yours and mine SpanDSP sources and there is no significant difference between them. I have tried another SpanDSP too, and problem remains. 

So I have looked deeper into backtraces and sources, and it seems that spandsp segfaults because of incorrect data received from Asterisk. In both backtraces there is segfault in t38_core_rx_ifp_stream(), and if I read backtraces correcttly, it receives empty buffer ("") in one argument and buflen=1 in next. Then spandsp tries to read 1 byte (buflen) from empty buffer, and it produces segfault, of course.

In res_fax_spandsp.c in function spands_fax_write() I see, that invalid data (empty buffer with buflen=1) comes from ast_frame f->data.ptr and f->datalen. But I'm not sure where ast_frame f comes from and why it has such inconsistent data inside, I'm little bit lost here. 

> Segfault when using SendFax / ReceiveFax via T.38
> -------------------------------------------------
>
>                 Key: ASTERISK-26252
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26252
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/T.38, Resources/res_fax_spandsp
>    Affects Versions: 11.23.0
>            Reporter: Michal Rybarik
>            Assignee: Unassigned
>         Attachments: backtrace-receive.txt, backtrace-send.txt, debug_log_26252_receivefax.log, debug_log_26252_sendfax.log
>
>
> SendFax and ReceiveFax are doing segfaults on latest Asterisk 11 release, short while after SendFax/ReceiveFax is invoked. It happens on every call. In my setup faxes goes from/to Asterisk via SIP trunk (chan_sip + T.38). There was no such problem with older Asterisk 11 r412438 on the same host and setup.



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