Re: [PATCH V2] locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()

[Al Viro]

On Fri, Jun 19, 2026 at 02:52:08PM +0200, Thomas Gleixner wrote:
> 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;
>  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. Same applies for the rwlock substitution.
> 
> Move the rcu_read_unlock() invocation past the unlock operations to match
> the non-RT semantics. This makes it asymmetric vs. rt_xxx_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

Looks sane.

ACKed-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>

If RT folks see no subtle problems with that, it ought to go into mainline ASAP.