Re: [syzbot] [mm?] KCSAN: data-race in mas_wr_slot_store / mtree_range_walk

[Marco Elver]

On Wed, 10 Jun 2026 at 23:21, Jay Vadayath <jkrshnmenon@xxxxxxxxx> wrote:
>
> Hello,
>
> I am a security researcher and was able to independently reproduce this
> data race on an x86-64 host using a KCSAN-enabled build of the affected
> kernel version (3cd8b194bf3428dfa53120fee47e827a7c495815).
> The crash can be reliably triggered using the provided PoC.

It's not a crash, it's a data-race report. Data races are more subtle,
while technically UB, they are tolerated in some cases in the kernel;
please see: https://lwn.net/Articles/816850/

> However, I am not aware of a method that can take advantage of this bug
> to achieve a practical exploit.

An analysis of its severity would be appreciated (e.g. corrupts data, etc.).

We've been trying to do this with syzbot. This report was also caught
by syzbot, and we have some AI-based workflows that attempt to analyze
benign'ness/harmfulness (take it with a bucket of salt):

> An unprivileged user can easily trigger this data race by performing concurrent
> `mmap()` operations and memory accesses (page faults). However, the race only
> results in a spurious fallback to the slow path of the page fault handler. It
> cannot lead to memory corruption, privilege escalation, or denial of service.

Sounds plausible. Source:
https://syzbot.org/bug?id=3ce3ffd8320398fb3336831c3cb1e7b3ba60d64a

Either way, marking the accesses appropriately is typically encouraged
so that optimizing compilers don't become too clever and break the
code in future:
https://docs.kernel.org/dev-tools/lkmm/docs/access-marking.html