public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: DJ Delorie <dj@redhat.com>
To: Ben Kallus <benjamin.p.kallus.gr@dartmouth.edu>
Cc: libc-alpha@sourceware.org, adhemerval.zanella@linaro.org
Subject: Re: [PATCH] malloc: Add integrity check to largebin nextsizes
Date: Mon, 24 Feb 2025 16:45:40 -0500	[thread overview]
Message-ID: <xnldtvkoe3.fsf@greed.delorie.com> (raw)
In-Reply-To: <20250214053454.2346370-1-benjamin.p.kallus.gr@dartmouth.edu> (message from Ben Kallus on Fri, 14 Feb 2025 00:34:54 -0500)


Ben Kallus <benjamin.p.kallus.gr@dartmouth.edu> writes:
> If attacker overwrites the bk_nextsize link in the first chunk of a
> largebin that later has a smaller chunk inserted into it, malloc will
> write a heap pointer into an attacker-controlled address [0].

LGTM.  Do you need someone to commit this on your behalf?

Reviewed-by: DJ Delorie <dj@redhat.com>

> @@ -4244,6 +4244,9 @@ _int_malloc (mstate av, size_t bytes)

At this point bck = bin() and fwd = bck->fd

>                        fwd = bck;
>                        bck = bck->bk;

So here, fwd = bin() and bck = bin()->bk (the last chunk in the chain,
which may or may not be part of the nextsize chain)

> +                      if (__glibc_unlikely (fwd->fd->bk_nextsize->fd_nextsize != fwd->fd))
> +                        malloc_printerr ("malloc(): largebin double linked list corrupted (nextsize)");

fwd->fd is thus the first chunk in the chain, which is the first of its
size (by definition).

fwd->fd->bk_nextsize is thus the last "first of its size" chunk in the
chain, and may be tainted.

fwd->fd->bk_nextsize->fd_nextsize is thus the first chunk in the chain,
but relies on the tainted fwd->fd->bk_nextsize

If the user controls fwd->fd->bk_nextsize, and we dereference it, we're
reading from an attacker-chosen site.  This is normally not a problem,
but it could be used as part of a cache attack (like rowhammer et al),
where reads are used to probe or corrupt the cache.

I think this is a risk we'll have to take as I can't see any other way
to get to the last first-in-size without iterating through the entire
chain, and we rely on these pointers being accurate anyway.  An attempt
to poison the cache would, with this patch, cause the application to
exit.

So OK.

>                        victim->fd_nextsize = fwd->fd;
>                        victim->bk_nextsize = fwd->fd->bk_nextsize;
>                        fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim;


  reply	other threads:[~2025-02-24 21:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14  5:34 Ben Kallus
2025-02-24 21:45 ` DJ Delorie [this message]
2025-02-24 22:04   ` Ben Kallus
2025-03-04  3:09     ` DJ Delorie

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=xnldtvkoe3.fsf@greed.delorie.com \
    --to=dj@redhat.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=benjamin.p.kallus.gr@dartmouth.edu \
    --cc=libc-alpha@sourceware.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).