CVE-2026-46141

What it actually does

This is a Linux kernel memory leak in the powerpc XIVE interrupt controller path. When MSI-X interrupt vectors are allocated for devices such as NVMe, XIVE allocates a struct xive_irq_data and stores it as interrupt chip data. During teardown, the free path looks up chip_data through the wrong interrupt domain, so the lookup fails and the XIVE allocation is not released. Repeated allocation and teardown of affected MSI-X interrupts can steadily consume kernel memory, eventually degrading system stability or causing denial of service through memory exhaustion. The issue is architecture- and configuration-specific, primarily affecting PowerPC systems using XIVE interrupt handling and MSI-X-capable devices.

Why it matters to the business

Affected PowerPC Linux systems can become unstable or unavailable if kernel memory is repeatedly leaked through device interrupt allocation and teardown. In operational terms, this can lead to degraded storage or PCIe device behavior, host crashes, forced reboots, and workload interruption. The risk is lower than a remote code execution issue because exploitation is local and requires the vulnerable kernel/device path, but the availability impact can still be significant for systems hosting critical workloads on affected PowerPC platforms.

How an attack unfolds

An attacker with local access first identifies that the system is running an affected Linux kernel on a PowerPC platform using XIVE and MSI-X-capable hardware or virtual devices, such as NVMe. The attacker then repeatedly triggers code paths that allocate and free MSI-X interrupt vectors, for example by causing device probe/remove, driver bind/unbind, or other local operations that exercise PCI MSI-X setup and teardown. Because the XIVE free path retrieves chip_data from the wrong interrupt domain, each cycle can leave behind an unreleased xive_irq_data allocation. Over time, the leaked kernel memory accumulates. If repeated enough, available kernel memory is reduced, potentially causing performance degradation, allocation failures, service disruption, or a host denial of service. There is no indication from the provided intelligence that this vulnerability is being exploited in the wild, used by ransomware, or has a public exploit.

How to fix it

Apply a Linux kernel update from the relevant distribution or hardware vendor that includes the powerpc/xive fix changing xive_irq_free_data() to retrieve irq_data from the correct interrupt domain using irq_domain_get_irq_data() and irq_data_get_irq_chip_data(). Because no exact fixed package versions were provided, remediation should be tracked through vendor advisories for the affected Linux kernel branch in use. Prioritize PowerPC systems that use XIVE interrupt handling and MSI-X devices, especially NVMe or other high-churn PCIe devices. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting permissions for device driver bind/unbind and hotplug operations, disabling unnecessary device hotplug workflows, and monitoring for abnormal kernel memory growth. Mitigations reduce exploitability but do not correct the leak; the durable fix is a patched kernel followed by reboot into the updated kernel.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that includes the XIVE chip_data lookup fix. Validate with the distribution package manager, kernel changelog, or vendor advisory, then reboot and verify the active kernel version with uname -a. On PowerPC systems where kmemleak is enabled, reproduce a safe MSI-X allocation/free lifecycle in a controlled maintenance environment and confirm that kmemleak no longer reports unreferenced xive_irq_data-related allocations. Review dmesg and kernel logs for absence of repeated kmemleak reports containing xive_irq_alloc_data, xive_irq_domain_alloc, pci_msi_setup_msi_irqs, __pci_enable_msix_range, and nvme_probe. Also monitor kernel memory consumption over repeated device lifecycle operations to ensure memory usage stabilizes rather than growing monotonically.

Typical attack path

1. Gain local access to an affected PowerPC Linux system with low-privileged execution capability.
2. Confirm the system uses a vulnerable kernel path involving XIVE interrupt handling and MSI-X-capable PCI devices such as NVMe.
3. Repeatedly trigger MSI-X allocation and teardown through device probing, removal, driver rebinding, hotplug-like workflows, or comparable local actions.
4. Cause xive_irq_data objects to remain allocated because the kernel free path looks up interrupt chip data through the wrong domain.
5. Accumulate unreleased kernel memory over many iterations.
6. Degrade system performance or exhaust kernel memory sufficiently to cause service disruption, crashes, or reboot-required denial of service.

How to detect it

Look for evidence of repeated MSI-X allocation and teardown combined with kernel memory leaks on PowerPC systems. Primary log sources are dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, syslog, and kmemleak output if enabled under /sys/kernel/debug/kmemleak. Search for kmemleak reports showing unreferenced objects with stack traces that include xive_irq_alloc_data, xive_irq_domain_alloc, pseries_irq_domain_alloc, msi_domain_alloc, pci_msi_setup_msi_irqs, __pci_enable_msix_range, pci_alloc_irq_vectors_affinity, nvme_pci_enable, or nvme_probe. Also review auditd, shell history, sudo logs, and udev/system logs for repeated driver bind/unbind, PCI device remove/rescan, NVMe device resets, or hotplug-like activity by local users. For forensic review, correlate spikes in kernel memory or slab consumption with repeated PCI/NVMe lifecycle events and kmemleak traces. There are no known threat actors or ransomware campaigns associated with this vulnerability in the provided data, so detection should focus on behavioral evidence of local abuse or operational triggering rather than known malware signatures.

• kmemleak: Unreferenced object
• xive_irq_alloc_data
• xive_irq_domain_alloc
• xive_irq_free_data
• irq_domain_get_irq_data
• irq_data_get_irq_chip_data
• pseries_irq_domain_alloc
• msi_domain_alloc
• pci_msi_setup_msi_irqs
• __pci_enable_msix_range
• pci_alloc_irq_vectors_affinity
• nvme_pci_enable
• nvme_probe
• /sys/kernel/debug/kmemleak
• /sys/bus/pci/drivers/*/unbind
• /sys/bus/pci/drivers/*/bind
• /sys/bus/pci/rescan
• /sys/bus/pci/devices/*/remove

What your security team should do

• Inventory PowerPC Linux systems and identify those using XIVE interrupt handling and MSI-X-capable PCIe devices, especially NVMe storage.
• Prioritize patching affected systems that support local multi-user access, virtualization, device hotplug, or frequent PCIe/NVMe lifecycle operations.
• Update to a vendor kernel containing the powerpc/xive irq_data domain lookup fix and reboot to ensure the patched kernel is active.
• Restrict local users from performing driver bind/unbind, PCI device reset, device passthrough manipulation, or hotplug-style operations unless operationally required.
• Monitor kernel memory, slab usage, dmesg, and kmemleak output for signs of repeated unreleased XIVE interrupt allocations until patching is complete.
• Treat unexplained kernel memory growth or repeated kmemleak traces involving xive_irq_alloc_data and NVMe MSI-X setup as a possible exploitation or stress indicator.
• Because EPSS is very low and there is no KEV listing or known exploitation, prioritize based on platform exposure and availability criticality rather than broad emergency response.