The idea is to ensure that 'make fate' always fetches the fate samples
that work with this release.
(cherry picked from commit a89f68776b2771935a348ce07d0a094ae965acfc)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Apparently, some build environments require dxva.h even for dxva2,
while others lack this header entirely. Including it conditionally
allows building in both cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit fa84506177f0246b30d4ea6a99ee5d419f3e4550)
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 cacad1c058f66558ec727faac3b277d2dee264d4)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 20373a66ec68d958c266f643a7d0e5ec254c0fcc)
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 3e2f200237af977b9253b0aff121eee27bcedb44)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 747fbe0c212b81952bb27ec7b99fa709081e2d63)
Conflicts:
libavcodec/roqvideodec.c
The check `src > dst' in the form `&c->out[-back] > c->out' invokes
pointer overflow, which is undefined behavior in C.
Remove the check. Also replace `&c->out[-back] < c->out_start' with
a safe form `c->out - c->out_start < back' to avoid overflow.
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 ca6c3f2c53be70aa3c38e8f1292809db89ea1ba6)
Conflicts:
libavutil/lzo.c
Simplify `p->buf > p->buf + p->buf_size - 4' as `p->buf_size < 4'.
Avoid a possible out-of-bounds pointer, which is undefined behavior
in C.
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 8425d693eefbedbb41f91735614d41067695aa37)
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 eba1ff31304e407db3cefd7532108408f364367b)
Conflicts:
libavcodec/atrac3.c
The values compared here can be more than INT64_MAX apart. Since the
difference is always positive, converting to uint64_t before subtracting
gives the correct result without overflows.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 91ac403b1316d59b4f43c4ea0f237e24cec2819a)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Indexing outside an array is invalid and causes errors with
gcc 4.8.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 0a07f2b346433a9a2677c69c6b29a1a827e39109)
Signed-off-by: Diego Biurrun <diego@biurrun.de>
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 5cf7c72757779a740e897a97710aac044fe5258c)
(cherry picked from commit 88089eecfd7e604d40d078b4f4206c647cb2e2b4)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavcodec/shorten.c
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 c10da30d8426a1f681d99a780b6e311f7fb4e5c5)
(cherry picked from commit 21d568be179c54a1596d1377b4da7fbe755bfe7f)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
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
This fixes standalone compilation of the VC-1 parser.
(cherry picked from commit 3c715383ea7012ac69507e6b9189c98675c77461)
Conflicts:
libavcodec/vc1data.h
Signed-off-by: Diego Biurrun <diego@biurrun.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 8a49d2bcbe7573bb4b765728b2578fac0d19763f)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 62a657de168cf501acb23d48cc1aa00793dc83f3)
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 ea1136baafb1fe271cb56c3f4d7bff0267e3c70f)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit c1f479e8df24284237c80ad959619fc85e29a26d)
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 4c0080b7e7d501e2720d2a61f5186a18377f9d63)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 60dd8b5733f9ec4919fbc732ace1be8184dde880)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
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 11dcecfcca0eca1a571792c4fa3c21fb2cfddddc)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 494ddd377ada76ed555f7a3f49391455daa099c9)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
There used to be one test for Altivec intrinsics support and a
separate test to determine which of two possible syntaxes to use
for vector literals. Since 2008, we only support the more common
of these so the split test no longer makes sense.
This combines the tests into one and also changes the hard error on
failure to a warning. The test can reasonably fail if no --cpu flag
is provided (or is provided with an unknown CPU) and the compiler
default target does not support Altivec. Aborting in this case is
probably over-reacting.
Fixes: #464, http://bugs.debian.org/701710
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 20bcce507aa6b9c866e34eee75d80305109767a8)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit d894f74762bc95310ba23f804b7ba8dffc8f6646)
Related to CVE-2012-2882
Conflicts:
libavformat/oggdec.h
libavformat/oggparsevorbis.c
While we do not use Automake in libav, this allows our config to be
used more globally without introducing unwanted breakage.
(cherry picked from commit 040c565e51985477a8fa5e42d2ddfb26ebde6608)
Conflicts:
doc/developer.texi
Right now, the frame properties are set from the user-facing
AVCodecContext before it is updated from the thread context, which is
wrong since they may be invalid or obsolete.
Properly forward mp_decode_layer3 errors, mp_decode_layer1 and
mp_decode_layer2 do not return errors.
Based on a patch by Michael Niedermayer.
(cherry picked from commit 0c03cc68386443f1e96ab6fb358220faf67cd5ff)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This prevents decoder from reading garbage from it in case of errors later.
(cherry picked from commit 81064a8045028838fd32d18490034c207c8ecc06)
Fixes an invalid read on sample from CVE-2012-2804
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes segfault in the fuzzed sample bipbop234.ts_s226407.
CC: libav-stable@libav.org
(cherry-picked from commit 6e5cdf26281945ddea3aaf5eca4d127791f23ca8)
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
The ogg decoder wasn't padding the input buffer with the appropriate
FF_INPUT_BUFFER_PADDING_SIZE bytes. Which led to uninitialized reads in
various pieces of parsing code when they thought they had more data than
they actually did.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit ef0d779706c77ca9007527bd8d41e9400682f4e4)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
