Hi Peter On Sun, Jun 22, 2025 at 02:38:46PM +1000, Peter Ross wrote: > On Sat, Jun 21, 2025 at 11:15:19PM +0200, Michael Niedermayer wrote: > > Fixes: signed integer overflow: 2147483647 + 1913651185 cannot be represented in type 'int' > > Fixes: 418335931/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-6568264620900352 > > > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/rv60dec.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavcodec/rv60dec.c b/libavcodec/rv60dec.c > > index 2bbcb1d6209..dbafa7eed02 100644 > > --- a/libavcodec/rv60dec.c > > +++ b/libavcodec/rv60dec.c > > @@ -409,6 +409,8 @@ static int read_slice_sizes(RV60Context *s, GetBitContext *gb) > > if (last_size <= 0) > > return AVERROR_INVALIDDATA; > > s->slice[i].size = last_size; > > + if (s->slice[i].size > INT32_MAX - sum) > > + return AVERROR_INVALIDDATA; > > sum += s->slice[i].size; > > As it turns out, sum is not used for any purpose. > This patch (https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-June/345621.html) > drops sum, obviating the need for your patch. > > However later on in rv60dec.c, line ~2354, there is a similar summation > of slice sizes. This might need a INT_MAX guard? > > for (int i = 0; i < s->cu_height; i++) { > if (header_size + ofs >= avpkt->size) > return AVERROR_INVALIDDATA; > s->slice[i].data = avpkt->data + header_size + ofs; > s->slice[i].data_size = FFMIN(s->slice[i].size, avpkt->size - header_size - ofs); > ofs += s->slice[i].size; > } teh same testcase also triggers the overflow on the 2nd case if it gets past the first new patch posted thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato