| Message ID | 20220818223535.13078-4-michael@niedermayer.cc |
|---|---|
| State | Accepted |
| Commit | f0395f9ef6051315973f1fdded1804f81458566d |
| Headers | show |
| Series | [FFmpeg-devel,1/4] avcodec/bethsoftvideo: Pass GetByteContext into set_palette() | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
On Fri, Aug 19, 2022 at 12:36 AM Michael Niedermayer <michael@niedermayer.cc> wrote: > Fixes: out of array access > Fixes: > 50014/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEDHQ_fuzzer-4748914632294400 > > Alternatively the buffer size can be increased > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > Michael Niedermayer <michael@niedermayer.cc> > --- > libavcodec/speedhq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c > index c43de4f199..ffee5f973b 100644 > --- a/libavcodec/speedhq.c > +++ b/libavcodec/speedhq.c > @@ -499,7 +499,7 @@ static int speedhq_decode_frame(AVCodecContext *avctx, > AVFrame *frame, > uint32_t second_field_offset; > int ret; > > - if (buf_size < 4 || avctx->width < 8) > + if (buf_size < 4 || avctx->width < 8 || avctx->width % 8 != 0) > return AVERROR_INVALIDDATA; > Is this right thing to do? > > quality = buf[0]; > -- > 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 Sun, Aug 21, 2022 at 12:54:57PM +0200, Paul B Mahol wrote: > On Fri, Aug 19, 2022 at 12:36 AM Michael Niedermayer <michael@niedermayer.cc> > wrote: > > > Fixes: out of array access > > Fixes: > > 50014/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEDHQ_fuzzer-4748914632294400 > > > > Alternatively the buffer size can be increased > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by > > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > > Michael Niedermayer <michael@niedermayer.cc> > > --- > > libavcodec/speedhq.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c > > index c43de4f199..ffee5f973b 100644 > > --- a/libavcodec/speedhq.c > > +++ b/libavcodec/speedhq.c > > @@ -499,7 +499,7 @@ static int speedhq_decode_frame(AVCodecContext *avctx, > > AVFrame *frame, > > uint32_t second_field_offset; > > int ret; > > > > - if (buf_size < 4 || avctx->width < 8) > > + if (buf_size < 4 || avctx->width < 8 || avctx->width % 8 != 0) > > return AVERROR_INVALIDDATA; > > > > Is this right thing to do? We can increase the buffer size or change how the %8 != 0 case is handled WIthout a non fuzzed file with such dimensions, I do not know what the correct handling of such a file is. What do you prefer to be done ? Thanks [...]
On Sun, Aug 21, 2022 at 04:23:09PM +0200, Michael Niedermayer wrote: > On Sun, Aug 21, 2022 at 12:54:57PM +0200, Paul B Mahol wrote: > > On Fri, Aug 19, 2022 at 12:36 AM Michael Niedermayer <michael@niedermayer.cc> > > wrote: > > > > > Fixes: out of array access > > > Fixes: > > > 50014/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEDHQ_fuzzer-4748914632294400 > > > > > > Alternatively the buffer size can be increased > > > > > > Found-by: continuous fuzzing process > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > Signed-off-by > > > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > > > Michael Niedermayer <michael@niedermayer.cc> > > > --- > > > libavcodec/speedhq.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c > > > index c43de4f199..ffee5f973b 100644 > > > --- a/libavcodec/speedhq.c > > > +++ b/libavcodec/speedhq.c > > > @@ -499,7 +499,7 @@ static int speedhq_decode_frame(AVCodecContext *avctx, > > > AVFrame *frame, > > > uint32_t second_field_offset; > > > int ret; > > > > > > - if (buf_size < 4 || avctx->width < 8) > > > + if (buf_size < 4 || avctx->width < 8 || avctx->width % 8 != 0) > > > return AVERROR_INVALIDDATA; > > > > > > > Is this right thing to do? > > We can increase the buffer size or change how the %8 != 0 case is handled > WIthout a non fuzzed file with such dimensions, I do not know what the > correct handling of such a file is. > What do you prefer to be done ? ping [...]
On Sun, Aug 28, 2022 at 07:39:53PM +0200, Michael Niedermayer wrote: > On Sun, Aug 21, 2022 at 04:23:09PM +0200, Michael Niedermayer wrote: > > On Sun, Aug 21, 2022 at 12:54:57PM +0200, Paul B Mahol wrote: > > > On Fri, Aug 19, 2022 at 12:36 AM Michael Niedermayer <michael@niedermayer.cc> > > > wrote: > > > > > > > Fixes: out of array access > > > > Fixes: > > > > 50014/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEDHQ_fuzzer-4748914632294400 > > > > > > > > Alternatively the buffer size can be increased > > > > > > > > Found-by: continuous fuzzing process > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > > Signed-off-by > > > > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > > > > Michael Niedermayer <michael@niedermayer.cc> > > > > --- > > > > libavcodec/speedhq.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c > > > > index c43de4f199..ffee5f973b 100644 > > > > --- a/libavcodec/speedhq.c > > > > +++ b/libavcodec/speedhq.c > > > > @@ -499,7 +499,7 @@ static int speedhq_decode_frame(AVCodecContext *avctx, > > > > AVFrame *frame, > > > > uint32_t second_field_offset; > > > > int ret; > > > > > > > > - if (buf_size < 4 || avctx->width < 8) > > > > + if (buf_size < 4 || avctx->width < 8 || avctx->width % 8 != 0) > > > > return AVERROR_INVALIDDATA; > > > > > > > > > > Is this right thing to do? > > > > We can increase the buffer size or change how the %8 != 0 case is handled > > WIthout a non fuzzed file with such dimensions, I do not know what the > > correct handling of such a file is. > > > What do you prefer to be done ? > > ping i will apply this in the next 24h thx [...]
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c index c43de4f199..ffee5f973b 100644 --- a/libavcodec/speedhq.c +++ b/libavcodec/speedhq.c @@ -499,7 +499,7 @@ static int speedhq_decode_frame(AVCodecContext *avctx, AVFrame *frame, uint32_t second_field_offset; int ret; - if (buf_size < 4 || avctx->width < 8) + if (buf_size < 4 || avctx->width < 8 || avctx->width % 8 != 0) return AVERROR_INVALIDDATA; quality = buf[0];
Fixes: out of array access Fixes: 50014/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEDHQ_fuzzer-4748914632294400 Alternatively the buffer size can be increased Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- libavcodec/speedhq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)