CVE-2026-23071: Linux Kernel Race Condition Vulnerability

CVE-2026-23071 Overview

CVE-2026-23071 is a race condition vulnerability in the Linux kernel's regmap subsystem, specifically in the hardware spinlock (hwspinlock) IRQ save routine. The flaw stems from passing the address of a shared structure member, &map->spinlock_flags, directly to hwspin_lock_timeout_irqsave. Multiple contexts contending for the same lock can overwrite the shared flags variable, corrupting the saved IRQ state for the current lock owner. The vulnerability is tracked under [CWE-362] (Concurrent Execution using Shared Resource with Improper Synchronization). Exploitation requires local access and high attack complexity, and the impact is limited to availability (kernel instability or denial of service).

Critical Impact
A local attacker triggering concurrent regmap operations on shared hwspinlock-protected resources can corrupt saved IRQ state, leading to kernel deadlock or system hang.

Affected Products

Linux Kernel (multiple stable branches prior to the fix commits)
Linux Kernel 6.19-rc1 through 6.19-rc6
Platforms using regmap with hardware spinlocks (commonly Qualcomm and other SoC drivers)

Discovery Timeline

2026-02-04 - CVE-2026-23071 published to NVD
2026-03-18 - Last updated in NVD database

Technical Details for CVE-2026-23071

Vulnerability Analysis

The Linux kernel regmap framework provides a hardware-abstraction layer for register access across diverse buses such as I2C, SPI, and MMIO. When a register map is shared between processor cores or contexts, drivers can configure regmap to use a hardware spinlock to serialize access. The save/restore of CPU interrupt state during this locking sequence is the locus of the defect.

In the vulnerable code, the kernel passed the address of the shared map->spinlock_flags field directly to hwspin_lock_timeout_irqsave. Because the regmap structure is shared across all contexts using that map, two or more callers attempting to acquire the hardware spinlock simultaneously could clobber each other's saved IRQ flags. When the lock owner later released the lock and attempted to restore interrupt state, the restored value reflected another context's flags. The result is incorrect interrupt enable/disable state on return, which can manifest as kernel deadlock, missed interrupts, or system hang.

Root Cause

The root cause is improper synchronization of a per-CPU resource (saved IRQ flags) treated as shared state. IRQ flags must be saved on stack-local storage because they describe the calling context, not the lock. Storing them in the shared regmap structure violates this invariant and creates the race window.

Attack Vector

Exploitation requires local code execution with privileges sufficient to drive regmap-backed device interfaces concurrently. An attacker with low privileges who can issue parallel ioctls or sysfs operations against a device whose driver uses a shared regmap with hwspinlock can trigger the race. Successful exploitation does not yield code execution or information disclosure but can render the system unresponsive. The fix replaces the shared field with a local stack variable flags, ensuring each caller saves and restores its own IRQ state.

No verified public exploit code is available. See the upstream commits referenced under Patch Information for the technical diff.

Detection Methods for CVE-2026-23071

Indicators of Compromise

Kernel soft-lockup or hard-lockup warnings referencing regmap_lock_hwlock or hwspin_lock_timeout_irqsave in dmesg.
Unexpected system hangs on platforms that share a regmap across multiple cores or remote processors.
Repeated WARN_ON traces from the hwspinlock or regmap subsystems following heavy concurrent device I/O.

Detection Strategies

Compare the running kernel version against the fixed stable branches identified by the upstream commits listed in the patch section.
Audit out-of-tree drivers for direct use of hwspin_lock_timeout_irqsave with a non-stack flags variable.
Use kernel lockdep and KCSAN builds in test environments to surface the race during regression testing.

Monitoring Recommendations

Forward dmesg, kern.log, and lockdep output to a centralized log platform and alert on hwspinlock or regmap stack traces.
Track host availability and kernel panic counters across fleets running affected kernel versions.
Correlate device driver crash signatures with kernel build identifiers to identify unpatched hosts.

How to Mitigate CVE-2026-23071

Immediate Actions Required

Inventory Linux hosts and embedded devices running affected kernel versions, prioritizing systems on SoCs that use regmap with hardware spinlocks.
Apply vendor or distribution kernel updates that incorporate the upstream fix as soon as they are available.
Restrict local access to multi-user systems where patching is delayed, since the vulnerability requires local privileges to trigger.

Patch Information

The fix replaces the shared &map->spinlock_flags argument with a local stack variable flags passed to hwspin_lock_timeout_irqsave. The change has been backported to multiple stable branches. Reference commits:

Workarounds

Where patching is not immediately feasible, limit untrusted local users on affected systems to reduce concurrent access to regmap-backed devices.
For embedded fleets, disable or unbind drivers that share a regmap across cores until updated firmware is deployed.
Run validation kernels with lockdep and KCSAN enabled in staging environments to detect residual misuse of shared flag storage.

bash

# Verify running kernel version and compare against patched stable releases
uname -r
# Inspect dmesg for hwspinlock or regmap lockup traces
dmesg | grep -E 'hwspin|regmap|soft lockup|hard LOCKUP'