linux-kernel - Re: [syzbot] [kernel?] KASAN: slab-use-after-free Write in flush_tlb

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: <CAG48ez1DgJg0MvrdYy7xTeAbZG6mkiGRU=6vvEdvwos26bNsMA@mail.gmail.com>
Date: Wed, 2 Jul 2025 19:23:21 +0200
From: Jann Horn <jannh@...gle.com>
To: Rik van Riel <riel@...riel.com>
Cc: syzbot <syzbot+084b6e5bc1016723a9c4@...kaller.appspotmail.com>, bp@...en8.de, 
	dave.hansen@...ux.intel.com, hpa@...or.com, linux-kernel@...r.kernel.org, 
	luto@...nel.org, mingo@...hat.com, neeraj.upadhyay@...nel.org, 
	paulmck@...nel.org, peterz@...radead.org, syzkaller-bugs@...glegroups.com, 
	tglx@...utronix.de, x86@...nel.org, yury.norov@...il.com, 
	kernel-team <kernel-team@...a.com>, David Hildenbrand <david@...hat.com>, 
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Subject: Re: [syzbot] [kernel?] KASAN: slab-use-after-free Write in flush_tlb_func

On Wed, Jul 2, 2025 at 7:17 PM Rik van Riel <riel@...riel.com> wrote:
> On Wed, 2025-07-02 at 18:53 +0200, Jann Horn wrote:
> > TLB flushes via IPIs on x86 are always synchronous, right?
> > flush_tlb_func is only referenced from native_flush_tlb_multi() in
> > calls to on_each_cpu_mask() (with wait=true) or
> > on_each_cpu_cond_mask() (with wait=1).
> > So I think this is not an issue, unless you're claiming that we call
> > native_flush_tlb_multi() with an already-freed info->mm?
> >
> It looks like there are a least some cases where
> try_to_unmap() can call flush_tlb_range() with
> an mm that belongs to some other process.
>
> I don't know whether that is an issue.

try_to_unmap() relies on read-locking either the anon_vma (for
anonymous pages) or the address_space (for file pages) throughout the
entire rmap walk to ensure that the list of VMAs attached to the
anon_vma/address_space stays stable during the operation, which
guarantees that those VMAs can't go away, which guarantees that the
associated MMs can't go away.

If the caller passes in TTU_RMAP_LOCKED, they promise that they've
already taken care of this rmap locking; otherwise, rmap_walk() will
do it internally.