CVE-2026-23355

published 2026-03-25

CVE-2026-23355: 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…

Priority P4 23 medium 5.5 CVSS 3.1

AV L AC L PR L UI N S U C N I N A H

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 lo

Affected

15 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.19.8-1 (forky)	linux 6.19.8-1 (forky)
linux	linux	—	—
linux	linux	—	—
linux	linux	>= 0ea84089dbf62a92dc7889c79e6b18fc89260808 < aac9b27f7c1f2b2cf7f50a9ca633ecbbcaf22af9	aac9b27f7c1f2b2cf7f50a9ca633ecbbcaf22af9
linux	linux	>= 5d61a38a60e62750526d94663b69b7ac5c7f07a5 < 58e658763ba2aa9168d8516b98a6314d7461a53e	58e658763ba2aa9168d8516b98a6314d7461a53e
linux	linux	>= 6.18.14 < 6.18.18	6.18.18
linux	linux	>= 6.19.4 < 6.19.7	6.19.7
linux	linux	>= 888cd7e40adb2ef4af1b4d3b6e2e83ad409ae8c2 < 6c5e8f16b5e8e614e829aaf38619bdd79107bb0a	6c5e8f16b5e8e614e829aaf38619bdd79107bb0a
linux	linux	>= ce22aaed011206fed9cbd8c9c2d44718607f31ee < 0d12453818c35e1ded84633152c6b05002ae48b9	0d12453818c35e1ded84633152c6b05002ae48b9
linux	linux_kernel	—	—
linux	linux_kernel	>= 0 < 6.19.8-1	6.19.8-1
linux	linux_kernel	>= 0 < 6.18.18	6.18.18
linux	linux_kernel	>= 6.18.14 < 6.18.18	6.18.18
linux	linux_kernel	>= 6.19.0 < 6.19.7	6.19.7
linux	linux_kernel	>= 6.19.4 < 6.19.7	6.19.7

CVSS provenance

nvd v3.1 5.5 MEDIUM CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

vendor_redhat 5.5 MEDIUM

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.

CWE-459