---
id: "CVE-2026-98878"
kind: "vulnerability"
aliases: ["CVE-2026-98878"]
title: "Linux kernel: GICv5 interrupt priority drop delayed, blocking other interrupts"
severity: "unknown"
cvss: null
epss: 0.00198
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["arm64", "gicv5", "infrastructure", "linux-kernel", "virtualization"]
not_affected_if: ["no-gicv5-hardware"]
published_at: "2026-10-23T12:18:21+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:51+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98878", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98878", "first_seen_at": "2026-10-25T12:38:51+00:00"}]
---

# Linux kernel: GICv5 interrupt priority drop delayed, blocking other interrupts

In 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, check and fix written by a model from the sources; labelled as such._

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98878
- 2026-10-25T12:38:51+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98878

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_