CVE-2026-72288: Linux kernel · KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 9.3 Critical · fixed in eb74f3feb68e64cf69f86cb806a15d8cfb6757f4 : patch Linux kernel as a priority.
Data as of 26 Oct 2026, 13:47 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 8% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in eb74f3feb68e64cf69f86cb806a15d8cfb6757f4, d19dca8194ebed371e624331c6be2cb73b562caf, b1a89d12d35a8256d2b170ced0b1c86851f3def2 +2
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 15 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling Hyunwoo Kim reports some really bad races should the following situation occur: - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows. The fix is two-fold: - Before dropping the irq and ap_list locks, take a reference on the irq - Do not try to handle migration of the pending bit: there is no expectation that this state is retained, as per the architecture With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).
References
- git.kernel.org/stable/c/eb74f3feb68e64cf69f86cb806a15d8cfb6757f4 (opens in a new tab)
- git.kernel.org/stable/c/77c61235d66246dd6a5f55587f0afc273d832775 (opens in a new tab)
- git.kernel.org/stable/c/d19dca8194ebed371e624331c6be2cb73b562caf (opens in a new tab)
- git.kernel.org/stable/c/b1a89d12d35a8256d2b170ced0b1c86851f3def2 (opens in a new tab)
- git.kernel.org/stable/c/7258770e5814f15e8308ebda82ac9acf6964ba8e (opens in a new tab)