Re: [FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig
Date: Mon, 14 Jul 2025 21:21:33 +0200
Message-ID: <20250714192133.GL29660@pb2> (raw)
In-Reply-To: <be81bf5d-6349-4906-b874-1ed6f0951ef6@rothenpieler.org>

[-- Attachment #1.1: Type: text/plain, Size: 2347 bytes --]

On Sun, Jul 13, 2025 at 01:42:28PM +0200, Timo Rothenpieler wrote:
> On 7/13/2025 3:10 AM, Michael Niedermayer wrote:
> > Fixes: Infinite loop
> > Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >   libavformat/flvdec.c | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > index ac681954cb7..a4fa0157512 100644
> > --- a/libavformat/flvdec.c
> > +++ b/libavformat/flvdec.c
> > @@ -1715,6 +1715,9 @@ retry_duration:
> >                   av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel info.\n");
> > +                if (avio_feof(s->pb))
> > +                    return AVERROR_EOF;
> > +
> >                   goto next_track;
> >               }
> >           } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
> 
> I don't think just returning from here is correct.
> The goto next_track right after it already checks for EOF.

> I do not see how between here and the eof check there there'd be any way to
> infinite loop.

avio_skip() with a negative value will reset the EOF flag

> 
> It returns FFERROR_REDO there, which is important to drain queued up
> packages.

I think the state becomes corrupted once it reads into EOF
that is the size accounting goes "oops" as the code keeps running
things that read and keeps accounting for these reads but in reality
nothing is read as its at EOF
and then it seeks back all these "not reads" and thats where it hits the
infinite loop as theres a mismatch what the code thinks it moved forward
and what it actually moved forward.
Thats how it looked to me at least, i have not verified every step of this

ill mail you the testcase, then you can check if my analysis is right
and fix the code in a way that can recover queued packets in such truncated
packet at EOF case.
Also please make sure its not forgotten that whatever fix this gets is backported

thx

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

Give a rich man 100$ and he will turn it into 1000$.
Give a poor man 1000$ and he will spend it.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".