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

[Rik van Riel <riel@surriel.com>]

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.