Don't allocate the buffer for the title ourselves, leave it to
av_dict_set(). This simplifies freeing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All instances of adding attached pictures to a stream or adding
a stream and an attached packet to said stream have several things
in common like setting the index and flags of the packet, setting
the stream disposition etc. This commit therefore factors this out.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some flac muxers write truncated metadata picture size if the picture
data do not fit in 24 bits. Detect this by truncting the size found inside
the picture block and if it matches the block size use it and read rest
of picture data.
This workaround is only for flac files and not ogg files with flac
METADATA_BLOCK_PICTURE comments and it can be disabled with strict level
above normal. Currently there is a 500MB limit on truncate size to protect
from large memory allocations.
The truncation bug in lavf flacenc was fixed in e447a4d112
but based on existing broken files other unknown flac muxers seems to truncate also.
Before the fix a broken flac file for reproduction could be generated with:
ffmpeg -f lavfi -i sine -f lavfi -i color=red:size=2400x2400 -map 0:0 -map 1:0 -c✌️0 bmp -disposition:1 attached_pic -t 1 test.flac
Fixes ticket 6333
Signed-off-by: Anton Khirnov <anton@khirnov.net>
ff_flac_parse_picture() parses a buffer containing a flac metadata
picture block by wrapping it in an AVIOContext and using the AVIOContext
API. Consequently, when not enough data could be read AVERROR(EIO) was
returned although reading didn't really fail: A block that contains a
subfield whose size field indicates that it is so big as to extend
beyond the buffer is just invalid.
This commit changes this by using the bytestream2 API instead;
furthermore, the checks for whether there is enough data left are
performed before allocating a buffer for said data.
Finally, if the length of the picture description is bigger than
INT_MAX, it will now raise an error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
During parsing a flac picture metadata block, the mimetype is read as
follows: Its 32b size field is read and checked for being in the range
1..63; afterwards, the actual mimetype-string is read into a buffer of
size 64, where the length to read is the minimum of the length field and
the size of the destination buffer -1. Then an assert guards that length
is indeed < the size of the destination buffer before the string in the
buffer is zero-terminated.
The FFMIN as well as the assert are actually redundant, as it has
been checked that the string (even after terminating) fits into the
buffer. In order to make this clear, reword the check "len >= 64" to
"len >= sizeof(mimetype)" and drop the FFMIN as well as the assert.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Put an AVIOContext whose lifetime doesn't extend beyond the function
where it is allocated on the stack instead of allocating and freeing it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
aviod use of uninitialized memory
Fixes: asan_heap-oob_1487fa4_4706_cov_364534849_cover_art.flac
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Andreas Rheinhardt
James Almer
Mattias Wadman
Andreas Rheinhardt
Paul B Mahol
Anton Khirnov
Vittorio Giovara
Michael Niedermayer