CVE-2026-89907 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Validate MSI data before routing it to EIOINTC
pch_msi_set_irq() passes e->msi.data straight into eiointc_set_irq() as the irq number. The MSI data comes from userspace, that either via a KVM_IRQ_ROUTING_MSI entry set with KVM_SET_GSI_ROUTING (used by irqfd and KVM_IRQ_LINE) or directly via KVM_SIGNAL_MSI, and is never checked against EIOINTC_IRQS.
eiointc_set_irq() uses the value with __set_bit()/__clear_bit() on the 256-bit isr bitmap, eiointc_update_irq() then indexes sw_coremap[] and
the per-cpu coreisr/sw_coreisr bitmaps with it. Therefore a data value >= 256 reads and writes memory past the end of those arrays, i.e. any process holding a VM fd can corrupt kernel memory beyond the allocation of loongarch_eiointc.
Reject MSI data that doesn't fit in the EIOINTC irq space. The DMSINTC path is unaffected as it decodes the vector from the address and masks it.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability identified involves a critical input validation failure within the LoongArch architecture's KVM subsystem, specifically concerning Message Signaled Interrupts or MSI routing to the Extended I/O Interrupt Controller known as EIOINTC. The core technical flaw resides in the pch_msi_set_irq function which acts as an intermediary for processing incoming interrupt requests. This function directly passes the msi.data field into eiointc_set_irq without performing any bounds checking against the valid range of IRQ numbers defined by EIOINTC_IRQS. Since this data originates from userspace, it can be manipulated by a malicious actor through two primary vectors: via KVM_IRQ_ROUTING_MSI entries configured using the KVM_SET_GSI_ROUTING ioctl which is utilized by irqfd and KVM_IRQ_LINE mechanisms, or directly through the KVM_SIGNAL_MSI interface. The absence of validation allows arbitrary values to propagate into the kernel's interrupt handling logic, bypassing standard safety checks that are typically enforced for hardware-specific constraints.
The operational impact of this flaw is severe due to how the EIOINTC subsystem utilizes the unvalidated data value. Once eiointc_set_irq receives the unchecked integer, it employs low-level bit manipulation functions such as __set_bit and __clear_bit on a fixed-size 256-bit interrupt status register bitmap. Subsequently, eiointc_update_irq uses this same unsanitized value to index into software core mapping arrays including sw_coremap along with per-cpu structures like sw_coreisr and coreisr bitmaps. Because these data structures are allocated with a strict limit corresponding to the 256-bit capacity or associated IRQ count, any input value greater than or equal to two hundred fifty six results in out-of-bounds memory access. This leads to reads from and writes to kernel memory locations beyond the intended allocation of loongarch_eiointc structures. Consequently, a process holding a file descriptor for a virtual machine can corrupt adjacent kernel memory, potentially leading to system instability, privilege escalation, or arbitrary code execution depending on what data resides in those out-of-bounds regions.
This vulnerability is classified under CWE-125 which denotes Out-of-Bounds Read and CWE-787 which covers Out-of-Bounds Write, reflecting the dual nature of the memory corruption risk presented by unchecked array indexing. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this flaw facilitates privilege escalation via exploitation of kernel vulnerabilities allowing an unprivileged user to gain higher-level access within the system environment. The attack vector is local requiring only file descriptor access to the VM instance which may be accessible in multi-tenant cloud environments or shared hosting setups where users have control over their virtual machine configurations but not direct root privileges on the host.
Mitigation strategies primarily involve applying the upstream kernel patch that introduces strict validation of MSI data before it is routed to the EIOINTC subsystem. Administrators should ensure that all LoongArch-based systems running KVM are updated with the latest stable kernel versions containing this fix. For environments where immediate patching is not feasible, restricting userspace access to VM file descriptors and limiting the capabilities granted via ioctl interfaces can reduce the attack surface. Additionally, enabling Kernel Self-Protection features such as stack protector hardening and memory isolation techniques may provide secondary layers of defense against exploitation attempts although they do not address the root cause which remains improper input validation in the interrupt routing logic. The DMSINTC path is noted to be unaffected by this specific issue because it decodes the vector from the address field rather than relying solely on data values, thereby masking potential out-of-bounds accesses through architectural design differences.