CVE-2026-45855

What it actually does

This is a local denial-of-service flaw in the Linux kernel libata SCSI translation path. Under sustained Native Command Queuing traffic on ATA/SATA storage devices, a non-NCQ command can be repeatedly deferred when multiple submission queues continue issuing NCQ commands ahead of it. Because the block and SCSI layers do not distinguish queueable from non-queueable ATA commands, the affected kernel behavior can starve non-NCQ commands indefinitely or for very long periods. The practical impact is storage command starvation, I/O stalls, device timeouts, degraded disk responsiveness, and potential system-level availability loss on affected Linux systems using impacted ATA/libata paths.

Why it matters to the business

An attacker or untrusted local workload with the ability to generate specific disk I/O patterns could degrade or stall storage operations on affected Linux systems, potentially causing application hangs, service outages, failed jobs, delayed maintenance operations, or node instability. The issue is not known to be remotely exploitable, is not listed in CISA KEV, has no known exploit maturity, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, systems running multi-tenant workloads, local shell access, containerized workloads with meaningful disk access, or storage-intensive services may face higher operational risk.

How an attack unfolds

An attacker first needs local execution capability or control over a workload that can issue sustained storage I/O to an affected Linux system. The attacker generates continuous NCQ-capable disk traffic against an ATA/SATA device, keeping multiple submission queues busy. While that load is active, the attacker causes non-NCQ commands to be submitted. In vulnerable kernels, the non-NCQ command is repeatedly requeued because NCQ and non-NCQ commands cannot be mixed, while other queues continue to submit NCQ commands first. This can prevent forward progress for the non-NCQ command, causing long I/O delays, command starvation, device timeouts, and service disruption. Successful exploitation affects availability only; it does not directly provide code execution, privilege escalation, data theft, or data modification.

How to fix it

Update the Linux kernel to a version that includes the libata-scsi fix for non-NCQ command forward progress. Because no exact fixed package versions were provided, use the relevant distribution vendor advisory and install the first kernel build that backports the upstream fix for ata/libata-scsi non-NCQ command starvation. Reboot into the updated kernel after installation and remove or retire vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce exposure by restricting local shell access, limiting untrusted workloads with heavy raw disk I/O, applying container and cgroup I/O controls, avoiding unnecessary access to block devices from containers or users, and monitoring for abnormal ATA/SCSI timeout and disk latency events. Temporary tuning that disables NCQ may reduce exploitability in some environments but can significantly reduce performance and should be validated carefully before production use.

How to confirm the fix worked

Confirm the running kernel version is updated to a vendor build containing the libata-scsi non-NCQ starvation fix, not merely that an updated package is installed. Validate with uname -a, package manager kernel inventory, and the applicable distribution changelog or advisory. Review boot logs to confirm the system booted into the fixed kernel. On representative systems, perform controlled storage stress testing with NCQ-enabled workloads and verify that non-NCQ commands complete without excessive delay, repeated ATA timeouts, or device reset behavior. Confirm there are no recurring kernel logs indicating ATA command timeouts, frozen ports, SCSI requeues, or block I/O stalls under normal production load.

Typical attack path

1. Obtain local access or control over a workload capable of generating disk I/O on an affected Linux system.
2. Identify or target storage backed by the Linux ATA/libata SCSI translation layer with NCQ enabled.
3. Generate sustained NCQ-heavy disk activity, preferably from multiple threads or CPUs, to keep the device queue occupied.
4. Trigger or wait for non-NCQ commands to be issued while NCQ commands remain in flight.
5. Cause repeated deferral of non-NCQ commands, resulting in starvation, excessive latency, I/O timeout behavior, or service instability.
6. Maintain the I/O pattern to prolong the denial-of-service condition.

How to detect it

To determine whether this issue may have been exploited, review host-level telemetry for periods of abnormal disk latency or hangs correlated with local users, containers, or jobs generating sustained disk I/O. Useful sources include kernel logs, system journals, dmesg output, audit logs for local process execution, container runtime logs, EDR process telemetry, cgroup I/O metrics, block device latency metrics, and storage monitoring. Look for ATA/SCSI timeout messages, frozen or reset ATA links, failed or delayed block requests, services stuck in uninterruptible I/O wait, and bursts of disk-stress or custom I/O tooling. Because this vulnerability is a starvation/availability issue and does not create a unique network signature or persistent artifact, detection should focus on correlation: affected kernel version, NCQ-capable ATA storage, high concurrent I/O, non-NCQ command timeout symptoms, and local processes responsible for sustained disk activity. Absence of unique indicators means logs may show symptoms similar to hardware degradation or storage overload, so compare against SMART data, device health, and normal workload baselines.

• ata.*hard resetting link
• ata.*soft resetting link
• ata.*exception Emask
• ata.*failed command
• ata.*cmd timeout
• ata.*COMRESET failed
• ata.*SATA link up
• ata.*frozen
• ata.*qc timeout
• blk_update_request: I/O error
• Buffer I/O error on dev
• end_request: I/O error
• I/O error, dev sd
• task .* blocked for more than .* seconds
• INFO: task .* blocked for more than
• D state
• iowait
• fio
• stress-ng --hdd
• stress-ng --iomix
• dd if=

What your security team should do

• Prioritize patching affected Linux systems that allow local users, run untrusted workloads, host containers with disk-intensive activity, or support business-critical storage-dependent applications.
• Track vendor kernel advisories and deploy the first available distribution kernel containing the libata-scsi forward-progress fix; reboot systems to activate the patched kernel.
• Restrict direct block-device access and unnecessary raw disk capabilities from containers, batch jobs, and non-administrative users.
• Apply I/O throttling or workload isolation for untrusted or noisy tenants using cgroups, container runtime controls, or scheduler policy.
• Monitor kernel, system, and storage telemetry for ATA/SCSI timeouts, device resets, high disk latency, stuck I/O, and repeated service hangs.
• Treat unexplained storage stalls on affected kernels as potential exploitation or abuse until logs and workload history show a benign cause.
• Where patching is delayed, consider temporary operational mitigations such as limiting NCQ-heavy untrusted workloads or disabling NCQ only after performance and reliability testing.