CVE-2026-97528: scsi: qla2xxx: Unlink NVMe unsol ctx before freeing on LS reject error
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Unlink NVMe unsol ctx before freeing on LS reject error
qlanvmexmtlsrsp() obtains uctx, which was linked into fcport->unsolctxhead by qla2xxxprocesspurlsiocb() and is still linked when the NVMe transport calls back to transmit the LS response. On the error (out:) path the function frees uctx with kfree() but never removes it from the list. This leaves a freed node in fcport->unsolctxhead: the next listaddtail() for that fcport writes through the freed node, and a subsequent listdel() can corrupt the list or panic.
Unlink uctx with listdel() before kfree() on the error path, matching the other free sites in qlanvmereleaselsrspcmdkref() and qla2xxxprocesspurlspkt(). qla2x00relsp() in the failure path only returns the SRB to its pool and does not invoke sp->putfn, so the out: path is the sole free and uctx is always still linked there.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel qla2xxx driver with NVMe unsolicited context handling are exposed when the affected LS-response error path is reached for an fcport. The issue concerns a context that remains linked in fcport->unsol_ctx_head after being freed.
What conditions are needed to trigger the failure?
An LS response transmission must take the error path in qla_nvme_xmt_ls_rsp() after qla2xxx_process_purls_iocb() has linked the unsolicited context into fcport->unsol_ctx_head. Later list operations for the same fcport can then write through the freed node or corrupt the list.
What is the likely impact after the error path is hit?
A subsequent list_add_tail() for the affected fcport can access the freed list node, and a later list_del() can corrupt the list or cause a kernel panic.
How can this be mitigated if the fix cannot be applied immediately?
The provided data identifies the triggering condition as an LS-response transmission error path, but does not provide a supported configuration workaround. Applying a kernel version containing the fix is the documented remediation.