CVE-2026-97536: scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown
The response queue MSI-X handler qla2xxxmsixrspq() schedules qladowork() via queuework(ha->wq, &qpair->qwork). qladowork() dereferences the qpair (vha, rsp) and takes qpair->qplock.
During teardown, qla2xxxdeleteqpair() deletes the response queue, which calls freeirq() in qla25xxfreerspque(), and then frees the queue and the qpair. freeirq() waits for running hardirq handlers but does not cancel work already placed on ha->wq. A still-pending qwork then runs qladowork() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroyworkqueue(ha->wq) forces pending work to run after the queue pairs have been freed.
Flush the work item with cancelworksync() in qla25xxfreerspque() after freeirq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp->qpair and ha->wq to match the INITWORK() condition and avoid operating on an uninitialized workstruct.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In qla25xx_free_rsp_que(), call cancel_work_sync() to flush qla_do_work() before freeing the response queue and qpair; guard qla_do_work() against rsp->qpair and ha->wq being unavailable, matching the INIT_WORK() condition.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux systems using the qla2xxx SCSI driver and queue pairs with response-queue MSI-X handling are exposed during queue or adapter teardown. The failure path involves work queued on the adapter workqueue after the associated queue pair and response queue have been freed.
What conditions are required to trigger the use-after-free?
An interrupt handler must queue qpair->q_work, followed by teardown that frees the response queue and qpair before the queued work runs. Full adapter teardown increases the likelihood because destroying the workqueue forces pending work to execute.
How can the issue be mitigated if the fix cannot be applied immediately?
The provided data does not identify a configuration-only mitigation. The required fix is to cancel and flush the queued work with cancel_work_sync() after free_irq() prevents new work from being queued and before queue-pair memory is released.
How can an affected failure be recognized?
The vulnerable path can result in qla_do_work() dereferencing a freed qpair or response queue and attempting to take qpair->qp_lock. Failures are most likely around queue deletion or adapter teardown with pending qla2xxx workqueue activity.