- 08 Apr, 2021 27 commits
-
-
Michael Niedermayer authored
Name suggested by Lynne, Gyan, Reto, Zane, Jan, Derek Signed-off-by:Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: out of array read Fixes: 32968/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSP2_fuzzer-5315296027082752 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by:
-
Michael Niedermayer authored
Fixes: Invalid read of size 4 Fixes: ASAN_Deadlysignal.zip Found-by:
Hardik Shah <hardik05@gmail.com> Signed-off-by:
-
Anton Khirnov authored
Calling av_frame_make_writable() from decoders is tricky, especially when frame threading is used. It is much simpler and safer to just make a private copy of the frame. This is not expected to have a major performance impact, since APNG_DISPOSE_OP_BACKGROUND is not used often and av_frame_make_writable() would typically make a copy anyway. Found-by:
James Almer <jamrial@gmail.com> Signed-off-by:
-
Marton Balint authored
Signed-off-by:
Marton Balint <cus@passwd.hu> (cherry picked from commit fb4da90f)
-
Marton Balint authored
Ugly, but a lot less broken than it was. Fixes ticket #9166. Signed-off-by:
-
Anton Khirnov authored
The length does not cover the chunk type or CRC. (cherry picked from commit ae08eec6 ) Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Anton Khirnov authored
This data cannot be stored in PNGDecContext.picture, because the corresponding chunks may be read after the call to ff_thread_finish_setup(), at which point modifying shared context data is a race. Store intermediate state in the context and then write it directly to the output frame. Fixes exporting frame metadata after 56633015 Fixes #8972 Found-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com> (cherry picked from commit 8d74bacc ) Signed-off-by:
-
Anton Khirnov authored
Do not store the image buffer pointer/linesize in the context, just access them directly from the frame. Stop assuming that linesize is the same for the current and last frame. (cherry picked from commit 89ea5057 ) Signed-off-by:
-
Anton Khirnov authored
Saves an allocation+free and two frame copies per each frame. (cherry picked from commit 5a50bd88 ) Signed-off-by:
-
Andreas Rheinhardt authored
The (deprecated) field AVCodecContext.mpeg_quant has no range restriction; MpegEncContext.mpeg_quant is restricted to 0..1. If the former is set, the latter is overwritten with it without checking the range. This can trigger an av_assert2() with the MPEG-4 encoder when writing said field. Fix this by just setting MpegEncContext.mpeg_quant to 1 if AVCodecContext.mpeg_quant is set. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@outlook.com> (cherry picked from commit d393c450)
-
Andreas Rheinhardt authored
The pix_fmts of the LJPEG encoder already contain all supported pixel formats (including the ones only supported when strictness is unofficial or less); yet the check in ff_encode_preinit() ignored this list in case strictness is unofficial or less. But the encoder presumed that it is always applied and blacklists some of the entries in pix_fmts when strictness is > unofficial. The result is that if one uses an entry not on that list and sets strictness to unofficial, said entry passes both checks and this can lead to segfaults lateron (e.g. when using gray). Fix this by removing the exception for LJPEG in ff_encode_preinit(). Signed-off-by:
-
Andreas Rheinhardt authored
Signed-off-by:
-
Andreas Rheinhardt authored
For both the RealMedia as well as the IVR demuxer (which share the same context) each AVStream's priv_data contains an AVPacket that might contain data (even when reading the header) and therefore needs to be unreferenced. Up until now, this has not always been done: The RealMedia demuxer didn't do it when allocating a new stream's priv_data failed although there might be other streams with packets to unreference. (The reason for this was that until recently rm_read_close() couldn't handle an AVStream without priv_data, so one had to choose between a potential crash and a memleak.) The IVR demuxer meanwhile never ever called read_close so that the data already contained in packets leaks upon error. This patch fixes both demuxers by adding the appropriate cleanup code. Signed-off-by:
-
Andreas Rheinhardt authored
ff_vc1_decode_init_alloc_tables() had one error path that forgot to free already allocated buffers; these would then be overwritten on the next allocation attempt (or they would just not be freed in case this happened during init, as the decoders for which it is used do not have the FF_CODEC_CAP_INIT_CLEANUP set). Signed-off-by:
-
Andreas Rheinhardt authored
The RealVideo 3.0 and 4.0 decoders call ff_mpv_common_init() only during their init function and not during decode_frame(); when the size of the frame changes, they call ff_mpv_common_frame_size_change(). Yet upon error, said function calls ff_mpv_common_end() which frees the whole MpegEncContext and not only those parts that ff_mpv_common_frame_size_change() reinits. As a result, the context will never be usable again; worse, because decode_frame() contains no check for whether the context is initialized or not, it is presumed that it is initialized, leading to segfaults. Basically the same happens if rv34_decoder_realloc() fails. This commit fixes this by only resetting the parts that ff_mpv_common_frame_size_change() changes upon error and by actually checking whether the context is in need of reinitialization in ff_rv34_decode_frame(). Reviewed-by:
-
Andreas Rheinhardt authored
In case of resolution changes rv20_decode_picture_header() closes and reopens its MpegEncContext; it checks the latter for errors, yet when an error happens, it might happen that no new attempt at reinitialization is performed when decoding the next frame; this leads to crashes lateron. This commit fixes this by making sure that initialization will always be attempted if the context is currently not initialized. Reviewed-by:
-
Andreas Rheinhardt authored
Reviewed-by:
-
Andreas Rheinhardt authored
When slice-threading is used, ff_mpv_common_init() duplicates the first MpegEncContext and allocates some buffers for each MpegEncContext (the first as well as the copies). But the count of allocated MpegEncContexts is not updated until after everything has been allocated and if an error happens after the first one has been allocated, only the first one is freed; the others leak. This commit fixes this: The count is now set before the copies are allocated. Furthermore, the copies are now created and initialized before the first MpegEncContext, so that the buffers exclusively owned by each MpegEncContext are still NULL in the src MpegEncContext so that no double-free happens upon allocation failure. Given that this effectively touches every line of the init code, it has also been factored out in a function of its own in order to remove code duplication with the same code in ff_mpv_common_frame_size_change() (which was never called when using more than one slice (and if it were, there would be potential double-frees)). Reviewed-by:
-
Andreas Rheinhardt authored
This mostly reverts commit 4b2863ff. Said commit removed the freeing code from ff_mpv_common_init(), ff_mpv_common_frame_size_change() and ff_mpeg_framesize_alloc() and instead added the FF_CODEC_CAP_INIT_CLEANUP to several codecs that use ff_mpv_common_init(). This introduced several bugs: a) Several decoders using ff_mpv_common_init() in their init function were forgotten: This affected FLV, Intel H.263, RealVideo 3.0 and V4.0 as well as VC-1/WMV3. b) ff_mpv_common_init() is not only called from the init function of codecs, it is also called from AVCodec.decode functions. If an error happens after an allocation has succeeded, it can lead to memleaks; furthermore, it is now possible for the MpegEncContext to be marked as initialized even when ff_mpv_common_init() returns an error and this can lead to segfaults because decoders that call ff_mpv_common_init() when decoding a frame can mistakenly think that the MpegEncContext has been properly initialized. This can e.g. happen with H.261 or MPEG-4. c) Removing code for freeing from ff_mpeg_framesize_alloc() (which can't be called from any init function) can lead to segfaults because the check for whether it needs to allocate consists of checking whether the first of the buffers allocated there has been allocated. This part has already been fixed in 76cea1d2 . d) ff_mpv_common_frame_size_change() can also not be reached from any AVCodec.init function; yet the changes can e.g. lead to segfaults with decoders using ff_h263_decode_frame() upon allocation failure, because the MpegEncContext will upon return be flagged as both initialized and not in need of reinitialization (granted, the fact that ff_h263_decode_frame() clears context_reinit before the context has been reinited is a bug in itself). With the earlier version, the context would be cleaned upon failure and it would be attempted to initialize the context again in the next call to ff_h263_decode_frame(). While a) could be fixed by adding the missing FF_CODEC_CAP_INIT_CLEANUP, keeping the current approach would entail adding cleanup code to several other places because of b). Therefore ff_mpv_common_init() is again made to clean up after itself; the changes to the wmv2 decoder and the SVQ1 encoder have not been reverted: The former fixed a memleak, the latter allowed to remove cleanup code. Fixes: double free Fixes: ff_free_picture_tables.mp4 Fixes: ff_mpeg_update_thread_context.mp4 Fixes: decode_colskip.mp4 Fixes: memset.mp4 Reviewed-by:
-
Andreas Rheinhardt authored
There might be segfaults on failure. Signed-off-by:
-
Andreas Rheinhardt authored
If only one of the two arrays used for the ICC profile could be successfully allocated, it might be overwritten and leak when the next ICC entry is encountered. Fix this by using a common struct, so that one has only one array to allocate. Signed-off-by:
-
Andreas Rheinhardt authored
In this case it also fixes a potential for compilation failures: Not all compilers can handle the case in which a function with a forward declaration declared with an attribute to always inline it is called before the function body appears. E.g. GCC 4.2.1 on OS X 10.6 doesn't like it. Reviewed-by:
Pavel Koshevoy <pkoshevoy@gmail.com> Signed-off-by:
-
Andreas Rheinhardt authored
Signed-off-by:
-
Andreas Rheinhardt authored
Up until now, initializing the mutexes/condition variables wasn't checked by ff_frame_thread_init(). This commit changes this. Given that it is not documented to be save to destroy a zeroed but otherwise uninitialized mutex/condition variable, one has to choose between two approaches: Either one duplicates the code to free them in ff_frame_thread_init() in case of errors or one records which have been successfully initialized. This commit takes the latter approach: For each of the two structures with mutexes/condition variables an array containing the offsets of the members to initialize is added. Said array is used both for initializing and freeing and the only thing that needs to be recorded is how many of these have been successfully initialized. Signed-off-by:
-
Andreas Rheinhardt authored
In case an error happened when setting up the child threads, ff_frame_thread_init() would up until now call ff_frame_thread_free() to clean up all threads set up so far, including the current, not properly initialized one. But a half-allocated context needs special handling which ff_frame_thread_frame_free() doesn't provide. Notably, if allocating the AVCodecInternal, the codec's private data or setting the options fails, the codec's close function will be called (if there is one); it will also be called if the codec's init function fails, regardless of whether the FF_CODEC_CAP_INIT_CLEANUP is set. This is not supported by all codecs; in ticket #9099 it led to a crash. Signed-off-by:
-
Andreas Rheinhardt authored
Signed-off-by:
-
- 03 Apr, 2021 12 commits
-
-
Mark Plomer authored
Some old DV AVI files have the DSF-Flag of frames set to 0, although it is PAL (maybe rendered with an old Ulead Media Studio Pro) ... this causes ffmpeg/VLC-player to produce/play corrupted video (other players/editors like VirtualDub work fine). Fixes ticket #8333 and replaces/extends hack for ticket #2177 Signed-off-by:
-
Michael Niedermayer authored
This avoids use of uninitialized data also several checks are inside the band reading code so it is important that it is run at least once Fixes: out of array accesses Fixes: 28209/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5684714694377472 Fixes: 32124/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5425980681355264 Fixes: 30519/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-4558757155700736 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by:
-
Michael Niedermayer authored
Previously the code skipped all security checks when these where encountered but prior data was incorrect. Also replace an always true condition by an assert Signed-off-by:
-
Michael Niedermayer authored
Fixes: out of array accesses Fixes: 29754/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-6333598414274560 Fixes: 30519/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-6298424511168512 Fixes: 30739/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5011292836462592 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by:
-
Alan Kelly authored
Signed-off-by:
-
Alan Kelly authored
Signed-off-by:
-
Alan Kelly authored
Signed-off-by:
-
Andreas Rheinhardt authored
Reviewed-by:
-
Andreas Rheinhardt authored
When using external Huffman tables fails during init, the decoder reverts back to using the default Huffman tables; and when doing so, the current VLC tables leak because init_default_huffman_tables() doesn't free them before overwriting them. Sample: samples.ffmpeg.org/archive/all/avi+mjpeg+pcm_s16le++mjpeg-interlace.avi Reviewed-by:
-
Andreas Rheinhardt authored
render_charset() used static buffers that are always completely initialized before every use, so that it is unnecessary for the values in these arrays to be kept after leaving the function. Given that this is not only unnecessary, but harmful due to the possibility of data races if several instances of a64multi/a64multi5 run simultaneously these buffers have been replaced by ordinary buffers on the stack (they are small enough for this). Signed-off-by:
-
Andreas Rheinhardt authored
Signed-off-by:
-
Andreas Rheinhardt authored
The current code tries the access the codecpar of a nonexistent audio stream when seeking. Stop that. Fixes ticket #9121. Signed-off-by:
-
- 02 Apr, 2021 1 commit
-
-
Andreas Rheinhardt authored
Fixes potential heap-buffer-overflow. Signed-off-by:
-
