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)
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
CC:libav-stable@libav.org
(cherry picked from commit de9d2705f6)
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
Avoid a division by 0 in ff_mpeg4_set_one_direct_mv.
Sample-Id: 00000168-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
(cherry picked from commit 9514440337)
(cherry picked from commit 5df52b0131)
(cherry picked from commit aa2a3ca27a)
Fixes invalid writes on pixel format changes.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 4c3e1956ee)
(cherry picked from commit bd57e783437f990c3ac4747eeebe20332e103980)
For left HFYU prediction, we predict from the buffer buf+1 using 8- or
16-byte reads. This means that aligning the buffer by 16 bytes is in
itself not sufficient, because if the width itself is 16- or 8-byte
aligned, the buffer will not be padded, and thus a read of size 16 at
buf+1 will overflow boundaries at the right edge. Padding the buffer by
1 byte is sufficient to not overflow its boundaries.
Fixes bug 342.
(cherry picked from commit 98d0d19208)
f777504f64 changed a - in +
CC: libav-stable@libav.org
(cherry picked from commit d922c5a5fb)
(cherry picked from commit 3ce77e04c2ca4b9e7fa6b94b51e8d7c5f188da86)
(cherry picked from commit 8cba6f58c8acaa0ca6749110a2746bbe60ff2dab)
And use the value from the specification.
Sample-Id: 00000451-google
Found-by: Mateusz j00ru Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit f777504f64)
(cherry picked from commit 5bd083d0216d9ee649039c84999fb61386536ac1)
Conflicts:
libavcodec/h264.c
(cherry picked from commit 41380e017afcca3119acb560c08a60a97d416c3c)
Conflicts:
libavcodec/h264.c
Fixes an issue where the B-frame coding mode switches from interlaced
fields to interlaced frames, causing incorrect decisions in the motion
compensation code and resulting in visual artifacts.
CC: libav-stable@libav.org
Signed-off-by: Tim Walker <tdskywalker@gmail.com>
(cherry picked from commit dd2d0039b6)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 3cc8d9bc1f)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
An invalid VUI is not considered a fatal error, so the SPS containing it
may still be used. Leaving an invalid value of num_reorder_frames there
can result in writing over the bounds of H264Context.delayed_pic.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 9ecabd7892)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Conflicts:
libavcodec/h264_ps.c
(cherry picked from commit 299c5dcfb0)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Too much code relies in having init_get_bits fed with a valid
buffer and set its dimension to 0.
Check for NULL buffer instead.
(cherry picked from commit 4603ec85ed)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Apparently gcc-4.8.2 miscompiles enums resulting in a lucky fpe soon
after it.
Passing the enum value as integer makes the ftype == FT_PPC condition
evaluates correctly.
pthread_wait_cond can wake up unexpectedly (Wikipedia: Spurious_wakeup).
The FF_THREAD_SLICE thread mechanism could spontaneously execute
jobs or allow the caller of avctx->execute to return before all
jobs were complete.
Test both cases to ensure the wakeup is real.
Signed-off-by: Ben Jackson <ben@ben.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 311583e779)
Sometimes, if pthread_create() failed, then pthread_cond_wait() could
accidentally be called in the worker threads after the uninit function
had already called pthread_cond_broadcast(), leading to a deadlock.
Don't call pthread_cond_wait() if c->done is set.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
(cherry picked from commit 1a5a6ac01b)
