CVE-2026-68396: Linux Kernel Race Condition Vulnerability

CVE-2026-68396 Overview

CVE-2026-68396 is a race condition in the Linux kernel SCSI subsystem. The flaw affects drivers that invoke scsi_schedule_eh to trigger the error handler. When all outstanding commands time out or become inactive, the error handler thread may never wake up. The root cause is missing memory ordering between setting the host into error recovery state and counting busy commands. Without an enforced ordering guarantee, a race with scsi_dec_host_busy can leave the storage stack stalled. The Linux kernel maintainers resolved the issue by moving the wakeup into a dedicated work item that uses read-copy-update (RCU) semantics.

Critical Impact
SCSI error recovery can stall indefinitely, blocking storage I/O when a driver relies on scsi_schedule_eh to invoke the error handler.

Affected Products

Linux kernel SCSI core subsystem
Drivers that call scsi_schedule_eh to run the error handler
Systems using SCSI storage stacks that depend on the mid-layer error recovery path

Discovery Timeline

2026-08-10 - CVE-2026-68396 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-68396

Vulnerability Analysis

The vulnerability is a race condition [CWE-362] in the SCSI mid-layer error handling logic. Drivers use scsi_schedule_eh to request that the SCSI error handler (EH) thread run. The EH thread must be woken when the host enters error recovery state and no commands remain outstanding. In the vulnerable code path, there is no memory barrier between the write that places the host into error recovery state and the read that counts busy commands via scsi_host_busy. A concurrent scsi_dec_host_busy caller can observe the busy count decrement without observing the error state, while the scsi_schedule_eh caller can observe an already-decremented busy count without seeing its own error-state write become globally visible. Neither path then issues the wakeup. The EH thread remains asleep and error recovery never proceeds, stalling storage I/O on the affected host.

Root Cause

The root cause is missing memory ordering between two independent state updates that must be checked together. Setting the host into error recovery state and decrementing the busy command counter can be reordered relative to each other from the perspective of concurrent CPUs. Both scsi_schedule_eh and scsi_dec_host_busy can each miss the combined condition that requires waking the error handler.

Attack Vector

No remote attack vector is documented. The condition is a functional defect that manifests under concurrent SCSI activity when the error handler is scheduled while commands complete or time out. Impact is limited to denial of service through stalled storage I/O on affected hosts. See the upstream fix commits 24d7abda, 866efe8a, c7a15091, and dccf3b17 for the technical resolution.

No verified exploitation code is available for this vulnerability.
The race condition is described in prose based on upstream commit messages.

Detection Methods for CVE-2026-68396

Indicators of Compromise

Kernel logs showing SCSI commands timing out without corresponding error handler activation messages
Storage I/O hangs where outstanding requests never complete and no scsi_eh thread activity is recorded
Systems reporting stuck SCSI hosts with a busy command count of zero and no progress in error recovery

Detection Strategies

Monitor kernel ring buffer output through dmesg for repeated SCSI command timeout entries without matching error handler wakeup messages
Correlate storage subsystem stalls with kernel versions that lack the upstream fix commits referenced in the CVE
Track process state for the per-host scsi_eh_* kernel threads; a persistently sleeping thread combined with pending timeouts indicates the race

Monitoring Recommendations

Ingest kernel logs and SCSI subsystem telemetry into a centralized logging platform for cross-host correlation
Alert on storage latency anomalies and I/O queue depth increases that persist beyond normal timeout windows
Track kernel package versions across the fleet to identify hosts running vulnerable SCSI mid-layer code

How to Mitigate CVE-2026-68396

Immediate Actions Required

Identify Linux systems running kernel versions that do not include the upstream fix commits and prioritize them for patching
Apply the vendor kernel update that incorporates the RCU-based wakeup work item once available for your distribution
Reboot affected hosts after installing the patched kernel to activate the corrected SCSI error handling path

Patch Information

The fix moves the scsi_eh_wakeup invocation into a new work item that uses RCU to ensure the scsi_host_busy check in scsi_schedule_eh occurs after the error state is globally visible. This ordering guarantee ensures any concurrent scsi_dec_host_busy caller will see the error state and issue the wakeup. Refer to the mainline commits 24d7abda, 866efe8a, c7a15091, and dccf3b17 for backport details.

Workarounds

No documented software workaround exists; the defect is in the SCSI mid-layer wakeup logic and requires the kernel patch
Where patching is delayed, monitor storage subsystems for stalls and prepare to reset affected hosts to restore I/O service
Test kernel updates in staging environments to confirm SCSI stack behavior under concurrent I/O and error injection

bash

# Check the currently running kernel version
uname -r

# Inspect kernel logs for SCSI error handler activity
dmesg | grep -iE 'scsi|scsi_eh'

# Update the kernel through the distribution package manager
# Debian/Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade linux-image-$(uname -r)

# RHEL/CentOS/Fedora
sudo dnf update kernel

# Reboot to activate the patched kernel
sudo systemctl reboot