CVE-2026-98426: wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path
mwifiexpcierequestirq() registers each MSI-X vector with a per-index devid (&card->msixctx[i]). On a requestirq() failure the cleanup loop "for (j = 0; j < i; j++)" frees msixentries[j].vector but passes the failed index's &card->msixctx[i] as the devid. freeirq() matches on (irq, devid), so it fails to find the action registered with &card->msixctx[j]: the already-requested IRQ j is not freed (leaked) and freeirq() warns about freeing a non-existent IRQ. Use &card->msixctx[j].
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Fix the mwifiex_pcie_request_irq() MSI-X error-path cleanup loop to call free_irq() with &card->msix_ctx[j] as the dev_id for each previously requested vector j, matching the per-index dev_id used by request_irq().
Event History
Frequently Asked Questions
When can this issue be triggered?
It occurs in the mwifiex PCIe driver's MSI-X error path when a request_irq() call fails after one or more MSI-X vectors have already been registered.
What is the practical impact of the faulty cleanup?
Previously registered IRQs are not freed because cleanup supplies the failed vector's dev_id instead of the dev_id associated with each earlier vector. The kernel also warns that it is freeing a non-existent IRQ.
How is the issue fixed?
The cleanup loop must call free_irq() with the per-vector dev_id for the IRQ being released, using &card->msix_ctx[j] rather than &card->msix_ctx[i].