Live › vulnerability › CVE-2026-98878
Go to dashboardIn the Linux GICv5 interrupt controller driver, the priority drop ran only when an interrupt was deactivated, so a long-running handler could hold back all other interrupts. The fix moves the priority drop to run right after an interrupt is acknowledged, which lets other interrupts be signalled sooner; the sources describe this as a denial-of-service risk and do not describe code execution.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running Linux kernels with the GICv5 interrupt controller driver, such as ARM servers and hosts that inject physical interrupts into guest VMs in software. The sources do not list affected kernel versions or say which systems ship GICv5 hardware, so check the kernel version and hardware against the NVD entry.
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v5: Immediately exec priority drop following activate
With GICv5 an interrupt of equal or lower priority cannot be signalled until there has been a priority drop. This is done via the GIC CDEOI system instruction. Once this has been executed, the hardware is able to signal the next interrupt if there is one.
As all interrupts are programmed to have the same priority, no new interrupts can be signalled until the priority drop has happened. This can cause issues when, for example, an interrupt remains active while a long running process takes place, such as when injecting a physical interrupt into a guest VM in software.
The GICv5 driver has so far done the priority drop as part of irq_eoi(), i.e., at the same time as deactivating the interrupt. This means that any long running process (or VM) could block incoming interrupts, effectively causing a denial of service for all other interrupts.
Rather than doing the EOI as part of irq_eoi() (which the name would suggest would be a good place for it), move it to happen immediately after acknowledging an interrupt in the main GICv5 interrupt handler. The deactivation of interrupts (GIC CDDI) remains implemented as part of irq_eoi(), which means that the same interrupt cannot be signalled a second time until deactivated by software.
This page as .md · .json · in your agent: get_signal("CVE-2026-98878")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.