Fixes: shift exponent 4294967163 is too large for 32-bit type 'int'
Fixes: 41449/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6183636217495552
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit a4af92d7cb044424d31a99fc2f8a091f882036a5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 40284/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP3_fuzzer-4599568176644096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 96caa01f130526cb420d0706a40fb63695153128)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -776522110086937600 * 16 cannot be represented in type 'long'
Fixes: 40563/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6644829447127040
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 3a64a4c58255d45e05eff80c9464ad3bdc2d6463)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: integer overflow
Fixes: 40313/clusterfuzz-testcase-minimized-ffmpeg_dem_AIFF_fuzzer-4814761406103552
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 905588df975071c03c00b2e923c311b4de65a8f4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 93f7776921ed8c5219732210067016c3457e864d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 1b04836dff9958e8bfdbed2746b8c40b1e119ecc)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We still own it on failure, and there's no point trying to feed it again.
This should address the issue reported in dav1d #383 and part of VLC #26259.
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 141f3053ba0fdb40971cf0700d0115631fca9949)
The DNXHD encoder's context contains an array of 32 pointers to
DNXHDEncContexts used in case of slice threading; when trying
to use more than 32 threads with slice threading, the encoder's init
function errors out, but the close function takes avctx->thread_count
at face value and tries to free inexistent elements of the array,
leading to potential crashes.
Fix this by modifying the check used to decide whether the slice
contexts should be freed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit eb583b3cb98797e8e815b7432f90cae8e8d52794)
ff_wma_init() can fail without freeing everything it has allocated;
so add the FF_CODEC_CAP_INIT_CLEANUP to the codecs using it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit fcdb012a100b245890949b2d53cb7f042380787d)
Currently an error from init could be overwritten by successfully
setting the enable expression.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 10ad3cd7982e5a5d922cabd176c97571a7684c60)
silk_lsp2poly()'s declaration contained arrays with array sizes;
yet these array sizes exceeded the number of actually accessed array
elements (which is related to another parameter) and this leads to
-Wstringop-overflow= warnings from GCC 11, because the arrays provided
by callers are only large enough for the actually used elements.
So replace the incorrect array sizes with comments containing
the correct array sizes. Given that these sizes are not compile-time
constants, they can only be communicated via a comment.
Reported by Paul B Mahol.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 4b154743163ffbe3fdc50759c0c55dc854636488)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 874f03fae7618e61aec34a0739404559245abd09)
The terminating '\0' is no longer included in the size of
the extradata output by the demuxer since commit
36e61e24e7ac737b38c4382d439329352d9e0c29.
E.g. if one remuxes the JACOsub sample JACOsub_capability_tester.jss
from the FATE suite, one receives a file not recognized as JACOsub
before this patch.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 54e8dcce8e5fce245715aafe1768beb0b6aa49f5)
Do this by using the AVStream's priv_data for the buffer holding
the packet size data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit d94b641b4a3ac3cbb009c8818b0eaf3e15795dca)
If an array for the packet sizes could not be successfully reallocated
when writing a packet, the CAF muxer frees said array, but does not
reset the number of valid bytes. As a result, when the trailer is
written later, avio_write tries to read that many bytes from NULL,
which segfaults.
Fix this by not freeing the array in case of error; also, postpone
writing the packet data after having successfully (re)allocated the
array, so that even on allocation error the file can be correctly
finalized.
Also remove an unnecessary resetting of the number of size entries
used at the end.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 19a6b51fe61b915b734319b5d917192108df8188)
(As long as avio_write() only accepts an int, it makes no sense
to try to support sizes that don't fit into an int.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 42fe438482dd0f1f59d86e27a88a616ad966706b)
There can only be a maximum of 255 entries in a tfrf tag, so using
more makes no sense; moreover, several size computations can overflow
in this case. Fix this by limiting it to 255.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 1cf3c59b58f4380d5ce166a67331777891d06eef)
avutil_version() currently performs several checks before
just returning the version. There is a static int that aims
to ensure that these tests are run only once. The reason is that
there used to be a slightly expensive check, but it has been removed
in 92e3a6fdac73f7e1d69d69717219a7538877d7a0. Today running only
once is unnecessary and can be counterproductive: GCC 10 optimizes
all the actual checks away, but the checks_done variable and the code
setting it has been kept. Given that this check is inherently racy
(it uses non-atomic variables), it is best to just remove it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit ff800903747325f15056444c11053279e391d60b)
Up until now, the scc demuxer not only read the line that it intends
to process, but also the next line, in order to be able to calculate
the duration of the current line. This approach leads to unnecessary
complexity and also to bugs: For the last line, the timing of the
next subtitle is not only logically indeterminate, but also
uninitialized and the same applies to the duration of the last packet
derived from it.* Worse yet, in case of e.g. an empty file, it is not
only the duration that is uninitialized, but the whole timing as well
as the line buffer itself.** The latter is used in av_strtok(), which
could lead to crashes. Furthermore, the current code always outputs
at least one packet, even for empty files.
This commit fixes all of this: It stops using two lines at a time;
instead only the current line is dealt with and in case there is
a packet after that, the duration of the last packet is fixed up
after having already parsed it; consequently the duration of the
last packet is left in its default state (meaning "unknown/up until
the next subtitle"). If no further line could be read, processing
is stopped; in particular, no packet is output for an empty file.
*: Due to stack reuse it seems to be zero quite often; for the same
reason Valgrind does not report any errors for a normal input file.
**: While ff_subtitles_read_line() claims to always zero-terminate
the buffer like snprintf(), it doesn't do so if it didn't read anything.
And even if it did, it would not necessarily help here: The current
code jumps over 12 bytes that it deems to have read even when it
hasn't.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 60e12318bb9372b3053703f2a3b849270b9d2fe5)
It claims to always zero-terminate its buffer like snprintf(),
yet it does it not on EOF. Because of this the mcc demuxer
used uninitialized values when reading an empty input file.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 8766361fc16b6d25ee8be880bf55c9761490cb99)
Happened for all slaves which didn't use the FIFO.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 3a27fcb168af07f168e58577f6b3696a8fe74803)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit cd1aaec760273bd7673b27609f114599e2d9b5a9)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 0429d8eed85674ae19cccab81f7fbb13a4ccc705)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit bae96fa9776cf35cdf32f285f2a980b31e63560a)
Fix this by switching to av_dynarray_add_nofree() which is more
natural anyway because the entries of the array are pointers.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 05c1f78a72916ef2466cc5a4fc778810503225ee)
av_image_copy() expects an array of four pointers according to its
declaration; although it currently only touches pointers that
are actually in use (depending upon the pixel format) this might
change at any time (as has already happened for the linesizes
in d7bc52bf456deba0f32d9fe5c288ec441f1ebef5).
This fixes ticket #9264 as well as a warning from GCC 11.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 9b17273c77ee2868ef34abc49efa70260453235b)
When an flite filter instance is uninitialized and the refcount
of the corresponding voice_entry reaches zero, the voice is
unregistered, yet the voice_entry's pointer to the voice is not reset.
(Whereas some other pointers are needlessly reset.)
Because of this a new flite filter instance will believe said voice
to already be registered, leading to use-after-frees.
Fix this by resetting the right pointer instead of the wrong ones.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 18ddb25c7a58404641de2f6aa68220bd509e376c)
Could also happen if initializing flite failed* or if an unknown voice
has been selected or if registering the voice failed.
*: which it currently can't, because it is a no-op.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 304cc0379870ebf155502069939582f1065ef3b5)
This reverts commit 723c37d3b7b5555f23bfdfe3e5c3599543c06332.
Said commit was in preparation for auto-inserting the idet filter.
This has never happened; even if it did, the code is wrong, because
it segfaults if the filter instance doesn't have a name (having one
is not mandatory). Furthermore, it is documented for libavfilter to
not assign any semantics to the name, which this check violates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit f626a3d0e0e6c59af4e844c7e2d308a93ea8c3e2)
h263_get_motion_length() forgot to take an absolute value;
as a consequence, a negative index was used to access an array.
This leads to potential crashes, but mostly it just accesses what
is to the left of ff_mvtab (unless one uses ASAN), thereby defeating
the purpose of the AV_CODEC_FLAG2_NO_OUTPUT because the sizes of
the returned packets differ from the sizes the encoder would actually
have produced.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 9207dc3b0db368bb9cf5eb295cbc1129c2975e31)
Fixes ticket #9537.
Probably a regression since 2b3206891649f317c20993411efef4bee39ae784.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit d1b47f3bfcc625ca1cae210fc198dcbd54381a88)
Regression since af043b839c38e850af1184fd6be691f8475c048e.
Fixes ticket #9409.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit bb89a2f64fd1d74cc51af62d5ef133be274dd7af)
av_image_copy() expects an array of four pointers and linesizes
according to its declaration; it currently only pointers that are
actually in use (depending upon the pixel format), but this might
change at any time. It has already happened for the linesizes in
d7bc52bf456deba0f32d9fe5c288ec441f1ebef5 and so increasing their
array fixes a stack-buffer overread.
This fixes a -Wstringop-overflow= and -Wstringop-overread warning
from GCC 11.2.
Reviewed-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit b0b90100bfda8c5cf95889e00183589de0abce60)
av_image_copy() expects an array of four pointers according to its
declaration; although it currently only touches pointers that
are actually in use (depending upon the pixel format) this might
change at any time (as has already happened for the linesizes
in d7bc52bf456deba0f32d9fe5c288ec441f1ebef5).
This fixes a -Wstringop-overflow= warning with GCC 11.2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit b09ea67b40e342f5e4183e9ebc0c14801ecd218c)
Due to this bush.aa (from the FATE suite) exported garbage metadata
with key "_040930".
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 0a76f8217e0d80d336ad8d9c46523fd3d1262c8c)
Forgotten in 555f5c1fc5ae0c4e7b0431dc3166c3fcf3f4e979.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit df4cb384fb68454e23f8cc2b369e344c1bd8be7d)
