The choosen value is arbitrary. I am not sure if this is a good idea
but i dont immedeately see an alternative better way, it seems either
an arbitrary limit or OOM
Fixes: OOM
Fixes: 27492/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6194970578649088
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 538976288 * 538976288 cannot be represented in type 'int'
Fixes: 27473/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5758978289827840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 64 + 9223372036854775799 cannot be represented in type 'long'
Fixes: 27563/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6244650163372032
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently skip_samples is set to start_pad if sample_time is lesser or
equal to 0. This can cause issues if the stream starts with packets that
have negative pts. Calling avformat_seek_file() with ts set to 0 on such
streams makes the mov demuxer return the right corresponding packets
(near the 0 timestamp) but set skip_samples to start_pad which is
incorrect as the audio decoder will discard the returned samples
according to skip_samples from the first packet it receives (which has
its timestamp near 0).
For example, considering the following audio stream with start_pad=1344:
[PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]
Calling avformat_seek_file() with ts=0 makes the next call to
av_read_frame() return the packet with pts=-320 and a skip samples
side data set to 1344 (start_pad). This makes the audio decoder
incorrectly discard (1344 - 320) samples.
This commit makes the move demuxer adjust skip_samples according to the
stream start_pad, seek timestamp and first sample timestamp.
The above example will now result in av_read_frame() still returning the
packet with pts=-320 but with a skip samples side data set to 320
(src_pad - (seek_timestamp - first_timestamp)). This makes the audio
decoder only discard 320 samples (from pts=-320 to pts=0).
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: signed integer overflow: 18 + 9223372036854775799 cannot be represented in type 'long'
Fixes: 26731/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5696846019952640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The AAXC container format is the same as the (already supported) Audible
AAX format but it uses a different encryption scheme.
Note: audible_key and audible_iv values are variable (per file) and are
externally fed.
It is possible to extend https://github.com/mkb79/Audible to derive the
audible_key and audible_key values.
Relevant code:
def decrypt_voucher(deviceSerialNumber, customerId, deviceType, asin, voucher):
buf = (deviceType + deviceSerialNumber + customerId + asin).encode("ascii")
digest = hashlib.sha256(buf).digest()
key = digest[0:16]
iv = digest[16:]
# decrypt "voucher" using AES in CBC mode with no padding
cipher = AES.new(key, AES.MODE_CBC, iv)
plaintext = cipher.decrypt(voucher).rstrip(b"\x00") # improve this!
return json.loads(plaintext)
The decrypted "voucher" has the required audible_key and audible_iv
values.
Update (Nov-2020): This patch has now been tested by multiple folks -
details at the following URL:
https://github.com/mkb79/Audible/issues/3
Signed-off-by: Vesselin Bontchev <vesselin.bontchev@yandex.com>
Those are private fields, no reason to have them exposed in a public
header. Since there are some (semi-)public fields located after these,
even though this section is supposed to be private, keep some dummy
padding there until the next major bump to preserve ABI compatibility.
The mfra has enough information to enable seeking, and reading it is
behind an AVOption flag, so we shouldn't require that sidx information
also be present in order to seek using the fragment index.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This also changes a check for mfra_size from < 0 to == 0, since
it was always wrong, as avio_rb32 returns an unsigned integer.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
On files with more than one sidx box, like live fragmented MP4
files, it was previously re-reading and seeking on every singl
sidx box, leading to extremely poor performance on larger files,
especially over the network.
Only do it on the first one, and stash its result.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It should be a 64-bit integer, otherwise it overflows and fails
on files greater than 2GB on some systems like x86_64 Linux.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
A few popular sites have started generating MP4 files which have a
sidx plus an mfra. The sidx accounts for all size except the mfra,
so the old code did not mark the fragment index as complete.
Instead we can just check if there's an mfra and if its size makes
up the difference we can mark the index as complete.
Bug: https://crbug.com/1107130
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It help initialize chroma format and other info properly
Chroma format wasn't correct if I use below code:
avformat_find_stream_info(fmtc, NULL);
iVideoStream = av_find_best_stream(fmtc, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0);
eChromaFormat = (AVPixelFormat)fmtc->streams[iVideoStream]->codecpar->format;
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 24457/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5760093644390400
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix two cases of memleaks:
1. The leak of dv_demux
2. The leak of dv_fctx upon dv_demux allocate failure
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code for demuxing DV audio predates the introduction of refcounted
packets and when the latter was added, changes to the former were
forgotten. This meant that when avpriv_dv_produce_packet initialized the
packet containing the AVBufferRef, the AVBufferRef as well as the
underlying AVBuffer leaked; the actual packet data didn't leak: They
were directly freed, but not via their AVBuffer's free function.
https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4671/dir1.tar.bz2
contains samples for this (enable_drefs needs to be enabled for them).
Moreover, errors in avpriv_dv_produce_packet were ignored; this has been
changed, too.
Furthermore, in the hypothetical scenario that the track has a palette,
this would leak, too, so reorder the code so that the palette code
appears after the DV audio code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that av_get_packet returns a blank packet on error, the only
difference to the current approach (that uses intermediate AVPackets on
the stack) is that st->attached_pic will be properly initialized on error
(i.e. the timestamps are AV_NOPTS_VALUE) whereas right now st->attached_pic
is only zeroed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Only read str_size bytes from offset 30 of extradata if the extradata is
indeed at least 30 + str_size bytes long.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
mov_read_custom tries to read three strings belonging to three different
tags. When an already encountered tag is encountered again, a new buffer
for the string to be read is allocated and stored in the pointer
destined for this particular tag. But in this scenario, said pointer
already holds the address of the string read earlier, leading to a leak.
This commit therefore aborts the reading process upon encountering
an already encountered tag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By default, a demuxer's read_close function is not called automatically
if an error happens when reading the header; instead it is up to the
demuxer to clean up after itself in this case. The mov demuxer did this
by calling its read_close function when it encountered some errors when
reading the header. Yet for other errors (mostly adding side-data to
streams) this has been forgotten, so that all the internal structures
of the demuxer leak.
This commit fixes this by making sure mov_read_close is called when
necessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
2d8d554f15 added a new error condition
to mov_read_stsz() but forgot to free a temporary buffer when it
occurs.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If you have a file with multiple Metadata Keys, the second time you parse
the keys, you will re-alloc c->meta_keys without freeing the old one.
This change will avoid parsing all the consecutive Metadata keys.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
