There are two possible kinds of timecode tracks (with tag "tmcd") in the
mov muxer: Tracks created internally by the muxer and timecode tracks
sent by the user. If any of the latter exists, the former are
deactivated. The former all belong to another track, the source
track; the latter don't have a source track set, but the index of the
source track is initially zeroed by av_mallocz_array(). This is a
problem since 3d894db700: Said commit added
a function that calculates the duration of tracks and the duration of
timecode tracks is calculated by rescaling the duration (calculated by
the very same function) of the source track. This gives an infinite
recursion if the first track (the one that will be treated as source
track for all timecode tracks) is a timecode track itself, leading to a
stack overflow.
This commit fixes this by not using the nonexistent source track
when calculating the duration of timecode tracks not created internally
by the mov muxer.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 22a2386a56)
Allocating an AVCodecContext's priv_data used to be the first object
allocated in avcodec_open2(), so it was unnecessary to goto free_and_end
(which does the cleanup) upon error here. But this is no longer so since
f3a29b750a.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit d1dcc20126)
Don't check for AVCodec.priv_data_size (which is always true if
AVCodec.priv_class is set). Instead check for AVCodecContext.priv_data
to actually exist.
(Note: av_opt_free(NULL) is a no-op.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit c6e54d14c5)
Fixes ticket #8219.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 9d8f9b2e40)
avcodec_open2() also called the AVCodec's close function if an error
happened before init had ever been called if the AVCodec has the
FF_CODEC_CAP_INIT_CLEANUP flag set. This is against the documentation of
said flag: "The codec allows calling the close function for deallocation
even if the init function returned a failure."
E.g. the SVQ3 decoder is not ready to be closed if init has never been
called.
Fixes: NULL dereference
Fixes: 25762/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ3_fuzzer-5716279070294016
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 5bc74d06da)
The earlier code would first attempt to allocate two buffers, then
attempt to allocate an AVIOContext, using one of the new buffers I/O
buffer, then check the allocations. On success, a z_stream that is used
in the AVIOContext's read_packet callback is initialized afterwards.
There are two problems with this: In case the allocation of the I/O
buffer fails avio_alloc_context() will be given a NULL read buffer
with a size > 0. This works right now, but it is fragile. The second
problem is that the z_stream used in the read_packet callback is not
functional when avio_alloc_context() is allocated (it might be that
avio_alloc_context() might already fill the buffer in the future). This
commit fixes both of these problems by reordering the operations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 3f04c30372)
When using one of the AV_DICT_DONT_STRDUP_KEY/VAL flags, av_dict_set()
already frees the key/value on error, so that freeing it again would
lead to a double free.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit e09e2c6442)
The tedcaptions demuxer uses an AVBPrint whose string is not restricted
to its internal buffer; it therefore needs to be cleaned up, yet this is
not done on error, as parse_file() returned simply returned directly.
This is fixed by going to fail first in such cases.
Furthermore, there is also a second way how this string can leak: By
having more than one subtitle per subtitle block, as the new one simply
overwrites the old one in this case as the AVBPrint is initialized each
time upon encountering a subtitle line. The code has been modified to
simply append the new subtitle to the old one, so that the old one can't
leak any more.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 9f7e592df2)
The SWF muxer accepts at most one mp3 audio and at most one VP6F, FLV1
or MJPEG stream. Upon encountering an mp3 stream, a fifo is allocated
that leaks if one of the subsequent streams is incompliant with the
restrictions mentioned above or if the framerate or samplerate are
invalid. This is fixed by adding a deinit function to free said fifo.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit d554aabdaf)
The RealMedia demuxer uses the priv_data of its streams to store a
structure containing an AVPacket. These packets are unreferenced in the
read_close function, yet said function simply presumed that the
priv_data has been successfully allocated. This implies that it mustn't
be called when an allocation of priv_data fails; but this can happen
since commit 35bbc1955a if one has a
stream with multiple substreams (also exported as AVStream) and if
allocating the priv_data for one of these substreams fails.
This has been fixed by making sure that read_close can handle the case
in which priv_data has not been successfully allocated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 5aafdb4e5f)
The RealMedia demuxer's read_header function initially initializes ret,
the variable designated for the return variable to -1. Afterwards, chunks
of the file are parsed in a loop until an error happens or until the actual
frame data is encountered. If the first function whose return
value is put into ret doesn't fail, then ret contains a value >= 0
(actually == 0) and this is what will be returned if an error is
encountered afterwards.
This is a regression since 35bbc1955a.
Before that, ret had never been overwritten with a nonnegative value.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 4cc43d30c3)
After all, allocating an AVFloatDSPContext might have failed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit dac9e88a99)
The JPEG2000 encoder did not clean up after itself on error.
This commit fixes this by modifying the cleanup function to be able to
handle only partially allocated structures and by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 3d83de4187)
Up until now, the flashsv encoder tried to allocate two buffers in its
init function; if only one of these allocations succeeds, the other
buffer leaks. Fix this by making one of these buffers part of the
context (its size is a compile-time constant).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit ec6f4c5158)
The ac3 encoders (fixed- and floating-point AC-3 as well as the EAC-3
encoder) all allocate an array whose elements are pointers to other
buffers. The array is not zeroed initially so that if an allocation of
one of the subbuffers fails, the other pointers are uninitialized.
This causes problems when cleaning, so zero the array initially.
(Only the fixed-point AC-3 encoder was affected by this, because
the other two don't clean up at all in case of errors during init.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit ae36fad624)
The very first thing the SVQ3 decoder currently does is allocating several
SVQ3Frames, a structure which contains members that need to be freed on
their own. If one of these allocations fails, the decoder calls its own
close function to not leak the already allocated SVQ3Frames. Yet said
function presumes that the SVQ3Frames have been successfully allocated
as there is no check before freeing the members that need to be freed.
This commit fixes this by making these frames part of the SVQ3Context,
thereby avoiding the allocations altogether. Notice that the pointers
to the frames have been retained in order to allow to just swap them as
the code already does.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 96061c5a4f)
The Sonic decoder and encoders allocate several buffers in their init
function and return immediately if one of these allocations fails; this
will lead to leaks if there was an earlier successfull allocation. Fix
this by setting the FF_CODEC_CAP_INIT_CLEANUP flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 7d91f9271e)
The qtrle encoder allocates several buffers and an AVFrame in its init
function. If one of these allocations fails, but others succeed, the
successfully allocated objects leak. This is fixed by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 2a71cbeb01)
The FFV1 encoder has so far not cleaned up after itself in this case;
but it can be done easily by setting the FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit f9215d0bb2)
When allocating FFV1 slice contexts fails, ff_ffv1_init_slice_contexts()
frees everything that it has allocated, yet it does not reset the
counter for the number of allocated slice contexts. This inconsistent
state leads to segfaults lateron in ff_ffv1_close(), because said
function presumes that the slice contexts have been allocated.
Fix this by making sure that the number of slice contexts on error is
consistent (namely zero).
(This issue only affected the FFV1 decoder, because the encoder does not
clean up after itself on init failure.)
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit a0750f412a)
If an error happens during init after an allocation has succeeded,
the already allocated data leaked up until now. Fix this by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit b78031cf16)
ff_ivi_init_planes() might error out after having allocated some arrays.
Set the FF_CODEC_CAP_INIT_CLEANUP flag in order to free these arrays in
this case.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit d8fc69bd6a)
If allocating the tiles array for indeo 4/5 fails, the context is in an
inconsistent state, because the counter for the number of tiles is > 0.
This will lead to a segfault when freeing the tiles' substructures.
Fix this by setting the number of tiles to zero if the allocation was
unsuccessful.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit e411a3af11)
If an error happens during init after an allocation has succeeded,
the already allocated data leaked up until now. Fix this by setting the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit a8ebb56320)
If one of several allocations the gif encoder performs in its init
function fails, the successful allocations leak. Fix this by adding the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 8da8774d8e)
If ff_codec_open2_recursive() fails, the already allocated
AVCodecContext leaks. Fix this by setting the FF_CODEC_CAP_INIT_CLEANUP
flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 3c2128df7f)
init_subtitles() sometimes returned directly upon error without cleaning
up after itself. The easiest way to trigger this is by using
picture-based subtitles; it is also possible to run into this in case of
missing decoders or allocation failures.
Furthermore, return the proper error code in case of missing decoder.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 77ace1ffea)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit f38926ec24)
Happened on several error conditions, e.g. if there is just no decoder
for the format (like with svg images).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 3d1a9824b8)
Move it to the context instead.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 2777bae7f2)
The init function first allocates an AVFrame and then some buffers; if
one of the buffers couldn't be allocated, the AVFrame leaks. Solve this
by setting the FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 4f67288948)
The Winnov WNV1 format is designed for a little-endian bitstream reader;
yet our decoder reversed every byte bitwise (in a buffer only
allocated for this purpose) to use a big-endian bitstream reader. This
commit stops this.
Two things needed to be done to achieve this: The codes in the table used
to initialize a VLC reader needed to be reversed bitwise (when
initializing a VLC in LE mode, it is expected that the first bit to be
read is in the least significant bit; with BE codes the first bit to be
read is the most significant bit of the code) and the following
expression needed to be adapted:
ff_reverse[get_bits(&w->gb, 8 - w->shift)]
But this is easy: When only the bits read are reversed, they coincide
with what a little-endian bitstream reader reads that reads the
original, not-reversed data. But ff_reverse always reverses the full
eight bits and this also performs a shift by (8 - (8 - w->shift)) on top
of reversing the bits read. So the above line needs to be changed to
get_bits(&w->gb, 8 - w->shift) << w->shift
and this also shows why the variable shift is named the way it is.
Finally, this also fixes a hypothetical memleak: For gigantic packets,
initializing a GetBitContext can fail and in this case, the buffer
containing the reversed data would leak.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 0166b1d1a6)
TrueMotion 2.0 uses Huffmann trees. To parse them, the decoder allocates
arrays for the codes, their lengths and their value; afterwards a VLC
table is initialized using these values. If everything up to this point
succeeds, a new buffer of the same size as the already allocated arrays
for the values is allocated and upon success the values are copied into
the new array; all the old arrays are then freed. Yet if allocating the
new array fails, the old arrays get freed, but the VLC table doesn't.
This leak is fixed by not allocating a new array at all; instead the old
array is simply reused, ensuring that nothing can fail after the
creation of the VLC table.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 5ff2ff6bd9)
In case the multichannel HRIR mode was enabled, an error could happen
between allocating a channel layouts list and attaching it to its target
destination. If an error happened, the list would leak. This is fixed by
attaching the list to its target directly after its allocation.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit ca8e5dedc7)
The headphone filter uses a variable number of inpads and allocates them
in its init function; if all goes well, the number of inpads coincides
with a number stored in the filter's private context. Yet if allocating a
subsequent inpad fails, the uninit function nevertheless uses the number
stored in the private context to determine the number of inpads to free
and not the AVFilterContext's nb_inputs. This will lead to an access
beyond the end of the allocated AVFilterContext.input_pads array and
an invalid free.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 0960da42f5)
If an error happens between allocating a string intended to be used as
an inpad's name and attaching it to its input pad, the string leaks.
Fix this by inserting the inpad directly after allocating its string.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 16ea88778e)
The aiir filter adds output pads in its init function. Each of these
output pads had a name which was allocated and to be freed in the uninit
function. Given that the aiir filter has between one and two outputs,
one output pad's name was freed unconditionally and a second was freed
conditionally.
Yet if adding output pads fails, there are no output pads at all and
trying to free a nonexistent pad's name will lead to a segfault.
Furthermore, if the name could be successfully allocated, yet adding the
new pad fails, the name would leak.
This commit fixes this by not allocating the pads' names at all any
more: They are constant anyway. This allows to remove the code to free
them and hence fixes the aforementioned bugs.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 97b1a2c564)
These names leak because freeing them in the uninit function has been
forgotten. Instead of adding the freeing code, this commit stops
allocating these names. They are constants anyway.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 7e736cd38a)
It has been forgotten to free the name of the second outpad if attaching
the first one to the AVFilterContext fails. Fixing this is easy: Only
prepare the second outpad after (and if) the first outpad has been
successfully attached to the AVFilterContext.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit fdbd579fd1)
The amerge filter uses a variable number of inpads and allocates them
in its init function; if all goes well, the number of inpads coincides
with a number stored in the filter's private context. Yet if allocating a
subsequent inpad fails, the uninit function nevertheless uses the number
stored in the private context to determine the number of inpads to free
and not the AVFilterContext's nb_inputs. This will lead to an access
beyond the end of the allocated AVFilterContext.input_pads array and
an invalid free.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit 8f2c1f2cbe)
Fixes memleaks in case init fails (e.g. because of invalid parameters
like 'aformat=sample_fmts=s16:cl=wtf') or also if query_formats is never
called.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
(cherry picked from commit a7bd379276)
