CVE-2026-68438
Received Received - Intake

Race Condition in Linux Kernel CSD Lock Debugging

Publication date: 2026-08-12

Last updated on: 2026-08-12

Assigner: kernel.org

Description
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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-12
Last Modified
2026-08-12
Generated
2026-08-12
AI Q&A
2026-08-12
EPSS Evaluated
N/A
NVD
CVE-2026-68438
EUVD
EUVD-2026-57046

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel linux_kernel *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves a race condition in the CSD (Call Single Data) lock mechanism when debug mode is enabled. Normally, the CSD lock ensures only one CPU can modify the callback fields at a time, but the change in smp_call_function_single() removed this safety property. Multiple CPUs can now concurrently prepare the same CSD, leading to overwrites and corruption of the callback fields. This can cause the target CPU to get stuck in an infinite loop while processing the corrupted queue.

Detection Guidance

This vulnerability is specific to the Linux kernel's smp_call_function_single() implementation and requires kernel debugging features to detect. Enable CSD lock debugging via kernel command line parameter 'lock_debug=1' or 'csd_lock_debug=1' and check kernel logs for soft-lockup warnings or panics during high parallel CPU operations.

Impact Analysis

If exploited, this vulnerability could cause a system hang or crash due to a soft-lockup or kernel panic. It may disrupt critical operations like TLB shootdowns, leading to performance degradation or complete system failure. Users might experience unresponsive systems or unexpected reboots.

Mitigation Strategies

Apply the kernel patch that introduces try_cmpxchg_acquire() for CSD lock acquisition when debugging is enabled. Alternatively, disable CSD lock debugging if not required by removing 'lock_debug=1' or 'csd_lock_debug=1' from kernel command line parameters.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-68438. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart