CVE-2026-23287Medium· 5.5▾ SunlitIn 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: …
▾ Sunlit zone — Low / medium · no exploitation signal
impact 30.3 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Sep 8.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
0.1%
Last analysed / modified upstream
— → 5.5
none → medium
0.1% → 0.1%
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().
linux_kernel >= 5.1, < 6.1.167linux_kernel >= 6.2, < 6.6.130linux_kernel >= 6.7, < 6.12.77linux_kernel >= 6.13, < 6.18.17linux_kernel >= 6.19, < 6.19.7linux_kernel = 7.0Upgrade past the affected range:
linux_kernel 6.19.7Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2025-71221High· 7.8In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and des…
CVE-2025-38232High· 7.8In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at …
CVE-2025-71075High· 7.8In the Linux kernel, the following vulnerability has been resolved: scsi: aic94xx: fix use-after-free in device removal path The asd_pci_remove() function fails to synchronize with pending tasklets before freeing the asd_ha structure, …
CVE-2023-53292Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NU…
CVE-2022-36280Medium· 6.3An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'
CVE-2022-36123High· 7.8The Linux kernel before 5.18.13 lacks a certain clear operation for the block starting symbol (.bss)