In sdp_read_header() some ff_network_close() calls were missed.
Also in rtp_read_header() update comment to explain why a single
call to ff_network_close() is enough to cover all cases even if
sdp_read_header() returns an error.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
In this error path ret still stores the number of bytes read in
ffurl_read().
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
As per the docs network initialization is required before ff_url_join().
Furthermore, because the ff_network_init() was skipped, this makes
one additional call to ff_network_close() if the stream exits without
errors.
The was forgotten in the origin commit of the listen mode:
a8ad6ffafe89e3a83f343f69249338e8245816f7
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
The Block timestamp read in matroska_parse_block() is in track timebase and is
passed on as such to the AVPacket which uses this timebase.
In the normal case the Cluster and Track timebases are the same because the
track->time_scale is 1.0. But when it is not the case, the values in Cluster
timebase need to be transformed in Track timebase so they can be added
together.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When the check was added (in 3668701f9600, in 2015), some IO
functions returned 0 on EOF (in particular, the TCP protocol
did, but the TLS protocol returned AVERROR_EOF). Since
0e1f771d2200d in 2017, the TCP protocol also returns AVERROR_EOF
instead of 0, making the check for premature end never have the
intended effect.
Signed-off-by: Martin Storsjö <martin@martin.st>
mpegts_read_header stops parsing the file at the first PMT. However the check
that ensured this was wrong because streams can also be added before the first
PMT is received (e.g. EIT).
So let's make sure we are in the header reading phase by checking if ts->pkt is
unset instead of checking if the number of streams found so far is 0.
Signed-off-by: Marton Balint <cus@passwd.hu>
A variable has been assigned a value twice consecutively; essentially
the same happens when one performs av_init_packet on an AVPacket after
a call to av_packet_unref.
Found via PVS-Studio (see ticket #8156).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ASF specification of Metadata Objects' stream number is as follows:
"Specifies whether the entry applies to a specific digital media stream
or whether it applies to the whole file. A value of 0 in this field
indicates that it applies to the whole file; otherwise, the entry
applies only to the indicated stream number and must be between 1 and
127."
Yet the asf_o demuxer (the one originating from Libav) has always
treated such metadata as if it applied to a stream even though no stream
with a stream number may exist in a valid ASF file. This is fixed in
this commit; it affected e.g. the file
wma_with_metadata_library_object_tag_trimmed.wma from the FATE suite.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ASF file format has a limit of 127 streams and the "asf_o" demuxer
(the ASF demuxer from Libav) has an array of pointers for a structure
called ASFStream that is allocated on demand for every stream. Attached
pictures are not streams in the sense of the ASF specification, yet the
demuxer created an ASFStream for them; and in one codepath it also
forgot to check whether the array of ASFStreams is already full. The
result is a write beyond the end of the array and a segfault lateron.
Fixing this is easy: Don't create ASFStreams for attached picture
streams.
(Other results of the current state of affairs are unnecessary allocations
(of ASFStreams structures), the misparsing of valid files (there might not
be enough ASFStreams left for the valid streams if attached pictures take
up too many); furthermore, the ASFStreams created for attached pictures all
have the stream number 0, an invalid stream number (the valid range is
1-127). This means that invalid data (packets for a stream with stream
number 0) won't get rejected lateron.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: NULL pointer dereference
Fixes: 26814/clusterfuzz-testcase-minimized-ffmpeg_dem_ICO_fuzzer-5758487797432320
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The previous threshold, 4 KB, maybe was reasonable when it was set
(in 2010), but in today's settings and with typical network speeds
and data sizes, it's pretty small. 32 KB probably is a more reasonable
default now, regardless of input.
This changes the test references for two seek tests.
When using the normal seek function, which boils down to the lseek(2)
function, a seek to an out of bounds position doesn't return an error,
but that condition is only reported when doing the subsequent read
(which returns EOF). When doing more seeks by fast forwarding, the
fact that the seeked to destination is out of bounds is noticed and
reported sooner in these cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: signed integer overflow: -9223372036854775808 + -5279949906739200 cannot be represented in type 'long'
Fixes: 26908/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-6329610851319808
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
move comments for the size of SDP_MAX_SIZE here:
Some SDP lines, particularly for Realmedia or ASF RTSP streams,
contain long SDP lines containing complete ASF Headers (several
kB) or arrays of MDPR (RM stream descriptor) headers plus
"rulebooks" describing their properties. Therefore, the SDP line
buffer is large.
The Vorbis FMTP line can be up to 16KB - see xiph_parse_sdp_line
in rtpdec_xiph.c.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Fixes: assertion failure
Fixes: 26905/clusterfuzz-testcase-minimized-ffmpeg_dem_LVF_fuzzer-5724267599364096.fuzz
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>
AMV is a hard-coded (and broken) subset of AVI. It's not worth sullying
the existing AVI muxer with its filth.
Fixes ticket #747.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Fixes: out of array access
Fixes: 26816/clusterfuzz-testcase-minimized-ffmpeg_dem_MPEGTSRAW_fuzzer-6282861159907328.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Marton Balint <cus@passwd.hu>
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>
Fixes: division by 0
Fixes: 26802/clusterfuzz-testcase-minimized-ffmpeg_dem_IDF_fuzzer-5180591554953216.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Bigger sizes are misinterpreted as negative numbers by the API
Fixes: infinite loop
Fixes: 26611/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-4890614975692800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array accesses
Fixes: 26622/clusterfuzz-testcase-minimized-ffmpeg_dem_VIVIDAS_fuzzer-6581200338288640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Causes a divide-by-zero in the rare case where:
- the file has an audio stream,
- the first audio frame isn't within the first BRP_BASF_LOOKAHEAD frames,
- an audio frame is encountered later, and
- its chunk header (except num_blocks) contains all zeros
(matching the uninitialised structure in the context)
The decoder will discard any garbage data, so the check isn't really needed.
Fixes: division by 0
Fixes: 26667/clusterfuzz-testcase-minimized-ffmpeg_dem_ARGO_BRP_fuzzer-5645146928185344.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reading the header terminates when an fcTL chunk is encountered in which
case read_header returned success without checking the length of said
chunk. Yet when read_packet processes this chunk, it checks for the
length to be 26 and errors out otherwise. So do so when reading the header,
too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
apng data consists of parts containing a small header (including a
four-byte size field) and a data part; the size field does not account
for everything and is actually twelve bytes short of the actual size. In
order to make sure that the size fits into an int, the size field is
checked for being > INT_MAX; yet this does not account for the + 12 and
upon conversion to int (which happens when calling append_extradata()),
the size parameter can still wrap around. In this case the currently
used check would lead to undefined signed integer overflow.
Furthermore, append_extradata() appends the new data to the already
existing extradata and therefore needs to make sure that the combined
size of new and old data as well as padding fits into an int. The check
used for this is "if (old_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE -
new_size)". If new_size is > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
the right side becomes negative if the types are signed (as they are
now); yet changing this to "if (new_size > INT_MAX -
AV_INPUT_BUFFER_PADDING_SIZE - old_size)" is better as this also works
for unsigned types (where it is of course presumed that INT_MAX is
replaced by the corresponding maximum for the new type).
Both of these issues have been fixed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If avio_read() could read anything, it returns the number of bytes read,
even if it could not read as much as the caller desired.
apng_read_header() only checked the return value of its avio_read() calls
for being negative and this meant that it was possible for an incomplete
header to not be detected. The return value of the last successfull call
has been returned instead. This commit changes this.
Fixes: OOM
Fixes: 26608/clusterfuzz-testcase-minimized-ffmpeg_dem_APNG_fuzzer-4839491644424192
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
