From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH 1/3] avformat/cafdec: sanity check channels and bps Date: Sun, 30 Jun 2024 01:37:05 +0200 Message-ID: <20240629233705.GB4991@pb2> (raw) In-Reply-To: <40908cf3-7e3a-4a57-a23e-43bf153c20bd@gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 2319 bytes --] On Wed, Jun 26, 2024 at 09:52:44PM -0300, James Almer wrote: > On 3/22/2024 8:08 PM, Michael Niedermayer wrote: > > Fixes: Timeout > > Fixes: 67044/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5791144363491328 > > > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > > --- > > libavformat/cafdec.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c > > index 426c56b9bd..334077efb5 100644 > > --- a/libavformat/cafdec.c > > +++ b/libavformat/cafdec.c > > @@ -33,6 +33,7 @@ > > #include "isom.h" > > #include "mov_chan.h" > > #include "libavcodec/flac.h" > > +#include "libavcodec/internal.h" > > #include "libavutil/intreadwrite.h" > > #include "libavutil/intfloat.h" > > #include "libavutil/dict.h" > > @@ -87,6 +88,10 @@ static int read_desc_chunk(AVFormatContext *s) > > st->codecpar->ch_layout.nb_channels = avio_rb32(pb); > > st->codecpar->bits_per_coded_sample = avio_rb32(pb); > > + if (st->codecpar->ch_layout.nb_channels > FF_SANE_NB_CHANNELS || > > + st->codecpar->bits_per_coded_sample > 64) > > Where does the process take so long that oss-fuzz gets a timeout if these > are unreasonably high? I don't see nb_channels used anywhere in here where > that matters. > Is it in the PCM decoder? Because that decoder is meant to handle any > arbitrary amount of channels, so limiting it to whatever FF_SANE_NB_CHANNELS > is set to is not ok. libavutil/channel_layout.c:627:17 or it will OOM before depending on how much memory is available > > And is the bits_per_coded_sample > 64 check to prevent codec_id being > AV_CODEC_ID_NONE? if so, how does that affect demuxing time? > AV_CODEC_ID_NONE for that matter could happen for valid files with a codec > we don't currently support. We generally check read values for validity at the earliest, bits_per_coded_sample of more than 64 seem not valid to me. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus [-- 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".
next prev parent reply other threads:[~2024-06-29 23:37 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-22 23:08 Michael Niedermayer 2024-03-22 23:08 ` [FFmpeg-devel] [PATCH 2/3] avformat/mov: Do not deallocate heif_item in a input dependant way Michael Niedermayer 2024-03-26 1:22 ` James Almer 2024-03-26 19:29 ` Michael Niedermayer 2024-03-22 23:08 ` [FFmpeg-devel] [PATCH 3/3] avformat/aiffdec: Check for previously set channels Michael Niedermayer 2024-04-01 16:59 ` Michael Niedermayer 2024-03-27 7:39 ` [FFmpeg-devel] [PATCH 1/3] avformat/cafdec: sanity check channels and bps Anton Khirnov 2024-03-27 23:27 ` Michael Niedermayer 2024-06-25 19:25 ` Michael Niedermayer 2024-06-25 19:27 ` Anton Khirnov 2024-06-26 23:50 ` Michael Niedermayer 2024-06-27 6:40 ` Paul B Mahol 2024-06-29 23:40 ` Michael Niedermayer 2024-06-27 6:53 ` Anton Khirnov 2024-06-29 23:28 ` Michael Niedermayer 2024-06-27 0:52 ` James Almer 2024-06-29 23:37 ` Michael Niedermayer [this message] 2024-06-30 23:07 ` James Almer 2024-07-01 23:42 ` Michael Niedermayer 2024-07-02 0:01 ` James Almer 2024-07-02 10:50 ` Michael Niedermayer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240629233705.GB4991@pb2 \ --to=michael@niedermayer.cc \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git