On Fri, Sep 29, 2023 at 08:41:23PM -0300, James Almer wrote: > 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 <mich...@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. yes ill try that thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time.
signature.asc
Description: PGP signature
_______________________________________________ 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".
