CVE-2026-89850: scsi: qla2xxx: Don't query firmware state while chip is down
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Don't query firmware state while chip is down
qla2x00fwstateshow() initializes rval to QLAFUNCTIONFAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00getfirmwarestate() because rval != QLASUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrommutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt.
Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrommutex, and only when the chip is up and not EEH-busy.
Affected Software
Event History
Frequently Asked Questions
Under what conditions can this issue cause an adapter hang?
The issue is triggered when firmware state is queried while the chip is down or while EEH is busy, such as during an ISP reset or PCI error recovery. The vulnerable path can issue an unsynchronized mailbox command and hang the adapter.
What changes with the resolved version?
Firmware state queries issue a mailbox command at most once, only while holding optrom_mutex and only when the chip is up and not EEH-busy. When a query cannot safely run, the firmware state is marked unknown instead of attempting a fallback mailbox command.