[FFmpeg-devel] [PATCH 2/2] avcodec/vvc/refs: Check content_ref in set_pict_type()

[Nuo Mi]

On Fri, Feb 7, 2025 at 4:25 AM Frank Plowman <post at frankplowman.com> wrote:

> On 02/02/2025 21:17, Michael Niedermayer wrote:
> > Fixes:
> 390565846/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-4990028521996288
> > Fixes: Null pointer dereference
> >
> > 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/vvc/refs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c
> > index 486515d06db..1cfca482047 100644
> > --- a/libavcodec/vvc/refs.c
> > +++ b/libavcodec/vvc/refs.c
> > @@ -186,7 +186,7 @@ static void set_pict_type(AVFrame *frame, const
> VVCContext *s, const VVCFrameCon
> >          const CodedBitstreamFragment *current = &s->current_frame;
> >          for (int i = 0; i < current->nb_units && !has_b; i++) {
> >              const CodedBitstreamUnit *unit = current->units + i;
> > -            if (unit->type <= VVC_RSV_IRAP_11) {
> > +            if (unit->content_ref && unit->type <= VVC_RSV_IRAP_11) {
> >                  const H266RawSliceHeader *rsh = unit->content_ref;
> >                  has_inter |= !IS_I(rsh);
> >                  has_b     |= IS_B(rsh);
>
> I did a little more sniffing around this.  unit->content and
> unit->content_ref are NULL for NAL units with a type code corresponding
> with a reserved or unspecified NAL unit type.  Due to the existing
> condition on the NAL unit type being a VCL NAL unit type, this means
> that unit->type will be in [4..6], which are all reserved.
>
> Perhaps we might want to add a warning message or something similar
> letting the user know some data is being skipped, particularly seeing as
> we are talking about video data here?  On the other hand, if the
> loglevel is set to verbose or above, cbs_read_fragment_content will
> produce some log output which eludes to this, although it is a bit
> obtuse as codec-specific information is not available there.

We can do this with other patch.

> In any
> case, I agree that adding the extra check on unit->content_ref is correct.
>
Thank you, Frank and Micheal.
Will apply.

>
> Thank you,
> Frank
>
> _______________________________________________
> 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".
>