aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/libtwolame.c
diff options
context:
space:
mode:
authorAndreas Rheinhardt <andreas.rheinhardt@gmail.com>2020-11-12 16:13:48 +0100
committerAndreas Rheinhardt <andreas.rheinhardt@gmail.com>2020-11-15 18:17:36 +0100
commite83f27a21a6d2f602b55e541ef66e365400e9827 (patch)
treec75190e105ab102235ac87a15c7e0a364caa4fe4 /libavcodec/libtwolame.c
parent9f20e5d2819eec8dcdb8efb6cf92bc39d362e78f (diff)
downloadffmpeg-e83f27a21a6d2f602b55e541ef66e365400e9827.tar.gz
avformat/asfdec_o: Don't segfault with lots of attached pics
The ASF file format has a limit of 127 streams and the "asf_o" demuxer (the ASF demuxer from Libav) has an array of pointers for a structure called ASFStream that is allocated on demand for every stream. Attached pictures are not streams in the sense of the ASF specification, yet the demuxer created an ASFStream for them; and in one codepath it also forgot to check whether the array of ASFStreams is already full. The result is a write beyond the end of the array and a segfault lateron. Fixing this is easy: Don't create ASFStreams for attached picture streams. (Other results of the current state of affairs are unnecessary allocations (of ASFStreams structures), the misparsing of valid files (there might not be enough ASFStreams left for the valid streams if attached pictures take up too many); furthermore, the ASFStreams created for attached pictures all have the stream number 0, an invalid stream number (the valid range is 1-127). This means that invalid data (packets for a stream with stream number 0) won't get rejected lateron.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Diffstat (limited to 'libavcodec/libtwolame.c')
0 files changed, 0 insertions, 0 deletions