CVE-2026-89848: scsi: qla2xxx: Quiesce response IRQ before freeing request queue
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Quiesce response IRQ before freeing request queue
qla2xxxdeleteqpair() deletes the request queue before the response queue. qla25xxdeletereqque() frees the request queue memory (kfree(req) in qla25xxfreereqque()), but the response-queue MSI-X is only released later, in qla25xxfreerspque(). In that window the response interrupt can still fire, qla2xxxmsixrspq() queues qpair->qwork, and qladowork() -> qla24xxprocessresponsequeue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free.
The cancelworksync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req.
Release the response-queue interrupt and flush qpair->qwork before deleting the request queue, so no late completion can reach the freed request queue. Clearing haveirq makes the subsequent qla25xxfreerspque() skip its freeirq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early.
Affected Software
Event History
Frequently Asked Questions
When does the use-after-free occur?
It occurs if a response-queue MSI-X interrupt fires after the request queue has been freed but before the response queue interrupt is released. The interrupt can queue qpair work that later dereferences the freed request queue through rsp->req.
What conditions are needed to trigger the issue?
The affected qpair must be undergoing teardown, and a late response completion interrupt must arrive in the interval between request-queue deletion and response-queue interrupt release. The provided information does not describe an external attacker-controlled trigger.
What does the fix change?
The fix releases the response-queue interrupt and flushes qpair work before deleting the request queue. It preserves the firmware queue-delete order while preventing late response processing from accessing the freed queue.
Are affected kernel versions or a configuration workaround identified?
No affected version range, default-configuration status, or temporary workaround is provided. The supplied stable kernel references identify commits containing the resolution.