CVE-2026-80620 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
Revert "PCI/MSI: Unmap MSI-X region on error"
This reverts commit 1a8d4c6ecb4c81261bcdf13556abd4a958eca202.
Commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") added an iounmap(dev->msix_base) on the error path of msix_capability_init() to release the MSI-X region when msix_setup_interrupts() fails.
When msix_setup_interrupts() fails, the call chain is:
msix_setup_interrupts() -> __msix_setup_interrupts() struct pci_dev *dev __free(free_msi_irqs) = __dev; ... return ret; // __free cleanup fires on error
The __free(free_msi_irqs) cleanup calls pci_free_msi_irqs(), which already handles the unmap:
void pci_free_msi_irqs(struct pci_dev *dev) {
pci_msi_teardown_msi_irqs(dev); if (dev->msix_base) {
iounmap(dev->msix_base); // already unmapped here dev->msix_base = NULL; // and set to NULL } }
So dev->msix_base is unmapped and set to NULL before msix_setup_interrupts() returns to msix_capability_init(). The "goto out_unmap" introduced by commit 1a8d4c6ecb4c ("PCI/MSI: Unmap MSI-X region on error") then calls iounmap() a second time on a NULL pointer.
This was reproduced on Intel Emerald Rapids (192 CPUs) while running tools/testing/selftests/kexec/test_kexec_jump.sh:
WARNING: CPU#44 at iounmap+0x2a/0xe0 RIP: 0010:iounmap+0x2a/0xe0 RDI: 0000000000000000 Call Trace: msix_capability_init+0x317/0x3f0 __pci_enable_msix_range+0x21d/0x2c0 pci_alloc_irq_vectors_affinity+0xa9/0x130 nvme_setup_io_queues+0x2a8/0x420 [nvme]
nvme_reset_work+0x151/0x340 [nvme]
...
RDI=0 confirms iounmap() is called with NULL.
Restore the original "goto out_disable" and leave the unmap to the existing __free(free_msi_irqs) cleanup.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel vulnerability addressed in this update involves a double-free condition within the PCI Message Signaled Interrupt (MSI-X) subsystem, specifically during the initialization of MSI-X capabilities. The root cause stems from an incorrect error handling path introduced by commit 1a8d4c6ecb4c, which attempted to unmap the MSI-X region upon failure in msix_setup_interrupts(). This change inadvertently created a scenario where the memory mapping for device resources is released twice, leading to undefined behavior and potential system instability. The issue manifests when msix_setup_interrupts() fails, triggering a cleanup sequence that relies on automatic resource management via the __free(free_msi_irqs) attribute attached to the local pci_dev pointer within __msix_setup_interrupts().
When an error occurs in msix_setup_interrupts(), control returns to msix_capability_init(), at which point the __free mechanism automatically invokes pci_free_msi_irqs() as part of its scope exit routine. This function is designed to handle all necessary teardown operations, including calling pci_msi_teardown_msi_irqs() and subsequently checking if dev->msix_base exists before calling iounmap on it. Crucially, after successfully unmapping the region, pci_free_msi_irqs sets dev->msix_base to NULL to prevent further access. However, because the erroneous commit added a goto statement that jumps to an out_unmap label upon failure, the code proceeds to call iounmap() one more time on the same device structure. Since the pointer has already been nullified by the automatic cleanup, this second invocation passes a NULL address to iounmap(), violating kernel memory management expectations and triggering a warning or crash depending on configuration and hardware specifics.
The operational impact of this vulnerability is primarily observed as system instability during high-load scenarios involving NVMe devices and kexec operations, such as those seen in testing environments like test_kexec_jump.sh on Intel Emerald Rapids platforms with extensive CPU counts. The kernel logs indicate warnings originating from iounmap when the register dump shows a zero value for the RDI register, confirming that NULL was passed to the unmapping function. While this may not always result in an immediate kernel panic due to defensive coding within some architectures' implementation of iounmap, it represents a significant deviation from safe memory management practices and can lead to subtle corruption or resource leaks if the underlying architecture does not strictly guard against null pointer dereferences. This type of error falls under CWE-415 Double Free, as it involves releasing resources that have already been deallocated by another part of the cleanup logic.
From a defense-in-depth perspective, this vulnerability highlights the importance of ensuring that manual resource management paths do not conflict with automatic or scoped cleanup mechanisms like __free attributes in modern Linux kernel development. The fix restores the original control flow by reverting to goto out_disable, thereby allowing pci_free_msi_irqs() to handle the unmapping exclusively without duplication. This aligns with best practices for error handling where responsibility for resource release is clearly assigned to a single code path to prevent race conditions or double releases. Security analysts and kernel developers should review similar patterns in other subsystems that mix manual goto-based cleanup with automatic scope-based destruction to ensure no overlapping deallocation occurs. Mitigation involves applying the specific patch that reverts commit 1a8d4c6ecb4c, ensuring that only one unmap operation is executed per initialization attempt failure.