avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
Fixes: 1735/clusterfuzz-testcase-minimized-5350472347025408
This uses unsigned instead of SUINT because the later was rejected by multiple developers
See: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/cfhd: Check band parameters before storing them
Fixes out of array read Fixes: 2169/clusterfuzz-testcase-minimized-5688641642823680 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/h264_parse: Check picture structure when initializing weight table
Fixes: runtime error: index 49 out of bounds for type 'int [48][2][2]' Fixes: 2159/clusterfuzz-testcase-minimized-5267945972301824 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Sasi Inguva [Tue, 6 Jun 2017 18:16:01 +0000 (11:16 -0700)]
lavf/mov.c: offset index timestamps by the minimum pts to make first pts zero
If the videos starts with B frame, then the minimum composition time
as computed by stts + ctts will be non-zero. Hence we need to shift
the DTS, so that the first pts is zero. This was the intention of that
code-block. However it was subtracting by the wrong amount.
For example, for one of the videos in the bug nonFormatted.mp4 we have
The resulting composition times are : 3003, 1001, 2002, 6006, ...
The minimum composition time or PTS is 1001, which should be used to
offset DTS. However the code block was wrongly using ctts[0] which is
3003. Hence the PTS was negative. This change computes the minimum pts
encountered while fixing the index, and then subtracts it from all the
timestamps after the edit list fixes are applied.
fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2
B frames. Before this change the PTS of first two B-frames was -6006
and -3003, and I am guessing one of them got dropped when being decoded
and remuxed to the framecrc before, and now it is not being dropped.
Henrik Gramner [Wed, 29 Mar 2017 14:43:57 +0000 (16:43 +0200)]
x86inc: Fix call with memory operands
We overload the `call` instruction with a macro, but it would misbehave when
the macro argument wasn't a valid identifier. Fix it by explicitly checking
if the argument is an identifier.
avcodec/mjpegdec: Check that reference frame matches the current frame
Fixes: out of array read Fixes: 2097/clusterfuzz-testcase-minimized-5036861833609216 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Tyler Jones [Tue, 30 May 2017 17:28:16 +0000 (11:28 -0600)]
avcodec/vorbisenc: Use a bufqueue in encoding with smaller lengths
Switching the vorbis encoder to use a buffer queue for input frames allows
saving lookahead samples more easily and safely for psychoacoustic systems,
requiring less pointer arithmetic in the case of transient windows.
This reduces the attack surface of local file-system
information leaking.
It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.
Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.
The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.
Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel
This recommits the security fix without the author name joke which was
originally requested by Nicolas.
Found-by: Emil Lerner and Pavel Cheremushkin Reported-by: Thierry Foucu <tfoucu@google.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Sysiphus [Sat, 3 Jun 2017 19:20:04 +0000 (21:20 +0200)]
avformat/hls: Check local file extensions
This reduces the attack surface of local file-system
information leaking.
It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.
Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.
The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.
Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel
Found-by: Emil Lerner and Pavel Cheremushkin Reported-by: Thierry Foucu <tfoucu@google.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Kevin Mark [Sun, 4 Jun 2017 07:53:31 +0000 (03:53 -0400)]
FATE: Add test for libavfilter/scale2ref
This new FATE test for the scale2ref filter makes use of the recently
added scale2ref-specific variables to maintain the aspect ratio of a
test input.
Filtergraph explanation:
[main] has an AR of 4:3. [ref] has an AR of 16:9.
640 / 4 = 160. So the new width for [main] is 160.
160 / ((320 / 240) * (1 / 1)) = 160 / (4 / 3) = 120. So the new
height for [main] is 120.
160 / 120 = 4 / 3 so [main]'s aspect ratio has been maintained while
using [ref]'s width as a reference point.
[ref] is nullsink'd since it is left unchanged by scale2ref (and so
shouldn't need to be tested).
If we were to use "iw/4:-1" in place of "iw/4:ow/mdar":
640 / 4 = 160. So the new width for [main] would be 160.
360 / 4 = 90. So the new height for [main] would be 90.
160 / 90 = 16 / 9 so [main] now has the same aspect ratio as [ref]
which is probably what you do not want.
This is currently the only test for scale2ref.
Signed-off-by: Kevin Mark <kmark937@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The RGB555 PACKBITSRGN case tries to read a palette, if such
palette is actually stored then it accesses a null pointer.
All 16bit samples i could find use DIRECTBITSRGN.
Fixes: 2065/clusterfuzz-testcase-minimized-6298930457346048 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/sbrdsp_fixed: Fix assertion failure in sbr_sum_square_c()
This also increases the range of input values supported as well as
decreasing the operation dependencies in the main loop, improving
speed on modern CPUs.
Fixes part of: 2045/clusterfuzz-testcase-minimized-6751255865065472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/mlpdec: Check quant_step_size against huff_lsbs
This reorders the operations so as to avoid computations with the above arguments
before they have been initialized.
Fixes part of 1708/clusterfuzz-testcase-minimized-5035111957397504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_scale_eval_dimensions blindly assumes that two inputs are always
available as of 3385989b98be7940044e4f0a6b431a0a00abf2fa. This is
notably not the case when the function is called for the scale
filter. With the scale filter inputs[1] does not exist.
ff_scale_eval_dimensions now has an updated scale2ref check that
makes certain two inputs are actually available before attempting to
access the second one.
Thanks to James Almer for reporting this bug. This should fix the 820
Valgrind tests I single-handedly managed to break.
Signed-off-by: Kevin Mark <kmark937@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Shivraj Patil [Thu, 1 Jun 2017 08:37:19 +0000 (14:07 +0530)]
Disable MSA optimization for big endian arch
The current upstreamed code has been written and tested for Little Endian systems.
We do have plans to add the Big Endian support in near future, but till that time, need to disable all to avoid its usage and failures.
Signed-off-by: Shivraj Patil <shivraj.patil@imgtec.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Ganapathy Kasi [Wed, 31 May 2017 02:03:14 +0000 (19:03 -0700)]
avcodec/nvenc: fix hw accelerated transcode with bframes
hw accelerated transcode (h264_cuvid -> h264_nvenc with -hwaccel cuvid) was
broken after the filtergraph initialization was changed to intialize decoder
first followed by encoder (commit af1761f7b5b1b72197dc40934953b775c2d951cc).
During initialzing encoder with bframes, local buffers are allocated
internally in encoder which fails since no cuda context is available. Now
pushing the correct cuda context before encoder initialization fixes the issue.
Also adding push/pop cuda ctx during create/destroy/map/unmap resources and
destroy encoder session.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Kevin Mark [Tue, 30 May 2017 17:34:29 +0000 (13:34 -0400)]
libavfilter/scale2ref: Add constants for the primary input
Variables pertaining to the main video are now available when
using the scale2ref filter. This allows, as an example, scaling a
video with another as a reference point while maintaining the
original aspect ratio of the primary/non-reference video.
Consider the following graph: scale2ref=iw/6:-1 [main][ref]
This will scale [main] to 1/6 the width of [ref] while maintaining
the aspect ratio. This works well when the AR of [ref] is equal to
the AR of [main] only. What the above filter really does is
maintain the AR of [ref] when scaling [main]. So in all non-same-AR
situations [main] will appear stretched or compressed to conform to
the same AR of the reference video. Without doing this calculation
externally there is no way to scale in reference to another input
while maintaining AR in libavfilter.
To make this possible, we introduce eight new constants to be used
in the w and h expressions only in the scale2ref filter:
* main_w/main_h: width/height of the main input video
* main_a: aspect ratio of the main input video
* main_sar: sample aspect ratio of the main input video
* main_dar: display aspect ratio of the main input video
* main_hsub/main_vsub: horiz/vert chroma subsample vals of main
* mdar: a shorthand alias of main_dar
Of course, not all of these constants are needed for maintaining the
AR, but adding additional constants in line of what is available for
in/out allows for other scaling possibilities I have not imagined.
So to now scale a video to 1/6 the size of another video using the
width and maintaining its own aspect ratio you can do this:
scale2ref=iw/6:ow/mdar [main][ref]
This is ideal for picture-in-picture configurations where you could
have a square or 4:3 video overlaid on a corner of a larger 16:9
feed all while keeping the scaled video in the corner at its correct
aspect ratio and always the same size relative to the larger video.
I've tried to re-use as much code as possible. I could not find a way
to avoid duplication of the var_names array. It must now be kept in
sync with the other (the normal one and the scale2ref one) for
everything to work which does not seem ideal. For every new variable
introduced/removed into/from the normal scale filter one must be
added/removed to/from the scale2ref version. Suggestions on how to
avoid var_names duplication are welcome.
var_values has been increased to always be large enough for the
additional scale2ref variables. I do not forsee this being a problem
as the names variable will always be the correct size. From my
understanding of av_expr_parse_and_eval it will stop processing
variables when it runs out of names even though there may be
additional (potentially uninitialized) entries in the values array.
The ideal solution here would be using a variable-length array but
that is unsupported in C90.
This patch does not remove any functionality and is strictly a
feature patch. There are no API changes. Behavior does not change for
any previously valid inputs.
The applicable documentation has also been updated.
Signed-off-by: Kevin Mark <kmark937@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Srinath K R [Thu, 1 Jun 2017 07:58:07 +0000 (13:28 +0530)]
avcodec/nvenc: Add default value for AVCodecContext::refs
AVCodecContext::refs is used to control the DPB size to be used by the
encoder. The default value for AVCodecContext::refs as set in
libavcodec/options_table.h is 1.
This patch sets AVCodecContext::refs to 0 for h264_nvenc and hevc_nvenc in
order to let the driver take the decision of the correct DPB size to use in
all cases.
Signed-off-by: Srinath K R <skr@nvidia.com> Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
avcodec/cinepak: Check input packet size before frame reallocation
Reduces time spend decoding 1917/clusterfuzz-testcase-minimized-5023221273329664
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>