Skip to main content

Linux Kernel EUVDEUVD-2026-59188

| CVE-2026-72289 CRITICAL
2026-08-15 Linux GHSA-j2wf-f982-8f9v
Information Disclosure Linux Red Hat Suse
9.3
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
9.3 CRITICAL
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
7.5 HIGH

Local ARM64 KVM host access with ability to run a guest gives PR:L; the timing-sensitive race window makes AC:H; primary impact is list corruption causing DoS and possible escalation, not disclosure, so C:N.

3.1 AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:H/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Red Hat
7.0 HIGH
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 17, 2026 - 08:11 vuln.today
CVSS changed
Aug 17, 2026 - 06:22 NVD
9.3 (CRITICAL)
Patch available
Aug 15, 2026 - 07:20 EUVD
CVE Published
Aug 15, 2026 - 05:55 cve.org
CRITICAL 9.3
CVE Published
Aug 15, 2026 - 05:55 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: vgic: Check the interrupt is still ours before migrating it

vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list.

That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed.

Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.

AnalysisAI

Memory corruption in the Linux kernel's KVM/arm64 GICv3 virtualization (vgic) subsystem allows a local attacker on an ARM64 KVM host to trigger a double list removal, corrupting the ap_list and enabling a use-after-free style condition. The flaw lives in vgic_prune_ap_list(), where an interrupt can be pruned from a vCPU's active/pending list a second time after vgic_flush_pending_lpis() already removed it, because the affinity re-check does not confirm the interrupt is still owned by the vCPU. No public exploit is identified at time of analysis, and EPSS is low (0.22%), consistent with a race-condition kernel bug that is difficult to weaponize.

Technical ContextAI

The affected component is the ARM64 KVM in-kernel virtual GIC (Generic Interrupt Controller) emulation, specifically LPI (Locality-specific Peripheral Interrupt) and ap_list (active/pending list) management. vgic_prune_ap_list() temporarily drops both ap_list_lock and irq_lock while migrating an interrupt between vCPUs; on reacquiring the locks it validates only that affinity is unchanged via vgic_target_oracle() rather than confirming irq->vcpu still points to this vCPU. Meanwhile vgic_flush_pending_lpis() can dequeue the interrupt and set irq->vcpu to NULL while leaving enabled/pending/target_vcpu intact, so the oracle returns the same target and the stale entry passes the check, causing list_del() to run twice on an already-removed list node. This is a classic race/time-of-check-to-time-of-use list-corruption pattern (conceptually CWE-416 use-after-free / CWE-362 race condition); the CWE field is not populated in the source data.

RemediationAI

Vendor-released patch: update to a fixed stable kernel for your branch - 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5, or later (7.2-rc4+ on mainline). Apply the distribution kernel update that incorporates the corresponding stable commit (see https://git.kernel.org/stable/c/3893e1fcf6f306b327a8358dcd1cbd077989a240 and the sibling backport commits) and reboot, or live-patch if your distribution supports it. Where immediate patching is not possible on ARM64 KVM hosts, reduce exposure by restricting who can create and control KVM guests (limit /dev/kvm access to trusted operators) and by avoiding untrusted multi-tenant guests on unpatched hosts; note this is a functional restriction on virtualization, not a code fix. There is no configuration toggle that disables the vulnerable vgic path without disabling ARM64 interrupt virtualization itself, so kernel upgrade is the only complete remedy.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-59188 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy