| Message ID | 20200206134549.29792-2-michael@niedermayer.cc |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [FFmpeg-devel,1/3] avcodec/cavsdsp: Fix invalid left shifts in cavs_idct8_add_c() | expand |
| Context | Check | Description |
|---|---|---|
| andriy/ffmpeg-patchwork | success | Make fate finished |
Nonsense, why would this code be called with 0 buffer? On 2/6/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > Fixes: division by zero > Fixes: > 20436/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5763229752229888 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > libavformat/tty.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavformat/tty.c b/libavformat/tty.c > index 60f7e9f87e..854a23c500 100644 > --- a/libavformat/tty.c > +++ b/libavformat/tty.c > @@ -53,6 +53,9 @@ static int read_probe(const AVProbeData *p) > { > int cnt = 0; > > + if (!p->buf_size) > + return 0; > + > for (int i = 0; i < p->buf_size; i++) > cnt += !!isansicode(p->buf[i]); > > -- > 2.17.1 > > _______________________________________________ > 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".
On Thu, Feb 06, 2020 at 03:27:11PM +0100, Paul B Mahol wrote: > Nonsense, why would this code be called with 0 buffer? I guess because code calls av_probe_input_format3() with a 0 buffer its a public function and called by multiple places from our code base as well. Theres even code in it to handle the case of a 0 sized input. The code that triggers it in this case seems to be probing the stream content. Its not a 0 byte input file Thanks > > On 2/6/20, Michael Niedermayer <michael@niedermayer.cc> wrote: > > Fixes: division by zero > > Fixes: > > 20436/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5763229752229888 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > > --- > > libavformat/tty.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavformat/tty.c b/libavformat/tty.c > > index 60f7e9f87e..854a23c500 100644 > > --- a/libavformat/tty.c > > +++ b/libavformat/tty.c > > @@ -53,6 +53,9 @@ static int read_probe(const AVProbeData *p) > > { > > int cnt = 0; > > > > + if (!p->buf_size) > > + return 0; > > + > > for (int i = 0; i < p->buf_size; i++) > > cnt += !!isansicode(p->buf[i]); > > > > -- > > 2.17.1 > > > > _______________________________________________ > > 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". > _______________________________________________ > 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".
On Fri, Feb 7, 2020 at 12:16 AM Michael Niedermayer <michaelni@gmx.at> wrote: > > On Thu, Feb 06, 2020 at 03:27:11PM +0100, Paul B Mahol wrote: > > Nonsense, why would this code be called with 0 buffer? > > I guess because code calls av_probe_input_format3() with a 0 buffer > its a public function and called by multiple places from our code base > as well. Theres even code in it to handle the case of a 0 sized input. > > The code that triggers it in this case seems to be probing the stream > content. Its not a 0 byte input file > The generic code in the public API calls should probably catch that then, a probe function really can't do anything meaningful on a NULL or zero-sized buffer. - Hendrik
On Fri, Feb 07, 2020 at 12:19:32AM +0100, Hendrik Leppkes wrote: > On Fri, Feb 7, 2020 at 12:16 AM Michael Niedermayer <michaelni@gmx.at> wrote: > > > > On Thu, Feb 06, 2020 at 03:27:11PM +0100, Paul B Mahol wrote: > > > Nonsense, why would this code be called with 0 buffer? > > > > I guess because code calls av_probe_input_format3() with a 0 buffer > > its a public function and called by multiple places from our code base > > as well. Theres even code in it to handle the case of a 0 sized input. > > > > The code that triggers it in this case seems to be probing the stream > > content. Its not a 0 byte input file > > > > The generic code in the public API calls should probably catch that > then, a probe function really can't do anything meaningful on a NULL > or zero-sized buffer. some of our probe functions have code to handle zero buffers, an example of this is to search the file name for placeholders like %d with image extensions. If the file failed to open and has that in its name that identifies it as a sequence of images. I suspect v4l2 will also give you a 0 buffer and i guess there are others Thanks [...]
diff --git a/libavformat/tty.c b/libavformat/tty.c index 60f7e9f87e..854a23c500 100644 --- a/libavformat/tty.c +++ b/libavformat/tty.c @@ -53,6 +53,9 @@ static int read_probe(const AVProbeData *p) { int cnt = 0; + if (!p->buf_size) + return 0; + for (int i = 0; i < p->buf_size; i++) cnt += !!isansicode(p->buf[i]);
Fixes: division by zero Fixes: 20436/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5763229752229888 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- libavformat/tty.c | 3 +++ 1 file changed, 3 insertions(+)