Cloudanix VulnDB

CVE-2026-68396

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel can stop storage error recovery from starting, leaving disks unresponsive after problems occur.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition between scsi_schedule_eh setting the host error-recovery state and scsi_dec_host_busy decrementing the busy-command count, allowing the error-handler thread to remain asleep even when all commands are inactive.

Why it matters to the business

SCSI storage devices can remain stuck after command timeouts, causing prolonged I/O hangs, application stalls, and unplanned downtime on affected Linux systems.

How an attack unfolds

An attacker or workload triggers repeated SCSI command timeouts or aborts; due to missing memory ordering, scsi_dec_host_busy may observe the inactive state before the error-recovery flag is visible, so scsi_eh_wakeup is never called and the handler thread stays dormant.

How to fix it

Update to a Linux kernel containing the fix that runs scsi_eh_wakeup from an RCU-protected work item; rebuild and reboot affected systems with the corrected kernel.

How to confirm the fix worked

Confirm the kernel source contains the scsi_eh_wakeup work-item change and that scsi_schedule_eh now uses RCU to guarantee ordering with scsi_dec_host_busy; test SCSI error injection to verify the handler wakes reliably.

Typical attack path

  1. Issue or induce SCSI command timeouts on a target host
  2. Race the setting of host error state against busy-count decrements
  3. Prevent scsi_eh_wakeup from executing, leaving commands unrecovered
  4. Observe persistent device unresponsiveness or I/O failures

How to detect it

Review kernel logs for repeated SCSI timeout or abort messages without corresponding error-handler activity; inspect /var/log/messages or dmesg for scsi_eh or scsi_schedule_eh entries that indicate a handler thread that never wakes.

What your security team should do

  • Prioritize kernel updates on systems with heavy SCSI or multipath storage workloads
  • Monitor vendor advisories for the exact patch release containing the RCU work-item fix
  • Apply the update during the next maintenance window or sooner if timeouts are observed

The record

In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.

Affected packages

Ecosystem Package Introduced Fixed