- 02 Jul, 2020 1 commit
-
-
Guo Yejun authored
(cherry-pick from fc932195ab0c9c00fa0cd9620c60763d978d495b) Signed-off-by:Guo, Yejun <yejun.guo@intel.com>
-
- 01 Jul, 2020 7 commits
-
-
Zhao Zhili authored
Fix two cases of memleaks: 1. The leak of dv_demux 2. The leak of dv_fctx upon dv_demux allocate failure Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com> (cherry picked from commit f3dc38a186b2326ce03e50969897ea703817ddb0) Signed-off-by:
-
Andreas Rheinhardt authored
The code for demuxing DV audio predates the introduction of refcounted packets and when the latter was added, changes to the former were forgotten. This meant that when avpriv_dv_produce_packet initialized the packet containing the AVBufferRef, the AVBufferRef as well as the underlying AVBuffer leaked; the actual packet data didn't leak: They were directly freed, but not via their AVBuffer's free function. https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4671/dir1.tar.bz2 contains samples for this (enable_drefs needs to be enabled for them). Moreover, errors in avpriv_dv_produce_packet were ignored; this has been changed, too. Furthermore, in the hypothetical scenario that the track has a palette, this would leak, too, so reorder the code so that the palette code appears after the DV audio code. Signed-off-by:
-
Andreas Rheinhardt authored
Fixes: assertion failure Fixes: left shift of 1 by 31 places cannot be represented in type 'int' Fixes: 23264/clusterfuzz-testcase-minimized-ffmpeg_BSF_AV1_METADATA_fuzzer-6308429248593920 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
-
Andreas Rheinhardt authored
Up until now, ff_avc_decode_sps would parse a SPS and return some properties from it in a freshly allocated structure. Yet said structure is very small and completely internal to libavformat, so there is no reason to use the heap for it. This commit therefore changes the function to return an int and to modify a caller-provided structure. This will also allow ff_avc_decode_sps to return better error codes in the future. It also fixes a memleak in mxfenc: If a packet contained multiple SPS, only the SPS structure belonging to the last SPS would be freed, the other ones would leak when the pointer is overwritten to point to the new SPS structure. Of course, without allocations there are no leaks. This is Coverity issue #1445194. Furthermore, the SPS structure has been renamed from H264SequenceParameterSet to H264SPS in order to avoid overlong lines. Reviewed-by:
Tomas Härdin <tjoppen@acc.umu.se> Signed-off-by:
-
Andreas Rheinhardt authored
Reviewed-by:
Michael Niedermayer <michael@niedermayer.cc> Signed-off-by:
-
Andreas Rheinhardt authored
Two kinds of errors can happen when working with dynamic buffers: (Re)allocation errors or truncation errors (one has to truncate the buffer to a size of INT_MAX because avio_close_dyn_buf() and avio_get_dyn_buf() both return an int). Right now, avio_get_dyn_buf() returns an empty buffer in either case. But given that avio_get_dyn_buf() does not destroy the dynamic buffer, one can return the buffer in case of truncation and let the user check the error flags and decide for himself instead of hardcoding a single way to proceed in case of truncation. (This actually restores the behaviour from before commit 163bb9ac.) Signed-off-by:
-
Andreas Rheinhardt authored
If adding two ints overflows, it doesn't matter whether the result will be stored in an unsigned or not; and checking afterwards does not make it retroactively defined. Signed-off-by:
-
- 15 Jun, 2020 29 commits
-
-
Michael Niedermayer authored
Fixes: assertion failure Fixes: 23422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5746026064642048 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
-
Andreas Rheinhardt authored
Only read str_size bytes from offset 30 of extradata if the extradata is indeed at least 30 + str_size bytes long. Signed-off-by: -
Andreas Rheinhardt authored
mov_read_custom tries to read three strings belonging to three different tags. When an already encountered tag is encountered again, a new buffer for the string to be read is allocated and stored in the pointer destined for this particular tag. But in this scenario, said pointer already holds the address of the string read earlier, leading to a leak. This commit therefore aborts the reading process upon encountering an already encountered tag. Signed-off-by: -
Andreas Rheinhardt authored
The argument pertaining to a printf %s conversion specifier must not be NULL, even if the precision (i.e. the number of characters to write) is zero. If it is NULL, it is undefined behaviour. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if allocating the AVStream for the subtitles fails. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle or when creating extradata. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon creating an AVStream. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle or when allocating extradata. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle or if creating the extradata failed. Signed-off-by: -
Andreas Rheinhardt authored
The already parsed subtitles (contained in an FFDemuxSubtitlesQueue) would leak if an error happened upon reading a subsequent subtitle. Signed-off-by: -
Andreas Rheinhardt authored
By default, a demuxer's read_close function is not called automatically if an error happens when reading the header; instead it is up to the demuxer to clean up after itself in this case. The mov demuxer did this by calling its read_close function when it encountered some errors when reading the header. Yet for other errors (mostly adding side-data to streams) this has been forgotten, so that all the internal structures of the demuxer leak. This commit fixes this by making sure mov_read_close is called when necessary. Signed-off-by: -
Andreas Rheinhardt authored
Fixes possible leaks of id3v2 metadata as well as an AVDES struct in case the content is encrypted and an error happens lateron. Signed-off-by: -
Andreas Rheinhardt authored
In certain error scenarios, the underlying Matroska demuxer was not properly closed, causing leaks. Signed-off-by: -
Andreas Rheinhardt authored
When demuxing a Matroska/WebM file, streams are added for tracks and for attachments, so that the array containing the former can be NULL even when the corresponding AVFormatContext has streams. So check for there to be tracks in the MatroskaDemuxContext instead of just streams in the AVFormatContext before dereferencing the pointer to the tracks. Signed-off-by: -
Andreas Rheinhardt authored
matroska_parse_block currently asserts that the duration is not equal to AV_NOPTS_VALUE, but there is nothing that actually guarantees this. It is easy to create (spec-compliant) files which run into this assert; so replace it and instead cap the duration to INT64_MAX, as the duration field of an AVPacket is an int64_t. Signed-off-by: -
Andreas Rheinhardt authored
EBML binary elements are already made reference-counted when read; so when populating the AVStream.attached_pic, one does not need to allocate a new buffer for the data; instead the current code just creates a new reference to the underlying AVBuffer. But this can be improved even further: Just move the already existing reference. This also fixes a memleak that happens upon error because matroska_read_close has not been called in this scenario. Signed-off-by: -
Andreas Rheinhardt authored
c801ab43 caused a regression: The stream number is now parsed with strtoll without a fixed basis; as a consequence, the "010" in a variant stream mapping like "a:010" is now treated as an octal number (i.e. as eight, not ten). This was not intended and may break some scripts, so this commit restores the old behaviour. Signed-off-by:
-
Andreas Rheinhardt authored
The hevc_mp4toannexb bsf does not explicitly check whether a NAL unit is so big that it extends beyond the end of the input packet; it does so only implicitly by using the checked version of the bytestream2 API. But this has downsides compared to real checks: It can lead to huge allocations (up to 2GiB) even when the input packet is just a few bytes. And furthermore it leads to uninitialized data being output. So add a check to error out early if it happens. Also check directly whether there is enough data for the length field. Reviewed-by:
-
- 14 Jun, 2020 3 commits
-
-
Michael Niedermayer authored
Name suggested by Kieran O Leary and Reto Kromer Signed-off-by: -
Michael Niedermayer authored
Fixes: memleak Fixes: 23415/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5124814510751744 Suggested-by:
Marton Balint <cus@passwd.hu> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
-
Michael Niedermayer authored
Fixes: assertion failure Fixes: 23434/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5227750851084288.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
-
