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: <CAG48ez1VMw=aE88eTfk9BscrmS7axJG=j_TrTui+htLF9-4Wqw@mail.gmail.com>
Date: Wed, 2 Jul 2025 19:00:00 +0200
From: Jann Horn <jannh@...gle.com>
To: Rik van Riel <riel@...riel.com>, yury.norov@...il.com, tglx@...utronix.de
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, 
	x86@...nel.org, kernel-team <kernel-team@...a.com>, David Hildenbrand <david@...hat.com>
Subject: Re: [syzbot] [kernel?] KASAN: slab-use-after-free Write in flush_tlb_func

On Wed, Jul 2, 2025 at 6:53 PM Jann Horn <jannh@...gle.com> wrote:
>
> On Wed, Jul 2, 2025 at 5:24 PM Rik van Riel <riel@...riel.com> wrote:
> >
> > On Wed, 2025-07-02 at 06:50 -0700, syzbot wrote:
> > >
> > > The issue was bisected to:
> > >
> > > commit a12a498a9738db65152203467820bb15b6102bd2
> > > Author: Yury Norov [NVIDIA] <yury.norov@...il.com>
> > > Date:   Mon Jun 23 00:00:08 2025 +0000
> > >
> > >     smp: Don't wait for remote work done if not needed in
> > > smp_call_function_many_cond()
> >
> > While that change looks like it would increase the
> > likelihood of hitting this issue, it does not look
> > like the root cause.
> >
> > Instead, the stack traces below show that the
> > TLB flush code is being asked to flush the TLB
> > for an mm that is exiting.
> >
> > One CPU is running the TLB flush handler, while
> > another CPU is freeing the mm_struct.
> >
> > The CPU that sent the simultaneous TLB flush
> > is not visible in the stack traces below,
> > but we seem to have various places around the
> > MM where we flush the TLB for another mm,
> > without taking any measures to protect against
> > that mm being freed while the flush is ongoing.
>
> 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?
>
> And I think the bisected commit really is the buggy one: It looks at
> "nr_cpus", which tracks *how many CPUs we have to IPI*, but assumes
> that "nr_cpus" tracks *how many CPUs we posted work to*. Those numbers
> are not the same: If we post work to a CPU that already had IPI work
> pending, we just add a list entry without sending another IPI.

Or in other words: After that blamed commit, if CPU 1 posts a TLB
flush to CPU 3, and then CPU 2 also quickly posts a TLB flush to CPU
3, then CPU 2 will erroneously not wait for the TLB flush to complete
before reporting flush completion, which AFAICS means we can get both
stale TLB entries and (less often) UAF.

I think the correct version of that commit would be to revert that
commit and instead just move the "run_remote = true;" line down, below
the cond_func() check.