CVE-2026-68396 Can Stall Linux SCSI Recovery After Timeouts

This is an availability and recovery defect, not a conventional code-execution finding. The published record does not assign a CVSS score, CWE, attack vector, or exploitation status. What it does establish is more concrete for storage administrators: a driver using

can request error recovery, all outstanding commands can drain, and the kernel’s dedicated error handler can still fail to wake.

For WindowsForum readers, this is not a Windows security update. The NVD entry identifies the affected product as Linux, with Linux kernel source files under

and the SCSI host interface; it does not list Windows 11, Windows Server, Hyper-V, or a Microsoft advisory. WSL users should not treat the CVE record itself as proof that their Windows host is affected. Linux guests, bare-metal Linux servers, appliances, and storage-heavy virtual machines are where administrators need to check the actual kernel package in service.

The failure happens after the I/O trouble begins​

Linux’s SCSI mid-layer has an error-handling thread for each SCSI host. When a device or transport hits a condition requiring recovery, the driver can invoke

to put that host into recovery and arrange for the handler to run after normal commands have drained.

The vulnerable sequence has two observations occurring across CPUs: one CPU changes the host’s state to error recovery and counts outstanding busy commands, while another completion path drops a command and checks whether the host is already in recovery. Kernel.org’s description says there is no enforced memory ordering tying those observations together.

The bad outcome is precise. One CPU can see no active commands but miss the transition into recovery; the other can see the recovery state but still count a command as active. Neither side then sees the combined condition that should wake the error-handling thread. Once the final command is inactive, there may be no later event to retry that wake-up decision.

That makes CVE-2026-68396 different from an ordinary timeout. The device I/O has already reached the point at which the kernel should be escalating into recovery. The defect is that the recovery coordinator can remain dormant, leaving the host in a state that may present to applications as hung or indefinitely delayed I/O rather than as a cleanly failed request.

The practical symptoms will depend on the low-level driver and the storage topology. On a server, that can mean a filesystem task blocked behind a device reset that never starts, multipath or RAID members taking longer to be declared unusable, or an application waiting on storage that should have been reset or failed over. It is not evidence that every timeout will hang a system; the race requires the narrow timing described in the advisory. But it removes the guarantee that the recovery path will be kicked once the queue drains.

The affected path reaches SATA through libata​

The “SCSI” label can mislead administrators into thinking this is limited to parallel SCSI, Fibre Channel, SAS HBAs, or USB mass-storage devices. Linux represents a broad range of block-storage hardware through the SCSI mid-layer, and the kernel’s libata code directly calls

when scheduling standard ATA error handling.

The Linux source documentation describes

as scheduling host error handling without associating it with a particular SCSI command. The libata implementation uses it from

, its common path for ATA-port error handling. In other words, the vulnerable interface is relevant to systems using SATA drives through libata as well as systems with more obviously “SCSI” storage hardware.

That does not mean every SATA controller or every virtual disk has the same exposure in practice. A particular driver must use the affected scheduling path, and the timing race must occur while recovery is being triggered and commands are becoming inactive. Still, the call chain is enough to reject the narrow reading that this is only a niche external-SCSI problem.

The finding matters most on machines where the storage stack is already being stressed: high queue depths, intermittent transport errors, controller resets, device firmware trouble, paths being removed beneath active I/O, or virtualized storage that can produce bursts of timeouts during an underlying fault. Those are the conditions in which error handling stops being background plumbing and becomes the difference between a workload recovering and a workload remaining stuck.

The fix adds ordering rather than another wake-up check​

Kernel.org’s remedy is not merely to call the wake-up function again. The patch moves

’s wake-up work into a new work item and uses RCU — read-copy-update, the kernel synchronization mechanism — so that the busy-command count occurs only after the recovery state is globally visible and is observable by any completion path already executing

.

That detail is important. Adding a second conditional wake-up without addressing visibility would leave the same two CPUs free to disagree about the relevant state. Deferring the work and synchronizing the observation establishes an ordering boundary: recovery state becomes visible before the later check decides whether the error-handler thread should run.

The kernel’s history shows why this area is sensitive. A 2024 SCSI-core change moved

calculations out of the host lock because repeatedly scanning busy commands while holding that lock could itself cause severe lock contention. The upstream commit cited a real hard-lockup observation on Broadcom’s

driver with 128 hardware queues and a queue depth of 8,169.

That earlier work reduced a scalability hazard by avoiding expensive work under the lock. CVE-2026-68396 addresses a separate correctness requirement: once state and busy-count evaluation are decoupled, the kernel must still make them visible in an order that the concurrent completion path cannot miss. The lesson is not that the 2024 performance fix was mistaken; it is that SCSI recovery has to satisfy both constraints at once — avoid lengthy locked scans and guarantee a final wake-up after the queue drains.

There is one scope detail worth reading carefully. The CVE’s affected-version declaration starts at Linux 5.5 and refers to the commit that introduced the queue-based

design, while the relevant locking and busy-count optimizations evolved later. Administrators should therefore rely on the vendor’s fixed-kernel status rather than attempting to infer safety from the presence or absence of one older performance patch.

Upstream fixed versions are not distro patch status​

According to the kernel.org data carried by NVD, upstream fixed lines are 6.12.101, 6.18.42, 7.1.6, and 7.2-rc4. Those are valuable anchors for self-built kernels and for verifying a kernel tree, but they are not a substitute for distribution advisories.

Enterprise and long-term-support distributions commonly backport security and reliability fixes without changing their base kernel version to the upstream stable number. A host reporting an older-looking release can already contain the patch; conversely, a package based on a nominally newer upstream branch can be missing it if the distributor has not yet incorporated the stable update. The correct test is the distribution’s kernel changelog, security tracker, or source package patch list for CVE-2026-68396 or the corresponding SCSI-core fix.

At publication time, the newly created NVD record includes the four kernel.org stable references but no CVSS assessment, no CWE mapping, and no vendor-specific operating-system advisories. No independent outlet appears to have reported field exploitation or a reproducible workload that triggers the race. That absence should prevent inflated severity claims, but it does not erase the operational issue: the upstream maintainers issued a fix because a SCSI recovery thread can permanently miss its required wake-up.

For administrators, the priority is proportional to dependence on storage recovery. Patch promptly on database servers, virtualization hosts, storage gateways, systems with multipath or RAID, and machines with a record of controller resets or I/O timeouts. On general-purpose Linux desktops and lightly loaded servers, take the normal kernel update once the distribution packages it; this record does not support emergency assumptions about remote compromise.

The concrete checkpoint is simple: verify the running kernel against your vendor’s advisory rather than comparing only

with 6.12.101, 6.18.42, or 7.1.6. The patch’s value is realized only when the kernel actually handling your disks includes the new ordered work-item path — otherwise the next storage fault can still be the one that leaves recovery waiting for an event that has already passed.