CVE-2026-23355

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata: cancel pending work after clearing deferred_qc<br /> <br /> Syzbot reported a WARN_ON() in ata_scsi_deferred_qc_work(), caused by<br /> ap-&gt;ops-&gt;qc_defer() returning non-zero before issuing the deferred qc.<br /> <br /> ata_scsi_schedule_deferred_qc() is called during each command completion.<br /> This function will check if there is a deferred QC, and if<br /> ap-&gt;ops-&gt;qc_defer() returns zero, meaning that it is possible to queue the<br /> deferred qc at this time (without being deferred), then it will queue the<br /> work which will issue the deferred qc.<br /> <br /> Once the work get to run, which can potentially be a very long time after<br /> the work was scheduled, there is a WARN_ON() if ap-&gt;ops-&gt;qc_defer() returns<br /> non-zero.<br /> <br /> While we hold the ap-&gt;lock both when assigning and clearing deferred_qc,<br /> and the work itself holds the ap-&gt;lock, the code currently does not cancel<br /> the work after clearing the deferred qc.<br /> <br /> This means that the following scenario can happen:<br /> 1) One or several NCQ commands are queued.<br /> 2) A non-NCQ command is queued, gets stored in ap-&gt;deferred_qc.<br /> 3) Last NCQ command gets completed, work is queued to issue the deferred<br /> qc.<br /> 4) Timeout or error happens, ap-&gt;deferred_qc is cleared. The queued work is<br /> currently NOT canceled.<br /> 5) Port is reset.<br /> 6) One or several NCQ commands are queued.<br /> 7) A non-NCQ command is queued, gets stored in ap-&gt;deferred_qc.<br /> 8) Work is finally run. Yet at this time, there is still NCQ commands in<br /> flight.<br /> <br /> The work in 8) really belongs to the non-NCQ command in 2), not to the<br /> non-NCQ command in 7). The reason why the work is executed when it is not<br /> supposed to, is because it was never canceled when ap-&gt;deferred_qc was<br /> cleared in 4). Thus, ensure that we always cancel the work after clearing<br /> ap-&gt;deferred_qc.<br /> <br /> Another potential fix would have been to let ata_scsi_deferred_qc_work() do<br /> nothing if ap-&gt;ops-&gt;qc_defer() returns non-zero. However, canceling the<br /> work when clearing ap-&gt;deferred_qc seems slightly more logical, as we hold<br /> the ap-&gt;lock when clearing ap-&gt;deferred_qc, so we know that the work cannot<br /> be holding the lock. (The function could be waiting for the lock, but that<br /> is okay since it will do nothing if ap-&gt;deferred_qc is not set.)