From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions. Date: Mon, 5 Feb 2024 21:07:36 +0100 Message-ID: <20240205200736.GS6420@pb2> (raw) In-Reply-To: <CAPUDrwcdy7-1CeAJ79_btNmuK1v=MHDSJqdbEBnuObT4RJ1aGg@mail.gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 3155 bytes --] On Fri, Feb 02, 2024 at 03:45:24PM -0800, Dale Curtis wrote: > On Fri, Feb 2, 2024 at 3:42 PM Dale Curtis <dalecurtis@chromium.org> wrote: > > > On Fri, Feb 2, 2024 at 3:20 PM Andreas Rheinhardt < > > andreas.rheinhardt@outlook.com> wrote: > > > >> Dale Curtis: > >> > + // Clamp allocation size for `chunk_offsets` -- don't throw an > >> error for an > >> > + // invalid count since the EOF path doesn't throw either. > >> > + entries = > >> > + FFMIN(entries, FFMIN(atom.size - 8, avio_size(pb) - > >> avio_tell(pb)) / > >> > + (atom.type == MKTAG('s', 't', 'c', 'o') ? 4 > >> : 8)); > >> > + > >> > >> This may call avio_size() and avio_tell() multiple times. Furthermore, > >> is it even certain that avio_size() returns a sane value? > >> > > > > I hope so since there are other usages of avio_size() throughout the file > > in a similar manner. I guess you're saying it may be invalid when > > !AVIO_SEEKABLE_NORMAL? Sticking to just atom.size is also fine. > > > > Here's a version of the patch which does just that. > mov.c | 7 +++++++ > 1 file changed, 7 insertions(+) > d5ba3836202adc762f38f03cbb5e30921e6073b4 stco-clamp-entries-v2.patch > From b76f526a01788a11e625eb1d7d7005a1959df75c Mon Sep 17 00:00:00 2001 > From: Dale Curtis <dalecurtis@chromium.org> > Date: Fri, 2 Feb 2024 20:49:44 +0000 > Subject: [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions. > > The `entries` value is read directly from the stream and used to > allocate memory. This change clamps `entries` to however many are > possible in the remaining atom or file size (whichever is smallest). > > Fixes https://crbug.com/1429357 > > Signed-off-by: Dale Curtis <dalecurtis@chromium.org> > --- > libavformat/mov.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index af95e1f662..25e5beadcf 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -2237,6 +2237,13 @@ static int mov_read_stco(MOVContext *c, AVIOContext *pb, MOVAtom atom) > av_log(c->fc, AV_LOG_WARNING, "Ignoring duplicated STCO atom\n"); > return 0; > } > + > + // Clamp allocation size for `chunk_offsets` -- don't throw an error for an > + // invalid count since the EOF path doesn't throw either. > + entries = > + FFMIN(entries, (atom.size - 8) / > + (atom.type == MKTAG('s', 't', 'c', 'o') ? 4 : 8)); assuming atom.size is an arbitrary 64bit value then the value of FFMIN() is also 64bit but entries is unsigned 32bit, this truncation would allow setting entries to values outside whats expected from FFMIN() also we seem to disalllow entries == 0 before this and its maybe possible to set entries = 0 here, bypassing the == 0 check before thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras [-- 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-02-05 20:07 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-02 23:09 Dale Curtis 2024-02-02 23:22 ` Andreas Rheinhardt 2024-02-02 23:42 ` Dale Curtis 2024-02-02 23:45 ` Dale Curtis 2024-02-05 20:07 ` Michael Niedermayer [this message] 2024-02-15 20:07 ` Dale Curtis 2024-02-15 22:35 ` Michael Niedermayer 2024-02-16 21:41 ` Dale Curtis 2024-02-21 17:27 ` 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=20240205200736.GS6420@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