Fixes: overflow in aspect ratio calculation
Fixes: signed integer overflow: 393215 * 14594 cannot be represented in type 'int'
Fixes: 15728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5661588893204480
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 181e138da7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
"9.1.1.43 P Reference Distance (REFDIST)"
"The value of REFDIST shall be less than, or equal to, 16."
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 7f7af9e294)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: signed integer overflow: -14527961 - 2147483425 cannot be represented in type 'int'
Fixes: 16380/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5645957131141120
Fixes: 16968/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5716169901735936
Fixes: 17074/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5198710497083392
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 1e95a3e8a7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Values larger would fail subsequent tests.
Fixes: signed integer overflow: 5 + 2147483646 cannot be represented in type 'int'
Fixes: 16966/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5695709549953024
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 f63cd1963e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Infinite loop
Fixes: signed integer overflow: 2147483644 + 16 cannot be represented in type 'int'
Fixes: 16169/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5662570416963584
Fixes: 16782/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5743163859271680
Fixes: 17641/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-5711603562971136
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 87ddf9f1ef)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
4650975 -> 4493240 dezicycles
This optimizes lines 2 and later. Line 1 still uses av_memcpy_backptr()
This change originally fixed ossfuzz 10790 but this is now fixed by other
optimizations already
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 95e5396919)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The specification does not seem to list what the maximum valid
value is
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 16268/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5638164544225280
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 e125578994)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A threshold of 1 is sufficient for simple_dump_cut.webm, 10 is used
just to be sure the next truncated file doesnt cause the same issue
Obvious alternative fixes are to simply accept that the file is broken or to
write some advanced error concealment or to
simply accept that the decoder wont stop at the end of input.
Fixes: Ticket 8069 (artifacts not the differing md5 which was there before 1afd246960)
Fixes: simple_dump_cut.webm
Fixes: regression of 1afd246960
fate-vp5 changes because the last frame is truncated and now handled
differently.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b6b9ac5698)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Because the lavf_container is sometimes called with only 2 arguments,
fate tests produce bash errors like this:
tests/fate-run.sh: 299: test: =: unexpected operator
This commit fixes this.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6d9d053edb)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ProRes in Matroska is supposed to not contain the first atom header
(containing a size field and the tag "icpf") and therefore the Matroska
demuxer has to recreate it; this involves an allocation and copy, of
course. Whether the old buffer (containing the data without the atom
header) needs to be freed or not depends upon whether it is what was
directly read (in which case it is owned by an AVBuffer) or whether it
has been allocated when reversing the track's content compression (e.g.
zlib compression) that Matroska supports.
So there are three pointers involved: The one pointing to the directly
read data (owned by the AVBuffer), the one pointing to the currently
valid data (which coincides with the former if no content compression
needed to be reverted) and the one pointing to the new data with the
first atom header. The check for whether to free the second of these is
simply whether the first two are different.
This works mostly, but there is a complication: Some muxers don't strip
the first atom header away and in this case, it is also not reinserted
and no new buffer is allocated; instead, the second and the third
pointers agree. In this case, one must never free the second buffer.
Yet it is currently done if the track is e.g. zlib compressed.
This commit fixes this.
This is a regression since b8e75a2a.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit af50f0a515)
The structure of a ProRes frame in mov/mp4 is that of a typical atom:
First a 32 bit BE size field, then a tag detailling the content. Said
size field includes the eight bytes of the atom header.
This header is actually redundant, as the size of the atom is already
known from the containing atom. It is therefore stripped away when muxed
into Matroska and so the Matroska demuxer has to recreate upon demuxing.
But it did not account for the fact that the size field includes the
size of the header and this can lead to problems when a decoder uses the
in-band size field.
Fixes ticket #8210.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 581419ea39)
Taking into account the code
fb(2, ar_coeff_lag);
num_pos_luma = 2 * current->ar_coeff_lag * (current->ar_coeff_lag + 1);
if (current->num_y_points)
num_pos_chroma = num_pos_luma + 1;
else
num_pos_chroma = num_pos_luma;
Max value for ar_coeff_lag is 3 (two bits), for num_pos_luma 24, and for
num_pos_chroma 25.
Both ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128 may have up to
num_pos_chroma values.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit a23dd33606)
In the worst case the startcode prefix has 4 bytes.
This fixes a trigerred assertion:
Assertion dp <= max_size failed at libavcodec/cbs_h2645.c:1451
Found-by:libFuzzer
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
(cherry picked from commit 02a83e26de)
