CVE-2026-72069 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides in the Linux kernel's real-time (RT) locking implementation where rt_spin_unlock() function fails to maintain proper RCU (Read-Copy-Update) protection during its execution. This flaw creates a potential use-after-free condition that can be exploited by malicious actors to gain unauthorized access or cause system instability. The issue specifically affects the RT spinlock subsystem which is designed to provide deterministic locking behavior for real-time applications while maintaining compatibility with standard kernel locking mechanisms.
The technical root cause stems from the incorrect ordering of RCU protection calls within rt_spin_unlock() implementation. During normal operation, regular spinlocks maintain preemption disabled across the unlock operation to ensure full RCU protection, but RT spinlocks fail to replicate this behavior. The vulnerability manifests when a thread releases an RT spinlock before properly ending the RCU read-side critical section, creating a window where subsequent RCU grace periods can complete prematurely. This timing issue allows for the classic race condition scenario where memory allocated to a structure can be freed while other threads still hold references to it, leading to potential memory corruption and system crashes.
The operational impact of this vulnerability extends beyond simple memory safety issues to encompass broader system stability concerns. Attackers could exploit this weakness to perform use-after-free attacks that might escalate privileges or cause denial-of-service conditions in real-time kernel environments. The vulnerability affects not just individual spinlock operations but the entire RT locking subsystem, potentially compromising the deterministic behavior that real-time applications depend upon for reliable operation. This weakness particularly impacts systems where real-time scheduling policies are actively used alongside RCU-protected data structures.
The fix implemented addresses the core issue by reordering the RCU protection calls within rt_spin_unlock() to ensure rcu_read_unlock() is invoked after the actual unlock operations rather than before them. This change makes the RT spinlock behavior consistent with standard spinlocks while maintaining the necessary preemption handling for real-time scheduling requirements. The solution specifically moves the rcu_read_unlock() invocation past the unlock operations to match non-RT semantics, though this creates an asymmetric behavior compared to rt_xxx_lock() functions. However, this asymmetry is considered harmless because callers are required to hold RCU read locks across the lock operation anyway, maintaining the necessary synchronization guarantees.
Security implications of this vulnerability align with CWE-416 Use After Free and CWE-362 Concurrent Execution using Shared Resources categories, as the flaw enables improper memory access patterns that can be exploited through timing attacks. The mitigation approach follows established security principles for RCU protection management and aligns with ATT&CK techniques related to privilege escalation and system stability compromise. The fix ensures proper ordering of synchronization primitives while maintaining backward compatibility and real-time scheduling guarantees essential for industrial and embedded systems relying on Linux kernel RT support.
This vulnerability demonstrates the complexity inherent in maintaining correct synchronization semantics across different kernel locking implementations, particularly when real-time requirements conflict with standard safety mechanisms. The resolution emphasizes the importance of careful analysis of timing dependencies in kernel code and proper adherence to established synchronization patterns. The fix also highlights how seemingly minor implementation differences between standard and RT kernel components can create significant security implications that require thorough testing and validation across different system configurations and workload scenarios.
The addressed issue represents a critical gap in kernel-level memory safety mechanisms that could be exploited by sophisticated attackers targeting real-time systems. Proper implementation of RCU semantics in real-time contexts requires careful consideration of both performance requirements and safety guarantees, particularly when dealing with lock-free data structures and concurrent access patterns. The resolution ensures that real-time applications maintain their deterministic behavior while also protecting against common memory safety vulnerabilities that could compromise system integrity.