On 8/16/20, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Sun, Aug 16, 2020 at 05:38:29PM +0200, Paul B Mahol wrote: >> On 8/16/20, Michael Niedermayer <mich...@niedermayer.cc> wrote: >> > Fixes: signed integer overflow: 317316873 * 10 cannot be represented in >> > type >> > 'int' >> > Fixes: >> > 24708/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5731180885049344 >> > >> > Found-by: continuous fuzzing process >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> > --- >> > libavformat/utils.c | 5 ++++- >> > 1 file changed, 4 insertions(+), 1 deletion(-) >> > >> > diff --git a/libavformat/utils.c b/libavformat/utils.c >> > index 807d9f10cb..60e6fe5be5 100644 >> > --- a/libavformat/utils.c >> > +++ b/libavformat/utils.c >> > @@ -4745,8 +4745,11 @@ int av_get_frame_filename2(char *buf, int >> > buf_size, >> > const char *path, int number >> > if (c == '%') { >> > do { >> > nd = 0; >> > - while (av_isdigit(*p)) >> > + while (av_isdigit(*p)) { >> > + if (nd >= INT_MAX / 10 - 255) >> > + goto fail; >> > nd = nd * 10 + *p++ - '0'; >> > + } >> > c = *p++; >> > } while (av_isdigit(c)); >> > >> >> Why to limit it? >> Use int64_t? > > The buffer is only 20 bytes long, INT_MAX is already a few million times > more than what would work
Buffer size is wrong. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Concerning the gods, I have no means of knowing whether they exist or not > or of what sort they may be, because of the obscurity of the subject, and > the brevity of human life -- Protagoras > _______________________________________________ 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".
