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

> A flaw in the Linux kernel's SiFive PLIC driver allows attackers to freeze UART interrupts by changing affinity settings, causing a denial of service.

- **Severity:** Medium 5.5 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 25 Mar 2026
- **Updated:** 15 Oct 2026
- **Also known as:** BELL-CVE-2026-23287, DEBIAN-CVE-2026-23287, GHSA-73mm-44q3-cmm6, ROOT-OS-DEBIAN-11-CVE-2026-23287, ROOT-OS-DEBIAN-12-CVE-2026-23287, ROOT-OS-DEBIAN-13-CVE-2026-23287, ROOT-OS-UBUNTU-2204-CVE-2026-23287, ROOT-OS-UBUNTU-2404-CVE-2026-23287, UBUNTU-CVE-2026-23287

## What is CVE-2026-23287?

CVE-2026-23287 is a medium-severity denial of service vulnerability in Linux kernel, published on 25 Mar 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official 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().

## Which versions are affected by CVE-2026-23287?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2026-23287?

Apply the vendor's patch.

## Is CVE-2026-23287 being exploited?

There is no known exploitation of CVE-2026-23287 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-23287 and fix it if it is affected.

What it is: CVE-2026-23287 is a medium-severity denial of service vulnerability in Linux kernel, published on 25 Mar 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-23287 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-23287/ (Markdown: https://insights.sbomify.com/CVE-2026-23287/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-23287
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-23287
- OSV: https://osv.dev/vulnerability/CVE-2026-23287

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-23287/
Summaries are generated and may contain mistakes; the official description above is the record.