fre 2024-04-26 klockan 05:08 +0200 skrev Michael Niedermayer: > Fixes: signed integer overflow: 538976288 - -9223372036315799520 > cannot be represented in type 'long' > Fixes: 68060/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer- > 5523457266745344 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > --- > libavformat/mxfdec.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c > index 233d614f783..e65cec74c23 100644 > --- a/libavformat/mxfdec.c > +++ b/libavformat/mxfdec.c > @@ -791,6 +791,9 @@ static int mxf_read_partition_pack(void *arg, > AVIOContext *pb, int tag, int size > partition->index_sid = avio_rb32(pb); > partition->body_offset = avio_rb64(pb); > partition->body_sid = avio_rb32(pb); > + if (partition->body_offset < 0) > + return AVERROR_INVALIDDATA;
The spec says BodyOffset is UInt64, so this means we drop support for files >= 2^63 bytes. This is probably fine though. Supporting such large files would be a pain in more places than here. MXF is sometimes used to archive scanned copies of film, but even raw 16k rgb48 essence @ 120 Hz takes over 1000 days of footage to hit the 2^63 limit.. I took a look at the body_offset logic and it looks like it should be correct when we force them to be non-negative. TL;DR: looks OK /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
