Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

  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