CVE-2026-89857 in Linux
Zusammenfassung
von VulDB • 16.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
scsi: qla2xxx: qpair-Sperre beim Senden von NVMe LS-Abweisungen halten
qla_nvme_ls_reject_iocb() alloziert aus dem und erhöht den Request-Ring über __qla2x00_alloc_iocbs() (was voraussetzt, dass hardware_lock gehalten wird) sowie qla2x00_start_iocbs() (der den Ring erhöht und die request-in-Türklingel betätigt), nimmt jedoch selbst keine Sperre. Zwei seiner Aufrufer rufen es ohne gehaltene Producer-Sperre auf:
- qla_nvme_xmt_ls_rsp(), der NVMe-FC .xmt_ls_rsp-Transport-Callback, im Fehlerpfad und - qla2xxx_process_purls_pkt(), ausgeführt aus dem purex-Arbeits-/DPC-Kontext.
Beide verwenden ha->base_qpair, dessen qp_lock_ptr hardware_lock ist; sie können daher parallel zur normalen I/O-Einreichung auf dem Basisring laufen und den Producer-Zustands des Rings beschädigen, was zu duplizierten oder verworfenen Befehlen führt. Der dritte Aufrufer, qla2xxx_process_purls_iocb(), läuft innerhalb von qla24xx_process_response_queue() mit bereits gehaltener qpair-Sperre und ist sicher; dies ist auch der Grund, warum die Sperre nicht im Helper selbst genommen werden kann (sie würde hardware_lock auf dem Antwortpfad rekursiv erneut erwerben).
Nehmen Sie qp_lock_ptr um die beiden ungesperrten Aufrufer herum und dokumentieren Sie den Helper als caller-locked. Beide laufen im Prozesskontext, daher wird spin_lock_irqsave() verwendet, und nichts in der gesperrten Region schläft.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.