CVE-2026-89854: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix cs84xx use-after-free on host teardown
qla84xxputchip() drops the last reference to ha->cs84xx and frees it via qla84xxchiprelease() without clearing ha->cs84xx. During teardown it ran before scsiremovehost(), which is what removes the 84xxfwversion host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx84xxfwversionshow(), which dereferences the freed ha->cs84xx, resulting in a use-after-free.
Move qla84xxputchip() to after scsiremovehost() in both qla2x00removeone() and qla2x00disableboardonpcierror(). Once scsiremovehost() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems using the Linux qla2xxx SCSI driver with cs84xx/84xx support are exposed during adapter host teardown, because the affected sysfs attribute is present on the SCSI host.
What must occur for the use-after-free to be triggered?
A read of the 84xx_fw_version host sysfs attribute must race with host teardown after qla84xx_put_chip() frees ha->cs84xx but before scsi_remove_host() removes the attribute.
How can I tell whether an affected system has encountered the issue?
The issue would manifest when qla24xx_84xx_fw_version_show() dereferences a freed ha->cs84xx during the teardown window. The provided data does not specify a particular log message, crash signature, or detection command.
What is the mitigation when updating is not immediately possible?
The provided fix removes the sysfs attribute through scsi_remove_host() before releasing the cs84xx chip reference. No separate operational workaround is specified in the provided data.