Broken bitstreams could report a larger than specified number of
channels and cause outbound writes.
CC:libav-stable@libav.org
(cherry picked from commit a943a132f3)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
They can be different if the last keyframe failed to decode correctly.
Fixes possible invalid reads in such a case.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit b1bb8fb860)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Also add an additional sanity check to the alt_quant table.
Fixes invalid reads with corrupted files.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 66531d634e)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The data offsets are relative to the bistream header, which is 16 bytes
after the start of the data.
Fixes invalid reads with corrupted files.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 34e6af9e20)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This can happen when the number of skipped lines is not consistent with
the number of coded lines.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 3623589edc)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
It can be 0 or -1 for invalid files, which may result in invalid memory
access.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit b88f902125)
Conflicts:
libavcodec/bmv.c
When `off' is 0, `0x537F6103 << 32' in the following expression invokes
undefined behavior, the result of which is not necessarily 0.
(0x537F6103 >> (off * 8)) | (0x537F6103 << (32 - (off * 8)))
Avoid oversized shifting.
CC: libav-stable@libav.org
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit eba1ff3130)
get_uint returns an unsigned value, use an unsigned to store
blocksize to make sure the comparison logic is correct and report
correctly the error for the channel count not supported.
CC: libav-stable@libav.org
(cherry picked from commit 5cf7c72757)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Prevent the loop shorten_decode_close from writing and freeing out of
the array boundary.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
CC: libav-stable@libav.org
(cherry picked from commit c10da30d84)
Fixes invalid reads when the first frame is not an I-frame.
CC:libav-stable@libav.org
(cherry picked from commit 7b89cd20d8)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Avoids an infinite loop in the calling programs with decoder not
consuming any input and not returning output.
CC:libav-stable@libav.org
(cherry picked from commit cacad1c058)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The loop a few lines below the xan_unpack() call accesses up to
dec_size * 2 bytes into y_buffer, so dec_size must be limited to
buffer_size / 2.
CC:libav-stable@libav.org
(cherry picked from commit 8a49d2bcbe)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Avoids an infinite loop in the calling programs with decoder not
consuming any input and not returning output.
CC:libav-stable@libav.org
(cherry picked from commit ea1136baaf)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
When there is just 1 byte remanining in the buffer, nothing will be read
and the loop will continue forever. Check that there are at least 8
bytes, which are always read at the beginning.
CC:libav-stable@libav.org
(cherry picked from commit 3e2f200237)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
When parsing the Xing/Info tag, don't set the bit rate if it's an Info tag.
When parsing the stream, don't override the bit rate if it's already set,
otherwise calculate the mean bit rate from parsed frames. This way, the bit
rate will be set correctly both for CBR and VBR streams.
CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit eae0879d96)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Returning 0 may result in an infinite loop in valid calling programs. A
decoder should never return 0 without producing any output.
CC:libav-stable@libav.org
(cherry picked from commit 4c0080b7e7)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The decoder assumes a single bit depth for all the planes
while the specification allows different bit depths for luma
and chroma.
Avoid the possible problems described in CVE-2013-2277
CC: libav-stable@libav.org
(cherry picked from commit 4987faee78)
Conflicts:
libavcodec/h264.c
CC:libav-stable@libav.org
(cherry picked from commit 437211ae73)
Fixes deadlocks waiting for non-existing references with some fuzzed files.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Since decode_slice_header() returns before the reference lists are
constructed, there are zero valid references.
CC:libav-stable@libav.org
(cherry picked from commit 668e16a0dd)
Conflicts:
libavcodec/h264.c
The specification does not prevent an encoder to write the amplitude 0
as 0 amplitude_bits.
Our get_bits() implementation might not support a zero sized read
properly, thus the additional branch.
(cherry picked from commit 23bd9ef4b2)
Conflicts:
libavcodec/vorbisdec.c
The value is used to calculate output LSP curve and a division by zero
and out of array accesses would occur.
CVE-2013-0894
CC: libav-stable@libav.org
Reported-by: Dale Curtis <dalecurtis@chromium.org>
Found-by: inferno@chromium.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 11dcecfcca)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Rate and order must not be 0 even if the specification does not say that
explicitly.
(cherry picked from commit 5b47c19bfd)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Damaged frames can lead to a mismatch, which can cause a segfault
due to using an incorrect channel mapping.
CC:libav-stable@libav.org
(cherry picked from commit d7c450436f)
Conflicts:
libavcodec/ac3dec.c
When byte_run is 0, pixel_countdown is not touched and the loop will run
forever.
CC:libav-stable@libav.org
(cherry picked from commit ddfe1246d9)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This fixes crashes in chromium on win64 on machines with AVX
(crashes that apparently aren't triggered by fate).
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 311443f6c7)
Signed-off-by: Martin Storsjö <martin@martin.st>
REBASE_PICTURE (more specifically, this half of it) takes a Picture
pointer that points into one larger struct, finds the offset of
that Picture within the struct and finds the corresponding field
within another instance of a similar struct.
The pointer difference "pic - (Picture*)old_ctx" is a value given
in sizeof(Picture) units, and when applied back on
(Picture*)new_ctx gets multiplied back with sizeof(Picture). Many
compilers seem to optimize out this division/multiplication, but
not all do.
GCC 4.2 on OS X doesn't seem to remove the division/multiplication,
therefore the new pointer didn't turn out to point to exactly
the right place in the new struct since it only had sizeof(Picture)
granularity (and the Picture is not aligned on a sizeof(Picture)
boundary within the encompassing struct). This bug has been present
before 47318953d as well - with H264, pointers to h->ref_list[0][0]
pointed to 88 bytes before h->ref_list[0][0] after the rebase. After
shrinking Picture, the difference ended up even larger, making
writes via such a Picture pointer overwrite other fields at random
in H264Context, ending up in crashes later.
This fixes H264 multithreaded decoding on OS X with GCC 4.2.
Fixes Bug: #439
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit a65f965c04)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
