CVE-2026-23355
Received Received - Intake
Race Condition in Linux libata Deferred Queue Cancelling Leads to WARN_ON

Publication date: 2026-03-25

Last updated on: 2026-04-24

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: ata: libata: cancel pending work after clearing deferred_qc Syzbot reported a WARN_ON() in ata_scsi_deferred_qc_work(), caused by ap->ops->qc_defer() returning non-zero before issuing the deferred qc. ata_scsi_schedule_deferred_qc() is called during each command completion. This function will check if there is a deferred QC, and if ap->ops->qc_defer() returns zero, meaning that it is possible to queue the deferred qc at this time (without being deferred), then it will queue the work which will issue the deferred qc. Once the work get to run, which can potentially be a very long time after the work was scheduled, there is a WARN_ON() if ap->ops->qc_defer() returns non-zero. While we hold the ap->lock both when assigning and clearing deferred_qc, and the work itself holds the ap->lock, the code currently does not cancel the work after clearing the deferred qc. This means that the following scenario can happen: 1) One or several NCQ commands are queued. 2) A non-NCQ command is queued, gets stored in ap->deferred_qc. 3) Last NCQ command gets completed, work is queued to issue the deferred qc. 4) Timeout or error happens, ap->deferred_qc is cleared. The queued work is currently NOT canceled. 5) Port is reset. 6) One or several NCQ commands are queued. 7) A non-NCQ command is queued, gets stored in ap->deferred_qc. 8) Work is finally run. Yet at this time, there is still NCQ commands in flight. The work in 8) really belongs to the non-NCQ command in 2), not to the non-NCQ command in 7). The reason why the work is executed when it is not supposed to, is because it was never canceled when ap->deferred_qc was cleared in 4). Thus, ensure that we always cancel the work after clearing ap->deferred_qc. Another potential fix would have been to let ata_scsi_deferred_qc_work() do nothing if ap->ops->qc_defer() returns non-zero. However, canceling the work when clearing ap->deferred_qc seems slightly more logical, as we hold the ap->lock when clearing ap->deferred_qc, so we know that the work cannot be holding the lock. (The function could be waiting for the lock, but that is okay since it will do nothing if ap->deferred_qc is not set.)
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-24
Generated
2026-05-07
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23355
EUVD
EUVD-2026-15330
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.19.4 (inc) to 6.19.7 (exc)
linux linux_kernel From 6.18.14 (inc) to 6.18.18 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's ATA subsystem, specifically in how deferred queued commands (deferred_qc) are handled in libata. The issue arises because when deferred_qc is cleared, the pending work associated with it is not canceled. This can lead to a scenario where work related to an old non-NCQ command is executed after the port has been reset and new commands have been queued, causing unexpected behavior.

The problem occurs because the function ata_scsi_deferred_qc_work() may run long after the work was scheduled, and if the deferred_qc was cleared in the meantime without canceling the work, the work will still execute. This can cause warnings and potentially incorrect handling of commands.

The fix involves ensuring that the pending work is always canceled after clearing deferred_qc, preventing the execution of stale work.


How can this vulnerability impact me? :

This vulnerability can lead to unexpected behavior in the handling of ATA commands in the Linux kernel, potentially causing warnings or errors during command processing. While the description does not explicitly mention security impacts such as data corruption or privilege escalation, the improper handling of deferred commands could affect system stability or reliability, especially in environments relying on NCQ (Native Command Queuing).


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart