CVE-2026-68438: Linux Kernel Race Condition Vulnerability

CVE-2026-68438 Overview

CVE-2026-68438 is a race condition in the Linux kernel's symmetric multiprocessing (SMP) subsystem. The flaw affects the smp_call_function_single() code path when CSD (Call Single Data) lock debugging is enabled. Multiple CPUs can concurrently prepare the same destination CPU's CSD structure, because the existing csd_lock() implementation uses a non-atomic read-modify-write to set CSD_FLAG_LOCK. Concurrent senders can enqueue the same llist node, producing a self-referential node->next pointer. The target CPU then loops indefinitely while walking call_single_queue, blocking subsequent synchronous work such as TLB shootdowns.

Critical Impact
The race can leave a CPU stuck traversing call_single_queue, causing soft-lockup warnings, stalled TLB shootdowns, and potential kernel panics on affected systems.

Affected Products

Linux kernel builds that include commit b0473dcd4b1d ("smp: Improve smp_call_function_single() CSD-lock diagnostics")
Kernel configurations with CSD lock debugging enabled (CONFIG_CSD_LOCK_WAIT_DEBUG)
Downstream distributions carrying the affected SMP code path

Discovery Timeline

2026-08-12 - CVE-2026-68438 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-68438

Vulnerability Analysis

The Linux kernel uses smp_call_function_single() to run a callback on a specific remote CPU. Each request is described by a call_single_data_t (CSD) that holds the callback pointer, argument, and a flag word. A prior improvement, commit b0473dcd4b1d, changed the async no-wait path so that CSD lock debugging routes requests through the destination CPU's csd_data rather than caller-owned storage. That change improved diagnostics but broke the previous single-writer invariant that made csd_lock() safe.

With debugging enabled, multiple sender CPUs can now target the same per-CPU CSD simultaneously. csd_lock() waits for CSD_FLAG_LOCK to clear, then sets the bit using a non-atomic operation. Two senders can each observe the unlocked state, both set the flag, both overwrite the callback fields, and both attempt to enqueue the same llist node onto call_single_queue.

Root Cause

The root cause is an atomicity violation [CWE-Race Condition]. The lock acquisition performs a check followed by a separate write, without atomic compare-and-swap semantics. When the same destination CSD is shared by multiple remote senders, the non-atomic acquisition permits duplicate insertion of an llist node. Re-adding a node that is already the queue head causes node->next to reference itself, creating a cycle in the singly linked list.

Attack Vector

The defect is a reliability and denial-of-service condition triggered by concurrent kernel workloads that generate cross-CPU calls under a debug kernel. It is not a remote network attack vector. Exploitation requires the ability to induce concurrent smp_call_function_single() traffic targeting the same CPU on a kernel built with CSD lock debugging enabled. Successful triggering results in a hung CPU, stalled TLB shootdowns, soft-lockup warnings, or a panic.

The upstream fix retains the single csd_lock() implementation but acquires CSD_FLAG_LOCK with try_cmpxchg_acquire() when CSD lock debugging is enabled. This restores atomic ownership in the only configuration where the CSD can be shared by multiple senders while preserving the non-debug fast path. See the kernel commit 282d220bae5f and kernel commit 35551efb155e for the patch details.

Detection Methods for CVE-2026-68438

Indicators of Compromise

Kernel soft-lockup messages referencing smp_call_function_single, flush_smp_call_function_queue, or csd_lock_wait in dmesg and /var/log/messages.
CSD-lock diagnostic warnings identifying a stuck destination CPU with pending callbacks.
Stalled TLB shootdown warnings correlated with hung tasks on a single CPU.

Detection Strategies

Audit kernel build configuration for CONFIG_CSD_LOCK_WAIT_DEBUG=y on production hosts.
Correlate soft-lockup and hung-task events with concurrent workloads that heavily use smp_call_function_single() such as TLB flushes, perf events, and IPI-driven RCU work.
Compare running kernel versions against the fixed commits listed in the vendor advisory to identify unpatched systems.

Monitoring Recommendations

Ship dmesg, journald, and /var/log/messages to a centralized log platform and alert on soft lockup, csd:, and rcu_sched detected stalls patterns.
Track host uptime and unexpected reboots that follow kernel panic conditions.
Monitor node_exporter or equivalent metrics for sustained per-CPU stalls that align with CSD-lock timeouts.

How to Mitigate CVE-2026-68438

Immediate Actions Required

Inventory Linux hosts and identify kernels containing commit b0473dcd4b1d without the fix commits 282d220bae5f or 35551efb155e.
Apply the stable kernel update from your distribution vendor once available.
On unpatched debug kernels, disable CONFIG_CSD_LOCK_WAIT_DEBUG in the build configuration to eliminate the shared-CSD code path.

Patch Information

The upstream fix converts CSD lock acquisition to try_cmpxchg_acquire() when CSD-lock debugging is compiled in, restoring atomic ownership of CSD_FLAG_LOCK. Reference the mainline commits at git.kernel.org 282d220bae5f and git.kernel.org 35551efb155e. Apply the corresponding stable-tree backport for your kernel line.

Workarounds

Rebuild the kernel without CONFIG_CSD_LOCK_WAIT_DEBUG to bypass the affected shared-CSD path.
Restrict use of debug-enabled kernels to non-production environments until the patch is deployed.
Where feasible, reduce workloads that generate concurrent cross-CPU calls on the same target CPU while awaiting patch rollout.

bash

# Verify whether the running kernel enables CSD lock debugging
zgrep CONFIG_CSD_LOCK_WAIT_DEBUG /proc/config.gz 2>/dev/null || \
  grep CONFIG_CSD_LOCK_WAIT_DEBUG /boot/config-$(uname -r)

# Search kernel logs for CSD-lock and soft-lockup indicators
dmesg -T | grep -E 'csd:|soft lockup|smp_call_function'
journalctl -k --since "7 days ago" | grep -E 'csd:|soft lockup'