CVE-2026-98426 in Linux
Summary
by MITRE • 10/15/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path
mwifiex_pcie_request_irq() registers each MSI-X vector with a per-index dev_id (&card->msix_ctx[i]). On a request_irq() failure the cleanup loop
"for (j = 0; j < i; j++)" frees msix_entries[j].vector but passes the
failed index's &card->msix_ctx[i] as the dev_id. free_irq() matches on
(irq, dev_id), so it fails to find the action registered with &card->msix_ctx[j]: the already-requested IRQ j is not freed (leaked) and
free_irq() warns about freeing a non-existent IRQ. Use &card->msix_ctx[j].
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/15/2026
The Linux kernel driver for Marvell Wi-Fi Express, known as mwifiex, contains a critical resource management flaw within its PCIe interrupt handling subsystem that leads to an Interrupt Request leak during the initialization phase. This vulnerability specifically manifests in the mwifiex_pcie_request_irq function, which is responsible for registering multiple MSI-X vectors with the kernel's interrupt handler infrastructure. The driver utilizes a per-index device ID structure, referenced as &card->msix_ctx[i], to associate each registered interrupt vector with its corresponding context data. This design ensures that when an interrupt occurs or needs to be dismantled, the system can correctly identify which specific hardware resource is being addressed through a precise matching mechanism based on both the IRQ number and the associated device ID pointer.
The technical flaw arises during the error handling path of this registration process. When mwifiex_pcie_request_irq attempts to register an MSI-X vector using request_irq(), it iterates through available vectors sequentially. If the request for a specific index i fails, the driver enters a cleanup loop designed to release any previously successful registrations from indices zero up to but not including i. However, within this loop, while the code correctly identifies the IRQ number via msix_entries[j].vector, it erroneously passes &card->msix_ctx[i] as the dev_id parameter to free_irq(). This is a fundamental logical error because the variable j represents the index of the already-registered interrupt being cleaned up, whereas i represents the index of the failed request that triggered the cleanup. Consequently, the driver attempts to free an IRQ using a device ID pointer that corresponds to a different, unregistered or differently indexed context entry rather than the one actually registered for vector j.
This mismatch between the actual registration data and the parameters passed during teardown results in a failure of the kernel's internal matching algorithm. The free_irq function relies on exact equality between the provided dev_id and the one stored during request_irq to locate and remove the interrupt action handler. Since &card->msix_ctx[i] does not match &card->msix_ctx[j], the lookup fails, leaving the previously allocated IRQ j active but orphaned from its proper management context. This constitutes a resource leak where system interrupts remain reserved by the driver even though they are no longer functional or intended for use in that specific configuration state. Over time, such leaks can exhaust the limited pool of MSI-X vectors available to the PCIe device, potentially preventing other devices on the same bus from functioning correctly and leading to broader system instability or denial of service conditions related to hardware resource exhaustion.
Furthermore, this error triggers kernel warnings regarding the freeing of non-existent IRQs, which clutters dmesg logs and can mask more serious underlying issues during debugging sessions. From a security perspective, while primarily a stability issue, persistent resource leaks in kernel drivers can be exploited by local attackers to induce denial-of-service conditions against system resources or potentially trigger race conditions if other subsystems attempt to interact with the improperly managed interrupt state. The vulnerability aligns with CWE-401, which describes missing release of memory after effective usage, and specifically relates to improper resource cleanup in error paths. In terms of attack vectors, this falls under ATT&CK technique T1529, System Shutdown or Reboot, as exhausting system resources like interrupts can effectively halt normal operations without requiring elevated privileges beyond those needed to load the driver module.
To mitigate this vulnerability, it is imperative that systems running affected versions of the Linux kernel are updated with patches that correct the index variable used in the cleanup loop. The fix involves changing the dev_id parameter from &card->msix_ctx[i] to &card->msix_ctx[j], ensuring that free_irq receives the exact pointer associated with the interrupt vector being released. Administrators should verify their kernel versions against vendor advisories and apply updates promptly. Additionally, developers reviewing similar PCIe driver code should enforce strict adherence to index consistency in error handling paths, utilizing static analysis tools to detect mismatches between loop variables and resource identifiers during the registration and deregistration phases of hardware initialization.