CVE-2026-89853: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump
qla2x00freefcetrace() freed and cleared ha->fce while holding only fcemutex. The firmware-dump consumers qla27xxfwdtentryt264() and qla25xxcopyfce() read ha->fce (NULL check followed by a copy of the buffer) under hardwarelock and never take fcemutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free.
Unpublish ha->fce under hardwarelock, then release the lock and free the DMA buffer (dmafreecoherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
A firmware dump must be reading the FCE trace buffer while an FCE disable operation through debugfs frees that buffer. The race occurs because dump consumers use hardware_lock while the prior free path used only fce_mutex.
Who is realistically exposed to this issue?
Systems using the Linux qla2xxx SCSI driver are exposed when FCE tracing is enabled and debugfs can be used to disable FCE concurrently with a firmware dump. The provided information does not establish exposure for systems that do not perform those concurrent operations.
What can be done if the fix cannot be applied immediately?
Avoid disabling FCE through debugfs while firmware dumps may be in progress. Serializing those operations prevents the described race between the dump copy and DMA-buffer free.
How does the fix prevent the race?
The fix clears ha->fce while holding hardware_lock, the same lock used by firmware-dump consumers, and frees the DMA buffer only after releasing that lock. A dump then either copies a valid buffer or sees a NULL pointer and skips the FCE data.