CVE-2026-23355 in Linux
Riassunto
di VulDB • 14/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ata: libata: annullare il lavoro in sospeso dopo aver cancellato deferred_qc
Syzbot ha segnalato un WARN_ON() in ata_scsi_deferred_qc_work(), causato dal fatto che ap->ops->qc_defer() restituisce un valore diverso da zero prima dell'emissione del qc differito.
ata_scsi_schedule_deferred_qc() viene chiamata al termine di ogni comando. Questa funzione verifica se esiste un QC (Queued Command) differito e, se ap->ops->qc_defer() restituisce zero, indicando che è possibile accodare il qc differito in quel momento (senza ulteriore ritardo), allora programma l'esecuzione del lavoro che emetterà il qc differito.
Una volta che il lavoro inizia a essere eseguito, cosa che può avvenire molto tempo dopo la sua programmazione, viene generato un WARN_ON() se ap->ops->qc_defer() restituisce un valore diverso da zero.
Sebbene si detenga l'ap->lock sia durante l'assegnazione e la cancellazione di deferred_qc, sia all'interno del lavoro stesso, il codice attualmente non annulla il lavoro dopo aver cancellato il deferred qc.
Ciò significa che può verificarsi lo scenario seguente: 1) Vengono accodati uno o più comandi NCQ (Native Command Queuing). 2) Viene accodato un comando non-NCQ, che viene memorizzato in ap->deferred_qc. 3) L'ultimo comando NCQ viene completato e si programma il lavoro per emettere il qc differito. 4) Si verifica un timeout o un errore e ap->deferred_qc viene cancellato. Il lavoro accodato non viene attualmente annullato. 5) La porta viene resettata. 6) Vengono accodati uno o più comandi NCQ. 7) Viene accodato un comando non-NCQ, che viene memorizzato in ap->deferred_qc. 8) Il lavoro viene finalmente eseguito. Tuttavia, a questo punto ci sono ancora comandi NCQ in transito (in flight).
Il lavoro descritto al punto 8) appartiene realmente al comando non-NCQ del punto 2), e non a quello del punto 7). La ragione per cui il lavoro viene eseguito quando non dovrebbe esserlo è che non è mai stato annullato quando ap->deferred_qc è stato cancellato nel passaggio 4). Pertanto, ci si assicura di annullare sempre il lavoro dopo aver cancellato ap->deferred_qc.
Un'altra possibile correzione sarebbe stata far sì che ata_scsi_deferred_qc_work() non facesse nulla se ap->ops->qc_defer() restituisce un valore diverso da zero. Tuttavia, l'annullamento del lavoro durante la cancellazione di ap->deferred_qc sembra leggermente più logico, poiché si detiene l'ap->lock quando si cancella ap->deferred_qc; ciò significa che sappiamo che il lavoro non può detenere tale lock. (La funzione potrebbe essere in attesa del lock, ma questo è accettabile poiché la funzione non farà nulla se ap->deferred_qc non è impostato.)
If you want to get best quality of vulnerability data, you may have to visit VulDB.