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: <f73e23f363b780a0e33e8b0ab7171a2128e16df6.camel@surriel.com>
Date: Wed, 02 Jul 2025 13:09:02 -0400
From: Rik van Riel <riel@...riel.com>
To: Jann Horn <jannh@...gle.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>
Subject: Re: [syzbot] [kernel?] KASAN: slab-use-after-free Write in
 flush_tlb_func

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.

> 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.
> 
Good point, we do need to wait when we enqueue
work, even if we do not send an IPI anywhere!

You are right that the bisected commit is buggy
and should be reverted.

-- 
All Rights Reversed.