[FFmpeg-devel] [PATCH 3/4] avcodec/h264_parser: Fix nalsize check

Michael Niedermayer michael at niedermayer.cc
Mon Sep 6 23:36:54 EEST 2021


On Sun, Sep 05, 2021 at 09:51:32PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: Assertion failure
> > Fixes: 37463/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-4914693494931456
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > ---
> >  libavcodec/h264_parser.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> > index 01ea016409..47cc1d5c78 100644
> > --- a/libavcodec/h264_parser.c
> > +++ b/libavcodec/h264_parser.c
> > @@ -87,7 +87,7 @@ static int h264_find_frame_end(H264ParseContext *p, const uint8_t *buf,
> >              i = next_avc;
> >              for (j = 0; j < p->nal_length_size; j++)
> >                  nalsize = (nalsize << 8) | buf[i++];
> > -            if (!nalsize || nalsize > buf_size - i) {
> > +            if (!nalsize || i > buf_size || nalsize > buf_size - i) {
> >                  av_log(logctx, AV_LOG_ERROR, "AVC-parser: nal size %"PRIu32" "
> >                         "remaining %d\n", nalsize, buf_size - i);
> >                  return buf_size;
> > 
> The cheapest fix for this is to make nalsize int64_t. But actually this
> whole code looks highly weird: In contrast to how the parsing API is
> supposed to be, it requires the whole buffer being available, despite
> the PARSER_FLAG_COMPLETE_FRAMES being unset.

you are correct, this implementation assumes things beyond what the
API alone gurantees packetization wise.
the various specs gurantee that though i think for H.264
If you or someone wants to implement the generic case, i think its a good
idea. OTOH if not i dont think that will be a problem either.
as you prefer int64_t instead of the check, i will apply that change
instead

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210906/0a634d2a/attachment.sig>


More information about the ffmpeg-devel mailing list