When Asterisk sends a re-invite initiating T.38 faxing and the endpoint responds with a m=image line and zero port, a crash will occur in Asterisk. This is a re-occurrence of AST-2019-004.
d43d5cb9a0201ce6df31db1a1a9561360db4a1bb17c19f46dd04be62c2e79557When re-negotiating for T.38 if the initial remote response was delayed just enough Asterisk would send both audio and T.38 in the SDP. If this happened, and the remote responded with a declined T.38 stream then Asterisk would crash.
2a9795115e2a46d96ffa9cb29f66fab90c91d64bdafcfd927d79e02c48f5c8b5Asterisk Project Security Advisory - When audio frames are given to the audio transcoding support in Asterisk the number of samples are examined and as part of this a message is output to indicate that no samples are present. A change was done to suppress this message for a particular scenario in which the message was not relevant. This change assumed that information about the origin of a frame will always exist when in reality it may not. This issue presented itself when an RTP packet containing no audio (and thus no samples) was received. In a particular transcoding scenario this audio frame would get turned into a frame with no origin information. If this new frame was then given to the audio transcoding support a crash would occur as no samples and no origin information would be present.
f099af7f927bb32ebabc2ad896ed9ecc6426a574a8666725577cefa49658c9c4
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed