Previously, the value given to put_bits was 10 bits long for positive
predictors, even though 9 bits were to be written. The extra bit could
in some cases overwrite existing bits in the bitstream writer cache.
This fixes a failed assert in put_bits.h, when running a version
built with -DDEBUG.
The fate test result gets slightly improved, thanks to getting rid
of the overwritten bits in the bitstream writer cache.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit aa264da5bf)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Conflicts:
tests/ref/fate/acodec-adpcm-ima_qt
This fixes assert failures when running in debug mode.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 2d7d91f06d)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
It is possible in various error paths as well as gap handling
that this has already been allocated. It is not clear why that
would be a problem with the current code, thus disable the
assert to avoid a common assert failure when asserts are enabled.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 5e997688f8)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The ParserContext class doesn't have an AVClass, required for
using it as a logging class.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 6d65496990)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This assert is no longer true since h264 error concealment needs
last_picture_ptr to be set.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 91672504a4)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Conflicts:
libavcodec/mpegvideo.c
It seems the condition was flipped from what was intended.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 2c340596ca)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This change avoids accessing the segment map of the previous frame if
segmentation is not enabled for the current frame. The caller of
decode_mb_mode() only calls ff_thread_await_progress() on the reference
segmentation index array if segmentation is enabled, so Chromium's TSAN
will report a race when accessing this data while segmentation is not
enabled.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 30011bf201)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Change the size specifiers to match the actual element sizes
of the data. This makes no practical difference with strict
alignment checking disabled (the default) other than somewhat
documenting the code. With strict alignment checking on, it
avoids trapping the unaligned loads.
Signed-off-by: Mans Rullgard <mans@mansr.com>
The vertically interpolating variants of these functions read
ahead one line to optimise the loop. On the last line processed,
this might be outside the buffer. Fix these invalid reads by
processing the last line outside the loop.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Such changes are neither allowed nor supported
Found-by: ami_stuff
Bug-Id: CVE-2013-7020
CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit da7d839a0d)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Conflicts:
libavcodec/ffv1dec.c
Fixes a double release of the current frame on deinit.
Bug-Id: CVE-2011-3934
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The input data must remain constant, make a copy instead. This is in
theory a performance hit, but since I failed to find any samples
using this feature, this should not matter in practice.
Also, check the size of the header, avoiding invalid reads on truncated
data.
CC:libav-stable@libav.org
(cherry picked from commit 7b588bb691)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Conflicts:
libavcodec/svq1dec.c
0 means no data consumed, so it can trigger an infinite loop in the
caller.
CC:libav-stable@libav.org
(cherry picked from commit c7d9b473e2)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Conflicts:
libavcodec/cdgraphics.c
Bug-Id: CVE-2013-0868
inspired by a patch from Michael Niedermayer <michaelni@gmx.at>
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
(cherry picked from commit 744b406ff3)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Conflicts:
libavcodec/huffyuvdec.c
ModeTab.fmode has only 3 elements, so indexing it with ftype
in the initialier for 'size' is invalid when ftype == FT_PPC.
This fixes crashes with gcc 4.8.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 4bf2e7c5f1)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Properly address CVE-2011-3946 and parse bitstream as described in the spec.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Make sure the buffer size does not exceed the expected
RLE size.
Prevent an out of array bound write.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Bug-Id: CVE-2013-0852
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 00915d3cd2)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Some optimized template functions reference optimized symbols, so they
must be explicitly disabled when those symbols are unavailable.
(cherry picked from commit ec36aa6944)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This is safer and possibly fixes invalid reads on truncated data.
(cherry-picked from commit 541427ab4d)
CC:libav-stable@libav.org
Conflicts:
libavcodec/eamad.c
(cherry picked from commit f9204ec56a)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
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>
Only consume an AVPacket when all the samples have been read.
When the rate of samples output is limited (by the default value
of max_samples), consuming the first packet immediately will cause
timing problems:
- The first packet with PTS 0 will output 4608 samples and be
consumed entirely
- The second packet with PTS 64 will output the remaining samples
(typically, a lot, that's why max_samples exist) until the decoded
samples of the first packet have been exhausted, at which point the
samples of the second packet will be decoded and output when
av_decode_frame is called with the next packet).
That means there's a PTS jump since the first packet is 'decoded'
immediately, which can be seen with avplay or mplayer: the timing
jumps immediately to 6.2s (which is the size of a packet).
Sample: http://streams.videolan.org/issues/6348/Goldwave-MAClib.ape
Bug-Debian: http://bugs.debian.org/744901
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
(cherry picked from commit 91d4cfb812)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
In case start_frame() fails, this potentially invalid frame can still be
output to the caller.
Bug-Id: 672
Bug-Id: debian/741240
Bug-Id: ubuntu/1288206
This is basically an overread/overwrite-safe memcpy between a
GetByteContext and a PutByteContext.
CC:libav-stable@libav.org
(cherry picked from commit 5748faf291)
Otherwise the generic code will unref them, which can then result in
last_picture_ptr == current_picture_ptr, which causes deadlocks at least
in rv40.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Prevents using GetBitContexts with data from previous calls.
Fixes access to freed memory.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Otherwise the ER code might try to use some already freed references.
Fixes possible access to freed memory.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
In this case we may not have a current frame, while first_field being
set implies we do.
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Higher modes are not allowed for 16x16/chroma, which is what this
function is used for. Otherwise this function would return 0 (vertical
prediction) for invalid higher modes, which could result in invalid
reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
There is no point in delaying the check and it avoids bugs with a
half-initialized context.
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
If it was set before then we can end up trying to decode a slice without
a valid slice header, which can lead to invalid memory access.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
