Freeing the new H.264 specific fields has been forgotten.
(This leak only appears in case the encoder has not been completely
drained.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, it has only been freed when the QSVFrame is reused,
so that the last one contained in it leaked at the end.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since commit 3bbe0c210b, the Payloads
array of every QSVFrame leaks as soon as the frame is reused;
the leak is small and not very noticeable, but if there is an attempt
to use said array the ensuing crash is much more noticeable.
This happens when encoding H.264 with A53 CC side data.
Furthermore, if said array can not be allocated at all, an AVFrame
leaks.
Fix all of this by not allocating the array separately at all; put it
in QSVFrame instead and restore the Payloads array upon reusing the
frame.
Finally, use av_freep() instead of av_free() to free the payload
entries.
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: Timeout
Fixes: 40481/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-6502647583080448
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In order to know that the earlier code did not use uninitialized
values one needs to know that the lowest four bits of each used
value of pframe_block4x4_coefficients_tab do not vanish identically.
E.g. Coverity did not get this and warned about it in ticket #1466632.
Fix this by slightly rewriting the code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The check for m->size >= 0xF000 is intended to avoid skipping too much
garbage data between JPEG frames in test_roman (thus missing next SOI),
but it erroneously also skips valid markers between SOI and SOS. Instead
of this, we should simply skip parsing markers other than SOI after EOI.
That way, we will not accidentally skip over SOI due to some garbage
between frames. There is still a small risk of encountering FFD8 in the
garbage data, but the chance of this is fairly low.
Fixes: https://trac.ffmpeg.org/ticket/8967
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
For dst->have_sse will be assigned by ctx->have_sse soon(code line 23).
Reviewed-by: James Zern <jzern-at-google.com@ffmpeg.org>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
C99/C11 6.3.2.3 5: "Any pointer type may be converted to an integer
type. [...] If the result cannot be represented in the integer type,
the behavior is undefined." So stop casting pointers to int; use
uintptr_t instead.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This context is transient, so putting it on the stack is more natural.
Also reduces codesize: 24E6->2296 B with GCC 10 and -O3.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add Branch Target Identifiers (BTIs) to all functions defined in
AArch64 assembly files. Most of the BTI landing pads are added
automatically by the 'function' macro.
BTI support is turned on or off at compile time based on the presence
of the __ARM_FEATURE_BTI_DEFAULT feature macro.
A binary compiled with BTI support can be executed on an Armv8-A
processor without BTI support because the instructions are defined in
NOP space.
Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>
Signed-off-by: Elijah Ahmad <elijah.ahmad@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Change AArch64 assembly code to use:
ret x<n>
instead of:
br x<n>
"ret x<n>" is already used in a lot of places so this patch makes it
consistent across the code base. This does not change behavior or
performance.
In addition, this change reduces the number of landing pads needed in
a subsequent patch to support the Armv8.5-A Branch Target
Identification (BTI) security feature.
Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
There is no reason to wrap them in #ifndef guards, they should only be
defined here and nowhere else. The define guards just add the
possibility to accidentally use the same FF_API name in different
libraries.
Fixes: signed integer overflow: 2105344 * 539033345 cannot be represented in type 'int'
Fixes: out of array write
Fixes: 39956/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-4766419250708480
Fixes: 40293/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-5219910217760768
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
x264.h: "the payloads of all output NALs are guaranteed to be
sequential in memory." Therefore we can omit the loop.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Always false since this encoder was switched to encode2 and
ff_alloc_packet() in 06484d0b8a
and f2b20b7a8b.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In function vtenc_populate_extradata(), there is a manually created
pixel buffer that has not been released. So we should use CVPixelBufferRelease
to release this pixel buffer at the end, otherwise will cause a memory leak.
Signed-off-by: Rick Kern <kernrj@gmail.com>
Andreas Rheinhardt
Michael Niedermayer
James Almer
rcombs
Alex Xu (Hello71)
Limin Wang
Matt Oliver
Derek Buitenhuis
Jonathan Wright
Anton Khirnov
Paul B Mahol
songyutong