Pointers to specific entries in the array are stored in other structs, so
in the scenario where heif_item was reallocated when parsing an iloc box after
and iinf one, the pointers may end up referencing freed memory.
Fixes use-after-free with such samples.
Signed-off-by: James Almer <jamrial@gmail.com>
This basically ignores the overflow without undefined behavior, alternatively we could detect and error out
Fixes: signed integer overflow: 6310596683470275584 + 7660622966157213696 cannot be represented in type 'long'
Fixes: 70433/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5483347233538048
Fixes: 369662284/clusterfuzz-testcase-minimized-media_metadata_parser_fuzzer-5327368763670528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Based on a patch by Hacene Bouaroua.
Fixes ticket #11171.
Co-authored-by: Hacene Bouaroua <hbouaroua@freebox.fr>
Signed-off-by: James Almer <jamrial@gmail.com>
Otherwise, things like ICC profiles as read from the colr box meant for an item
with no stream (like a grid) may end up being added to the wrong stream.
Signed-off-by: James Almer <jamrial@gmail.com>
Found by fuzzer.
Bug: https://crbug.com/356720789
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We assign a 64bit variable to it before checking
Fixes: CID1604544 Overflowed integer argument
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It's meant to override any codec specific (but still container level)
information, but its position is not guaranteed, so apply the values after the
entire trak structure has been parsed.
Also, replace the ugly roundabout int -> double -> int method to set SAR from
existing dimensions while at it.
Signed-off-by: James Almer <jamrial@gmail.com>
I am not sure the case described by coverity is possible
but its more robust checking the argument first
Fixes: CID1598441 Improper use of negative value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 67492/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5778297231310848
Fixes: signed integer overflow: 2314885530818453536 + 7782220156096217088 cannot be represented in type 'long'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If view is defined in the child stri box, then the type must be set to
unspecified, as these boxes don't carry packing information.
Also, don't attach a useless Stereo 3D side data if the stream is monoscopic.
Signed-off-by: James Almer <jamrial@gmail.com>
This avoids hardcoding any implementation-specific limitiations as
part of the API, and allows for future expandability.
This also allows API users to more conveniently convert the
values into floats without hardcoding specific conversion constants.
The API was committed a few days ago, so changing this field now
is within the realms of acceptable.
As defined in Section 8.7.3.2.1 of ISO 14496-12.
Any unsupported value will be rejected in mov_build_index() without outright
aborting demuxing.
Fixes ticket #11005.
Signed-off-by: James Almer <jamrial@gmail.com>
ab77b878f1 attempted to fix the issue of broken packets being sent to
the decoder by implementing logic that kept attempting to PTS-step
backwards until it reached a valid point, however applying this
heuristic meant that in files that had no valid points (such as HEVC
videos shot on iPhones), we'd seek back to sample 0 on every seek
attempt. This meant that files that were previously seekable, albeit
with some skipped frames, were not seekable at all now.
Relax this heuristic a bit by giving up on seeking to a valid point if
we've tried a different sample and we still don't have a valid point to
seek to. This may some frames to be skipped on seeking but it's better
than not being able to seek at all in such files.
Fixes: ab77b878f1 ("avformat/mov: fix seeking with HEVC open GOP files")
Fixes: #10585
Signed-off-by: Philip Langdale <philipl@overt.org>
sc->data_size may contain the size of a single fragment after probing, and
using it alongside the duration of the entire stream to calculate bitrate
will result in a bogus small value.
Before:
Duration: 00:00:05.00, start: 0.000000, bitrate: 586 kb/s
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 640x360 [SAR 1:1 DAR 16:9], 112 kb/s, 60 fps, 60 tbr, 15360 tbn (default)
After:
Duration: 00:00:05.00, start: 0.000000, bitrate: 586 kb/s
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 640x360 [SAR 1:1 DAR 16:9], 561 kb/s, 60 fps, 60 tbr, 15360 tbn (default)
Signed-off-by: James Almer <jamrial@gmail.com>
James Almer
vectronic
Michael Niedermayer
Dale Curtis
Kacper Michajłow
Derek Buitenhuis
Lynne
Anton Khirnov
llyyr