linux-kernel - Re: [PATCH] mm/mmap_lock: Reset maple state on lock_vma_under

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aRUggwAQJsnQV_07@casper.infradead.org>
Date: Thu, 13 Nov 2025 00:04:19 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Suren Baghdasaryan <surenb@...gle.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Shakeel Butt <shakeel.butt@...ux.dev>, Jann Horn <jannh@...gle.com>,
	stable@...r.kernel.org,
	syzbot+131f9eb2b5807573275c@...kaller.appspotmail.com,
	"Paul E . McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH] mm/mmap_lock: Reset maple state on lock_vma_under_rcu()
 retry

On Wed, Nov 12, 2025 at 03:06:38PM +0000, Lorenzo Stoakes wrote:
> > Any time the rcu read lock is dropped, the maple state must be
> > invalidated.  Resetting the address and state to MA_START is the safest
> > course of action, which will result in the next operation starting from
> > the top of the tree.
> 
> Since we all missed it I do wonder if we need some super clear comment
> saying 'hey if you drop + re-acquire RCU lock you MUST revalidate mas state
> by doing 'blah'.

I mean, this really isn't an RCU thing.  This is also bad:

	spin_lock(a);
	p = *q;
	spin_unlock(a);
	spin_lock(a);
	b = *p;

p could have been freed while you didn't hold lock a.  Detecting this
kind of thing needs compiler assistence (ie Rust) to let you know that
you don't have the right to do that any more.

> I think one source of confusion for me with maple tree operations is - what
> to do if we are in a position where some kind of reset is needed?
> 
> So even if I'd realised 'aha we need to reset this' it wouldn't be obvious
> to me that we ought to set to the address.

I think that's a separate problem.

> > +++ b/mm/mmap_lock.c
> > @@ -257,6 +257,7 @@ struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
> >  		if (PTR_ERR(vma) == -EAGAIN) {
> >  			count_vm_vma_lock_event(VMA_LOCK_MISS);
> >  			/* The area was replaced with another one */
> > +			mas_set(&mas, address);
> 
> I wonder if we could detect that the RCU lock was released (+ reacquired) in
> mas_walk() in a debug mode, like CONFIG_VM_DEBUG_MAPLE_TREE?

Dropping and reacquiring the RCU read lock should have been a big red
flag.  I didn't have time to review the patches, but if I had, I would
have suggested passing the mas down to the routine that drops the rcu
read lock so it can be invalidated before dropping the readlock.