[asterisk-bugs] [JIRA] (ASTERISK-25603) [patch]udptl: Uninitialized lengths and bufs in udptl_rx_packet cause ast_frdup crash

[Asterisk Team (JIRA)]

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

Asterisk Team updated ASTERISK-25603:
-------------------------------------

    Target Release Version/s: 13.8.0

> [patch]udptl: Uninitialized lengths and bufs in udptl_rx_packet cause ast_frdup crash
> -------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25603
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25603
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Core/UDPTL
>    Affects Versions: 11.20.0, 13.6.0
>            Reporter: Walter Doekes
>            Assignee: Richard Mudgett
>      Target Release: 11.21.1, 13.7.1, 13.8.0
>
>         Attachments: ASTERISK-25603_fix_udptl_crash-2.patch, ASTERISK-25603_fix_udptl_crash.patch
>
>
> UDPTL frames get decoded by udptl_rx_packet. If no packets are lost, the subpacket IFP length is read into ifp_len, which is initialized to 0. The first frame in a list of frames is filled with the T38 data, it is returned to ast_udptl_read, and it ends up in ast_read() (channel.c).
> However, if the sequence number does a jump, Asterisk tries to use the error correcting redundancy packets available. There the IFP length nor the buffer are initialized. And if the supplied IFP length is 0, it is not stored: those uninitialized values end up in the frame {{data}} and {{datalen}} attributes.
> Serving UDPTL packets with the right amount of missing sequence numbers and enough redundant 0-length IFP packets, will make Asterisk enqueue the excess redundant frames through ast_queue_frame(). There, an ast_frdup() will attempt to read the message: datalen could be huge or data may point outside the process address space. In either case, Asterisk crashes.
> This has been broken since the introduction of the UDPTL code in 2006 (0f5e4e47). It has been mitigated somewhat by 3f789aa8 in 2012, but that apparently wasn't enough.
> According to my tests, if can you force Asterisk to read UDPTL, if even for bridging only, the right pcap will make it crash with absolute certainty.
> This was tested against 11.19, after reports were received that an Asterisk 1.4 was crashing on this same issue.
> Fix is attached.
> Cheers,
> Walter Doekes
> OSSO B.V.



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