Re: rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree]

[Al Viro]

On Fri, Jun 19, 2026 at 12:24:58AM +0200, Thomas Gleixner wrote:
> Subject: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()
> From: Thomas Gleixner <tglx@xxxxxxxxxx>
> Date: Thu, 18 Jun 2026 23:32:43 +0200
> 
> rt_spin_unlock() releases the RCU protection before unlocking the
> lock. That opens the door for the following UAF scenario:
> 
>  T1					T2
>  spin_lock(&p->lock);		rcu_read_lock();
>  invalidate(p);			p = rcu_dereference(ptr);
>  rcu_assign_pointer(ptr, NULL);	if (!p) return; // Not taken
>  spin_unlock(&p->lock);		spin_lock(&p->lock)
>  				   lock(&lock->lock);
> 				   rcu_read_lock();
>  kfree_rcu(p);			rcu_read_unlock();
> 				....
> 				spin_unlock(&p->lock)
> 				  rcu_read_unlock(); // Ends grace period
>  rcu_do_batch()
>    kfree(p);
> 			 UAF ->	  rt_mutex_cmpxchg_release(&lock->lock...)
> 
> Regular spinlocks keep preemption disabled accross the unlock operation,
> which provides full RCU protection, but the RT substitution fails to
> resemble that.
> 
> Move the rcu_read_unlock() invocation past the unlock operation to match
> the non-RT semantics and add a comment explaining why rcu_read_unlock()
> must come last.
> 
> This makes it asymmetric vs. rt_spin_lock(), but that's harmless as the
> caller needs to hold RCU read lock across the lock operation. The
> migrate_enable() call stays before the unlock operation because there is
> no per CPU operation in the unlock path which would require migration to
> be kept disabled.
> 
> Fixes: 0f383b6dc96e ("locking/spinlock: Provide RT variant")
> Reported-by: syzbot+000c800a02097aaa10ed@xxxxxxxxxxxxxxxxxxxxxxxxx
> Decoded-by: Jann Horn <jannh@xxxxxxxxxx>
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx

IIRC, something very similar being mentioned in dentry UAF threads back in April...
<digs around>
https://lore.kernel.org/all/a0f19c52-47d2-41d9-995a-4bbc6bb73c13@paulmck-laptop/

There it covered rt_read_unlock() and rt_write_unlock() as well; AFAICS both are
in the same situation and at that point there's nothing left held to prevent
the RCU callbacks from running.

Said that, this is _not_ the same thing Jeff had been hitting - config in
question didn't have RT_PREEMPT, so there was something separate  ;-/