Re: [FFmpeg-devel] [PATCH 4/6] avformat/cafdec: saturate start + size into 64bit

[James Almer <jamrial@gmail.com>]

On 9/29/2023 8:19 PM, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 64 + 9223372036854775803 cannot be represented in type 'long long'
> Fixes: 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-6536881135550464
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>   libavformat/cafdec.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
> index e92e3279fc6..0e50a3cfe68 100644
> --- a/libavformat/cafdec.c
> +++ b/libavformat/cafdec.c
> @@ -435,7 +435,7 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt)
>   
>       /* don't read past end of data chunk */
>       if (caf->data_size > 0) {
> -        left = (caf->data_start + caf->data_size) - avio_tell(pb);
> +        left = av_sat_add64(caf->data_start, caf->data_size) - avio_tell(pb);

avio_tell(pb) here is guaranteed to be bigger than caf->data_start, 
which is the offset where the DATA chunk starts, so the result of this 
calculation will be <= INT64_MAX even if you don't saturate it and 
instead cast it to uint64_t. Nonetheless, if the DATA chunk ends at an 
offset that would not fit in an int64_t, then we can't parse it to begin 
with due to AVIOContext API limitations.

Maybe we should just abort in read_header() if data_start + data_size > 
INT64_MAX, instead of pretending we can parse the file, invalid or not, 
by saturating values.

>           if (!left)
>               return AVERROR_EOF;
>           if (left < 0)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".