aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/xan.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>2021-02-27 07:20:59 +0100
commit9475175ec0da425955e0ada4c8d43453215f6c8b (patch)
treec42901a4090d79fc891c9fa82f2f9e0971ef01f2 /libavcodec/xan.c
parent2eb76188d03767eb782918fcd6c93a82429ddad0 (diff)
downloadffmpeg-9475175ec0da425955e0ada4c8d43453215f6c8b.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> (cherry picked from commit e83f27a21a6d2f602b55e541ef66e365400e9827)
Diffstat (limited to 'libavcodec/xan.c')
0 files changed, 0 insertions, 0 deletions