Description
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.
Published: 2026-08-15
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability is in the Linux kernel’s real‑time spinlock implementation. In rt_spin_unlock() the RCU read lock is released too early, creating a race that can lead to a use‑after‑free. An attacker who can trigger the described timing example can cause a kernel object to be freed while still referenced, creating an undefined state that can be abused to execute arbitrary code with kernel privileges.

Affected Systems

Linux kernel versions that have not yet incorporated the commit series that reorders the rcu_read_unlock() call in rt_spin_unlock(). No explicit version range is given, but any kernel containing rt_spin_unlock() before the patch is vulnerable.

Risk and Exploitability

The CVSS score is not provided and the flaw is not listed in CISA KEV, indicating limited known exploitation. However, the flaw is a classic use‑after‑free capable of local privilege escalation. Exploiting it requires orchestrating a race between threads holding the real‑time lock and those holding RCU read locks; while difficult, it could allow an attacker with access to privileged code paths to execute arbitrary code in kernel mode.

Generated by OpenCVE AI on August 15, 2026 at 08:29 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the rt_spin_unlock patch, such as the latest stable release or a release that implements the commit series linked in the advisory.
  • If using a custom kernel, cherry‑pick and apply the commits referenced in the advisory to the local source tree, rebuild, and reboot.
  • Until the kernel can be updated, avoid using real‑time spinlocks in critical code paths or disable the real‑time scheduling features if they are not required, thereby reducing the exposure window.

Generated by OpenCVE AI on August 15, 2026 at 08:29 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 15 Aug 2026 08:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 15 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Description 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.
Title locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-15T05:52:21.752Z

Reserved: 2026-08-09T03:40:39.903Z

Link: CVE-2026-72069

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:21:16.607

Modified: 2026-08-15T06:21:16.607

Link: CVE-2026-72069

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-15T08:30:06Z

Weaknesses