linux-kernel - Re: [PATCH] mm/rmap: Add anon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3e77eed-10b9-4197-b381-91c4ea3fc576@lucifer.local>
Date: Fri, 25 Jul 2025 16:22:48 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jann Horn <jannh@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...hat.com>, Rik van Riel <riel@...riel.com>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Harry Yoo <harry.yoo@...cle.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/rmap: Add anon_vma lifetime debug check

On Fri, Jul 25, 2025 at 05:15:45PM +0200, Jann Horn wrote:
> On Fri, Jul 25, 2025 at 5:07 PM Lorenzo Stoakes
> <lorenzo.stoakes@...cle.com> wrote:
> > On Fri, Jul 25, 2025 at 04:48:09PM +0200, Jann Horn wrote:
> > > On Fri, Jul 25, 2025 at 3:49 PM Lorenzo Stoakes
> > > <lorenzo.stoakes@...cle.com> wrote:
> > > > On Fri, Jul 25, 2025 at 02:00:18PM +0200, Jann Horn wrote:
> > > > > > We're sort of relying on this
> > > > > >
> > > > > > a. being a UAF
> > > > > >
> > > > > > b. the thing we're UAF-ing not either corrupting this field or (if that
> > > > > >     memory is actually reused as an anon_vma - I'm not familiar with slab
> > > > > >     caches - so maybe it's quite likely - getting its refcount incremented.
> > > > >
> > > > > KASAN sees the memory read I'm doing with this atomic_read(), so in
> > > > > KASAN builds, if this is a UAF, it should trigger a KASAN splat
> > > > > (modulo KASAN limitations around when UAF can be detected). Basically,
> > > > > in KASAN builds, the actual explicit check I'm doing here is only
> > > > > relevant if the object has not yet been freed. That's why I wrote the
> > > > > comment "Part of the purpose of the atomic_read() is to make KASAN
> > > > > check that the anon_vma is still alive.".
> > > >
> > > > Hm, I'm confused, how can you detect a UAF if the object cannot yet be
> > > > freed? :P
> > > >
> > > > or would that be the case were it not an atomic_read()?
> > > >
> > > > I guess this permits this to be detected in a timely manner.
> > >
> > > If the anon_vma hasn't yet been freed, but its refcount is 0, then
> > > that's still a bug because we rely on the anon_vma to have a nonzero
> > > refcount as long as there are folios with a nonzero mapcount that are
> > > tied to it, and it is likely to allow UAF at a later point.
> >
> > But how is this happening?
> >
> > The only places where we might explicitly manipulate anon_vma->refcount
> > are:
> >
> > - anon_vma_ctor() -> set to 0 on construction used by slab.
> > - folio_lock_anon_vma_read() / put_anon_vma() - both cases call
> >   __put_anon_vma() when 0 to free the anon_vma.
> >
> > So how could we get to a refcount of 0 but the anon_vma still be hanging
> > around, except if it's freshly allocated?
>
> Due to SLAB_TYPESAFE_BY_RCU, the anon_vma is guaranteed to still be
> accessible (possibly post-recycling) for an RCU grace period after its

Right that makes sense.

> refcount drops to zero. Under CONFIG_SLUB_RCU_DEBUG (which you need
> for KASAN to catch UAF in such slabs semi-reliably), from KASAN's
> perspective, the anon_vma is effectively freed after an RCU grace
> period.

By UAF I mean used after kmem_cache_free(), but I hadn't grokked this point but
y'know kinda makes sense given the name...

>
> Basically CONFIG_SLUB_RCU_DEBUG turns kmem_cache_free() on
> SLAB_TYPESAFE_BY_RCU slabs into something like kfree_rcu(), and this
> allows KASAN to catch UAF access.
>
> > It's surely only UAF?
>
> I mean, "UAF" is kind of vague when talking about SLAB_TYPESAFE_BY_RCU
> slabs. I am only using the term "UAF" when talking about a situation
> where accessing the anon_vma object is entirely forbidden because an
> RCU grace period has passed after it was "freed" with
> kmem_cache_free().

Could it not be either case? Or are we sure it's been accessed within that grace
period?