[FFmpeg-devel] [PATCH v2 1/2] avcodec/vvc_mp4toannexb: check bytes left for nalu_len

[Nuo Mi]

On Sat, Feb 10, 2024 at 6:57 PM Andreas Rheinhardt <
andreas.rheinhardt at outlook.com> wrote:

> Nuo Mi:
> > On Fri, Feb 9, 2024 at 7:40 PM Andreas Rheinhardt <
> > andreas.rheinhardt at outlook.com> wrote:
> >
> >> Nuo Mi:
> >>> Fixes: fuzzer timeout
> >>> Fixes:
> >>
> 65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
> >>>
> >>> Found-by: continuous fuzzing process
> >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> >>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
> >>> ---
> >>>  libavcodec/bsf/vvc_mp4toannexb.c | 7 ++++---
> >>>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/libavcodec/bsf/vvc_mp4toannexb.c
> >> b/libavcodec/bsf/vvc_mp4toannexb.c
> >>> index 25c3726918..36bdae8f49 100644
> >>> --- a/libavcodec/bsf/vvc_mp4toannexb.c
> >>> +++ b/libavcodec/bsf/vvc_mp4toannexb.c
> >>> @@ -155,10 +155,11 @@ static int vvc_extradata_to_annexb(AVBSFContext
> >> *ctx)
> >>>          }
> >>>
> >>>          for (j = 0; j < cnt; j++) {
> >>> -            int nalu_len = bytestream2_get_be16(&gb);
> >>> +            const int nalu_len = bytestream2_get_be16(&gb);
> >>>
> >>> -            if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len >
> >>> -                SIZE_MAX - new_extradata_size) {
> >>> +            if (!nalu_len ||
> >>> +                nalu_len > bytestream2_get_bytes_left(&gb) ||
> >>> +                4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > SIZE_MAX
> >> - new_extradata_size) {
> >>>                  ret = AVERROR_INVALIDDATA;
> >>>                  goto fail;
> >>>              }
> >>
> >> What about growing the packet?
> >>
> > Hi Andreas,
> > Do you mean growing the packet only once for all nalus?
> > However, this would change the original behavior and result in more
> > duplicate code between the HEVC and VVC implementations.
> > I can do it, but I'll refactor duplications to h2656_mp4toannexb.c first.
> > Do you think that's okay?
> > Thank you
> >
>
> I meant a simple check before growing the packet to ensure that there is
> enough input left as the header claims there to be. Your original patch
> added such a check, so I presumed that there is none. But there is one
> (both here and in hevc_mp4toannexb). So my above point is moot.

Thank you for the explanation.  Your suggestion for the original patch is
pretty good.  Thank you
Applied.

>


> - Andreas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>