[FFmpeg-devel] [PATCH 6/6] avformat/mxfdec: Check body_offset

[Tomas Härdin]

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 <michael at 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