If the height is zero, the decompression will probably end up
failing due to not fitting into the allocated buffer later
anyway, so this doesn't need any more elaborate check.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 601c2015bc16f0b281160292a6a760cbbbb0eacb)
This is required, since invalid parameters actually could
pass the switch check below.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit c77d409bf95954aceb762dd800d1ee2868c4b0d4)
This fixes reads out of bounds.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit d1d99e3befea5d411ac3aae72dbdecce94f8b547)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/pcx.c
We read 2 bytes for 15 out of 16 pixels, therefore we need to
have at least 30 bytes, not 16.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 7ba0cedbfeff5671b264d1d7e90777057b5714c6)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Decoded data is always written in pairs within this decoder.
This fixes writes out of bounds.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit aa0dd52434768da64f1f3d8ae92bcf980c1adffc)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Previously, we returned 0, meaning successful decoding but 0
bytes consumed, leading to an infinite loop.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 9fb0de86b49e9fb0709a8ad1e1875e35da841887)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
If the input buffer contains more data after the deflate stream,
the loop previously left running infinitely, with inflate returning
Z_STREAM_END.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit a81cad8f86d1feb7e4bfae29e43f3e994935a5c7)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
In lpc_prediction(), we write up to array element 'lpc_order' in
an array allocated to hold 'max_samples_per_frame' elements.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 59480abce7e4238e22b3a4a904a9fe6abf4e4188)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Previously, s->context_initialized was left set to 1
if ff_vc1_decode_init_alloc_tables failed, skipping the
initialization completely on the next decode call.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit b772b0e28eba6abf76d86ee8c6e459a86642db5a)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This is similar to the fix in 35cbc98b.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit e9d61de96c113ee0ef8082833c7e682df0e23eec)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The init function reads one byte of extradata.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit f50803354c6acb4575379d7c54ca48ec5d36dd61)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This avoids crashes when initializing the range coder for
the first slice context.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit b1db33159fdc2da4bdd8c75e4ff9a7dd0ef2f0c2)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This is similar to an existing check for the second-last frame
from 062421e3.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit ea78a348d86a3a733f6c1e0a65cfdd8283d924b9)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/eacmv.c
This avoids a potential division by zero.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit f875a732e36786d49f3650e3235272891a820600)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Also pass on any returned error code.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 1115689d54ea95a084421f5a182b8dc56cbff978)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/svq3.c
Also don't pointlessly set the buffer size to 1 after copying
one packet.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 0d61f260010707f3028b818e8b24598e1a83d696)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* qatar/release/9:
Update Changelog
Prepare for 9.9 RELEASE
lavf: fix the comparison in an overflow check
dv: Add a guard to not overread the ppcm array
nuv: check ff_rtjpeg_decode_frame_yuv420 return value
Conflicts:
Changelog
RELEASE
libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit a4e70918316c6d1423e559aad15823a5e0453fcf)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 164b67ca281fa5a47b965a858c7783aa547091b8)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Currently all uses of the emu edge code as well as the code itself
assume int linesize
changing some but not changing all would introduce a security issue
once all use this typedef a simple search and replace can be
done to switch them all to ptrdiff_t
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 2ffead98ddd384f61cdf6b1cb3f36592f54cd34a)
Conflicts:
libavcodec/videodsp.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/release/9:
mpegvideo: Avoid 32-bit wrapping of linesize multiplications
mjpegb: Detect changing number of planes in interlaced video
alac: Check that the channels fit at the given offset
4xm: Check that the read track value is non-negative
Conflicts:
libavcodec/alac.c
libavcodec/mjpegdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'aade60ab165716523788cd11caf03ae61b40144a':
matroskadec: Check that .lang was allocated and set before reading it
alac: Limit max_samples_per_frame
ape demuxer: check for EOF in potentially long loops
4xm: check that bits per sample is strictly positive
lavf: avoid integer overflow when estimating bitrate
pictordec: pass correct context to avpriv_request_sample
Conflicts:
libavcodec/pictordec.c
libavformat/matroskadec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8dc4b2c92e492aa172327d10c926d5ca3a04371c':
pictordec: break out of both decoding loops when y drops below 0
vcr1: add sanity checks
Conflicts:
libavcodec/pictordec.c
libavcodec/vcr1.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
These prevent the rgb ljpeg code from being run on parameters that it doesnt
support. No testcase available but it seems possible to trigger these.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 61c68000eda643dfce96dc46b488d39fd5c4e309)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This makes sure that linesize * start_y doesn't overflow, so that
emulated_edge_mc can get back the original value if needed.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit a711a2cb473dc95708f371a82c85c97fe789b5c2)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The code tries to decode a number of channels at the
offset given by the ff_alac_channel_layout_offsets table.
Even if the number of channels decoded so far doesn't
exceed the total number of channels, we need to check that
we actually can decode that number of channels at this offset
as well.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 35cbc98b720db95b923cb2d745f77bb2ee4363dc)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Otherwise buffer size calculations in allocate_buffers could
overflow later, making the code think a large enough buffer
actually was allocated.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit f7c5883126f9440547933eefcf000aa78af4821c)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Otherwise picmemset can get called with negative y, resulting in an
invalid write.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 5f7aecde02a95451e514c809f2794c1deba80695)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
