CVE-2026-68438 in Linux
Summary
by MITRE • 08/12/2026
In the Linux kernel, the following vulnerability has been resolved:
smp: Make CSD lock acquisition atomic for debug mode
Commit b0473dcd4b1d ("smp: Improve smp_call_function_single() CSD-lock diagnostics") changed smp_call_function_single() so that, when CSD lock debugging is enabled, async !wait calls use the destination CPU csd_data. That improves diagnostics, but it also removes the single-writer property that made the old csd_lock() safe: multiple CPUs can now prepare the same destination CPU CSD concurrently.
csd_lock() currently waits for CSD_FLAG_LOCK to clear and then sets the bit with a non-atomic read-modify-write. Two senders can both see an unlocked CSD, set the bit, overwrite the callback fields, and enqueue the same llist node. Re-adding a node that is already the queue head can make node->next point to itself, leaving the target CPU stuck walking call_single_queue. Later synchronous work, such as a TLB shootdown, can then remain queued and trigger soft-lockup warnings or panics.
Keep the single csd_lock() implementation, but when CSD lock debugging is enabled, acquire CSD_FLAG_LOCK with try_cmpxchg_acquire(). This makes the destination CPU CSD a real atomic lock in the only configuration where it can be shared by multiple remote senders, while preserving the existing non-debug fast path.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability described represents a critical race condition in the Linux kernel's symmetric multiprocessing implementation that affects the smp_call_function_single() function. This issue emerges from changes made to improve diagnostic capabilities for CSD (call single data) lock operations, specifically when debug mode is enabled. The fundamental problem occurs because the original implementation relied on a single-writer property that ensured exclusive access to the CSD structure during lock acquisition. When debugging features were introduced, this guarantee was compromised as multiple CPUs could concurrently prepare the same destination CPU's CSD data, creating a scenario where competing writers could corrupt shared data structures.
The technical flaw manifests in the csd_lock() function which previously waited for the CSD_FLAG_LOCK to clear and then set the bit using a non-atomic read-modify-write operation. This approach worked correctly under normal conditions because only one CPU could prepare a given destination CPU's CSD at a time. However, with the introduction of debug mode functionality, multiple CPUs could simultaneously attempt to acquire the lock on the same destination CPU's CSD structure. When two or more senders both observed an unlocked CSD, set the lock bit concurrently, and then proceeded to overwrite callback fields, they created a scenario where the same llist node could be enqueued multiple times.
The operational impact of this vulnerability is severe and can lead to system instability including infinite loops in the call_single_queue traversal, which causes target CPUs to become stuck processing their work queues. When a node's next pointer points to itself due to re-enqueuing operations, the queue walking logic enters an endless loop that prevents proper execution of queued work items. This condition becomes particularly problematic when synchronous operations such as TLB shootdowns are queued, as these operations can remain indefinitely pending and trigger soft-lockup warnings or system panics. The vulnerability directly violates the atomicity guarantees required for concurrent access to shared kernel data structures.
The proposed mitigation strategy maintains the existing single csd_lock() implementation while introducing atomic lock acquisition specifically when CSD lock debugging is enabled. By using try_cmpxchg_acquire() for lock acquisition in debug mode, the implementation transforms the destination CPU CSD into a real atomic lock under conditions where multiple remote senders can access it simultaneously. This approach preserves the existing high-performance fast path for non-debug configurations while providing proper atomicity guarantees only where needed. The solution aligns with established security principles and follows best practices for concurrent programming in kernel space, ensuring that shared resources remain properly protected against race conditions.
This vulnerability is categorized as a concurrency issue affecting kernel-level memory management and synchronization primitives, relating to CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and CWE-367 (Time-of-Check Time-of-Use). The attack surface involves malicious or faulty concurrent access patterns that can cause system hangs or crashes through improper lock handling. From an ATT&CK perspective, this vulnerability could be leveraged in privilege escalation scenarios where attackers attempt to exploit kernel-level race conditions to gain unauthorized access or cause denial of service conditions. The fix ensures proper memory ordering semantics and atomic operations during lock acquisition, preventing the specific race condition that allowed multiple writers to corrupt shared data structures.