CVE-2026-23355 in Linux Kernel

Resumen

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ata: libata: cancelar trabajo pendiente después de limpiar deferred_qc Syzbot informó un WARN_ON() en ata_scsi_deferred_qc_work(), causado por ap->ops->qc_defer() que devolvía un valor distinto de cero antes de emitir el qc diferido. ata_scsi_schedule_deferred_qc() es llamada durante cada finalización de comando. Esta función verificará si hay un QC diferido, y si ap->ops->qc_defer() devuelve cero, lo que significa que es posible encolar el qc diferido en este momento (sin ser diferido), entonces encolará el trabajo que emitirá el qc diferido. Una vez que el trabajo se ejecuta, lo que potencialmente puede ser mucho tiempo después de que el trabajo fue programado, hay un WARN_ON() si ap->ops->qc_defer() devuelve un valor distinto de cero. Mientras mantenemos el ap->lock tanto al asignar como al limpiar deferred_qc, y el trabajo en sí mantiene el ap->lock, el código actualmente no cancela el trabajo después de limpiar el qc diferido. Esto significa que el siguiente escenario puede ocurrir: 1) Uno o varios comandos NCQ son encolados. 2) Un comando no-NCQ es encolado, se almacena en ap->deferred_qc. 3) El último comando NCQ se completa, el trabajo es encolado para emitir el qc diferido. 4) Ocurre un tiempo de espera o un error, ap->deferred_qc es limpiado. El trabajo encolado NO es cancelado actualmente. 5) El puerto es reiniciado. 6) Uno o varios comandos NCQ son encolados. 7) Un comando no-NCQ es encolado, se almacena en ap->deferred_qc. 8) El trabajo finalmente se ejecuta. Sin embargo, en este momento, todavía hay comandos NCQ en curso. El trabajo en 8) realmente pertenece al comando no-NCQ en 2), no al comando no-NCQ en 7). La razón por la cual el trabajo se ejecuta cuando no se supone que debe hacerlo, es porque nunca fue cancelado cuando ap->deferred_qc fue limpiado en 4). Por lo tanto, asegúrese de que siempre cancelemos el trabajo después de limpiar ap->deferred_qc. Otra solución potencial habría sido dejar que ata_scsi_deferred_qc_work() no hiciera nada si ap->ops->qc_defer() devuelve un valor distinto de cero. Sin embargo, cancelar el trabajo al limpiar ap->deferred_qc parece ligeramente más lógico, ya que mantenemos el ap->lock al limpiar ap->deferred_qc, por lo que sabemos que el trabajo no puede estar manteniendo el bloqueo. (La función podría estar esperando el bloqueo, pero eso está bien ya que no hará nada si ap->deferred_qc no está configurado.)

Responsable

Linux

Reservar

2026-01-13

Divulgación

2026-03-25

Voces

VulDB provides additional information and datapoints for this CVE:

ID	Vulnerabilidad	CWE	Exp	Con	CVE
353086	Linux Kernel libata escalada de privilegios		No está definido	Arreglo oficial	CVE-2026-23355