CVE-2026-98878 in Linux
Summary
by MITRE • 10/23/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified within the Linux kernel's Generic Interrupt Controller version 5 driver stems from an incorrect sequencing of hardware operations during interrupt handling, specifically concerning priority management and deactivation logic. In ARM architecture systems utilizing GICv5, the hardware enforces a strict rule that prevents signaling interrupts with equal or lower priority until a specific priority drop operation has been executed via the CDEOI system instruction. This mechanism is critical for maintaining proper interrupt nesting and ensuring that higher-priority events can preempt ongoing processes without being blocked by pending lower-priority tasks. The core technical flaw lies in the driver's implementation of this sequence, where the necessary priority drop was historically deferred until the end of the interrupt lifecycle during the irq_eoi function call. This design choice inadvertently created a window where any long-running process or virtual machine execution could effectively block all incoming interrupts that did not possess strictly higher priority than the currently active one.
From an operational perspective, this flaw manifests as a significant performance degradation and potential denial of service condition for system-wide interrupt handling. When an interrupt is acknowledged but its associated priority drop is delayed until deactivation, any subsequent code executing within that context prevents new interrupts from being signaled by the hardware if they fall below or match the current active priority level. This issue becomes particularly acute in virtualized environments where physical interrupts are injected into guest VMs via software emulation. If a guest performs long-running computations while an interrupt is held active, the host system's ability to respond to other critical events, such as timer ticks, network packets, or hardware errors, is severely impaired. The result is a systemic latency increase that can lead to missed deadlines in real-time systems and general instability across the platform due to the starvation of lower-priority but essential interrupt sources.
This vulnerability aligns with CWE-829, which describes Inclusion of Functionality Outside Proper Control Boundary, as the driver failed to properly control the timing of hardware state changes relative to software execution context. Furthermore, it relates to CWE-400, a Resource Exhaustion issue, where the improper sequencing leads to resource contention by blocking interrupt delivery paths. From an ATT&CK perspective, while this is not directly exploitable for remote code execution in the traditional sense, the resulting denial of service impacts availability and could be leveraged in scenarios requiring disruption of system responsiveness or timing-based attacks against virtualized workloads that rely on precise interrupt scheduling. The flaw highlights a critical misunderstanding of hardware requirements where software assumptions about interrupt handling order conflicted with strict architectural constraints defined by ARM for GICv5 operation.
The resolution involves restructuring the interrupt handler to execute the priority drop immediately after acknowledging an interrupt, rather than deferring it until deactivation. By moving this operation out of irq_eoi and into the main interrupt acknowledgment routine, the driver ensures that the hardware is permitted to signal subsequent interrupts without delay, regardless of their relative priority compared to the currently active one. The deactivation logic, which uses the CDDI instruction to prevent re-signaling of the same interrupt until explicitly deactivated by software, remains in irq_eoi where it logically belongs for managing interrupt lifecycle state rather than immediate hardware signaling permissions. This separation ensures that high-priority interrupts can always preempt lower ones while maintaining correct isolation between distinct interrupt instances.
To mitigate this issue and similar architectural misconfigurations, system administrators should ensure their Linux kernels are updated to versions containing the corrected GICv5 driver logic. For environments running virtualized workloads, monitoring for unusual latency spikes or missed timer events may indicate residual issues if patches have not been applied. Developers integrating custom interrupt handlers must adhere strictly to hardware specification requirements regarding priority management and avoid deferring critical state changes until after lengthy processing blocks. Adhering to these practices ensures that the operating system maintains responsive interrupt handling capabilities, preserving both performance stability and security posture by preventing availability degradation through improper resource scheduling.