CVE-2026-64211 Overview
CVE-2026-64211 affects the Linux kernel's Sleepable Read-Copy-Update (SRCU) subsystem. During the transition of an srcu_struct structure from CPU-0 state to all-CPUs state, the kernel can attempt to invoke callbacks for CPUs that have never been online. In some cases, the kernel targets CPUs that will never come online, including imaginary CPUs absent from cpu_possible_mask. This behavior causes hangs on the s390 architecture, which cannot handle workqueue handlers scheduled on such CPUs. The upstream fix prevents Tree SRCU from queueing workqueue handlers on CPUs that have not yet come online and redirects premature callbacks to the boot CPU.
Critical Impact
The flaw can trigger kernel hangs on s390 systems when SRCU callbacks are queued to never-online CPUs during subsystem state transitions.
Affected Products
- Linux kernel (Tree SRCU subsystem)
- s390 architecture builds are most directly impacted by the hang condition
- Distributions shipping affected kernel versions prior to the referenced stable commits
Discovery Timeline
- 2026-07-24 - CVE-2026-64211 published to NVD
- 2026-07-30 - Last updated in NVD database
Technical Details for CVE-2026-64211
Vulnerability Analysis
The vulnerability resides in the Tree SRCU implementation within the Linux kernel. SRCU allows readers to sleep in read-side critical sections and relies on per-CPU state to track grace periods and pending callbacks. An srcu_struct begins in a CPU-0-only mode and later transitions to an all-CPUs mode as usage patterns require broader tracking.
During this transition window, the callback invocation logic can enumerate CPUs that have not yet been brought online. On architectures such as s390, scheduling workqueue handlers to these CPUs leads to hangs because the workqueue infrastructure cannot service handlers on offline or non-existent CPUs. The condition can also target CPUs outside cpu_possible_mask, which represents an invalid queueing target.
The categorization aligns with a kernel logic and race-condition class defect [Race Condition, Kernel Vulnerability] that manifests as a Denial of Service through resource stall.
Root Cause
The root cause is that Tree SRCU did not gate workqueue queueing on CPU online state during the CPU-0-to-all-CPUs mode switch. The code assumed all enumerated CPUs were valid workqueue targets. Additionally, callers invoking call_srcu(), synchronize_srcu(), or synchronize_srcu_expedited() from a not-yet-fully-online CPU could enqueue callbacks that had no valid CPU on which to execute.
Attack Vector
This is a local reliability defect triggered by kernel code paths that use SRCU during early CPU bring-up or on architectures with sparse CPU topologies. It is not a remote or authenticated attack vector. The impact is a system hang rather than memory corruption or privilege escalation. Exploitation as a deliberate denial-of-service requires local code that invokes SRCU primitives under the specific transition window.
No verified public exploit code is available. See the kernel commit 593889c4 and kernel commit a4153538 for the technical fix.
Detection Methods for CVE-2026-64211
Indicators of Compromise
- Kernel hangs or soft lockups on s390 systems that use SRCU-heavy subsystems during boot or CPU hotplug events
- Workqueue stall warnings referencing CPUs that are not currently online
- srcu or rcu related traces in dmesg during CPU bring-up sequences
Detection Strategies
- Compare running kernel versions against the fixed stable commits referenced by kernel.org to identify unpatched hosts
- Monitor for INFO: task ... blocked messages and workqueue watchdog warnings originating from SRCU call sites
- Track kernel package inventory across s390 fleets to prioritize systems most susceptible to the hang
Monitoring Recommendations
- Ingest kernel logs into a centralized log platform and alert on SRCU-related stall messages
- Track CPU hotplug events on s390 hosts and correlate with subsequent workqueue anomalies
- Establish baselines for boot-time and hotplug-time kernel messages to detect deviations quickly
How to Mitigate CVE-2026-64211
Immediate Actions Required
- Identify all Linux systems, particularly s390 builds, running kernels prior to the fixed stable commits
- Schedule kernel updates to a stable release that includes both referenced fix commits
- Prioritize hosts that perform CPU hotplug or use SRCU-heavy kernel subsystems
Patch Information
Upstream fixes are available in the mainline and stable trees via kernel commit 593889c4 and kernel commit a4153538. The patches make Tree SRCU refrain from queueing workqueue handlers on CPUs that have not yet come online. They also redirect callbacks queued on not-yet-fully-online CPUs to the boot CPU, which avoids the hang without introducing warning noise.
Apply distribution-provided kernel updates that incorporate these commits rather than applying patches manually where vendor kernels are in use.
Workarounds
- Avoid invoking call_srcu(), synchronize_srcu(), or synchronize_srcu_expedited() from code paths that run on not-yet-fully-online CPUs
- On s390, defer SRCU-dependent workloads until all planned CPUs are fully online
- Where feasible, reduce reliance on CPU hotplug operations on affected kernels until patched builds are deployed
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
