Re: BUG: KCSAN: data-race in do_mremap / vma_complete

From: Lorenzo Stoakes (Oracle)

Date: Wed Mar 11 2026 - 12:41:22 EST


On Wed, Mar 11, 2026 at 04:17:13PM +0000, Lorenzo Stoakes (Oracle) wrote:
> On Wed, Mar 11, 2026 at 10:27:32AM +0000, Pedro Falcato wrote:
> > Well, the problem is that the data_race() is incorrect. It would only be okay
> > if the check could fail (with no bad side-effects). Otherwise, we need READ_ONCE()
> > and WRITE_ONCE().
>
> Yeah true, also a user can update sysctl_max_map_count without any mmap locks
> held obviously.
>
> So we're probably in a state of sin generally that we've previously tolerated.
>
> Anyway, that check seems to be wrong, so I'm going to send a patch that fixes
> it, and I'll update the logic to READ_ONCE() this variable. (proc_int_conv()
> already does a WRITE_ONCE()).

Also, updating to only check this once mmap write lock held, so avoid the
racey situation altogether.

Cheers, Lorenzo