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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 9.3
AV:L - The bug is reached only from KVM guest execution paths—GICv3 redistributor GICR_CTLR LPI-disable MMIO traps into vgic_flush_pending_lpis() and vCPU exit/sync paths into vgic_prune_ap_list()—not from any remote network, adjacent-radio, or physical-device interface on the host.
AC:L - A malicious multi-vCPU guest controls both racing sides by pinning threads, changing LPI affinity via ITS so an interrupt must migrate off one vCPU's ap_list, and concurrently disabling LPIS on that redistributor; the attacker creates the window rather than depending on uncontrollable host timing or memory layout.
PR:N - The highest-impact scenario is a malicious cloud VM tenant on arm64 KVM who needs no host privileges beyond code already running inside the assigned guest; exploitation uses guest-kernel GIC MMIO/ITS operations, not host root, CAP_SYS_ADMIN in the init namespace, or additional /dev/kvm access beyond having a VM.
UI:N - Exploitation is fully attacker-driven from within the guest VM through deliberate LPI setup, affinity changes, and timed GICR_CTLR writes; no victim user or administrator action on the host is required beyond normal VM operation.
S:C - Double list_del()/list_add_tail() on host-kernel ap_list linkages corrupts KVM VGIC state from guest-controlled interrupt operations, crossing the guest-to-host virtualization security boundary with VM-escape-class impact rather than confining damage to the attacker's VM.
C:H - Corrupting detached ap_list pointers and inserting them into another vCPU's ap_list_head enables out-of-bounds kernel linked-list traversal and disclosure of adjacent kmalloc slab memory (struct vgic_irq and neighboring objects); per kernel guidance, this list corruption is leverageable for arbitrary host memory read primitives.
I:H - The vulnerable path performs list_del() on an already removed entry and may follow with list_add_tail() onto another vCPU's ap_list, letting a guest steer kernel list pointers and overwrite adjacent vgic_irq/host heap metadata for control-flow or data corruption on the hypervisor.
A:H - Re-running list_del() on an entry already removed by vgic_flush_pending_lpis() dereferences poisoned list pointers and corrupts live ap_list_heads, causing immediate host kernel BUG/oops/panic or persistent interrupt-delivery failure during subsequent VGIC processing.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is reached only from KVM guest execution paths—GICv3 redistributor GICR_CTLR LPI-disable MMIO traps into vgic_flush_pending_lpis() and vCPU exit/sync paths into vgic_prune_ap_list()—not from any remote network, adjacent-radio, or physical-device interface on the host.
AC:L - A malicious multi-vCPU guest controls both racing sides by pinning threads, changing LPI affinity via ITS so an interrupt must migrate off one vCPU's ap_list, and concurrently disabling LPIS on that redistributor; the attacker creates the window rather than depending on uncontrollable host timing or memory layout.
PR:N - The highest-impact scenario is a malicious cloud VM tenant on arm64 KVM who needs no host privileges beyond code already running inside the assigned guest; exploitation uses guest-kernel GIC MMIO/ITS operations, not host root, CAP_SYS_ADMIN in the init namespace, or additional /dev/kvm access beyond having a VM.
UI:N - Exploitation is fully attacker-driven from within the guest VM through deliberate LPI setup, affinity changes, and timed GICR_CTLR writes; no victim user or administrator action on the host is required beyond normal VM operation.
S:C - Double list_del()/list_add_tail() on host-kernel ap_list linkages corrupts KVM VGIC state from guest-controlled interrupt operations, crossing the guest-to-host virtualization security boundary with VM-escape-class impact rather than confining damage to the attacker's VM.
C:H - Corrupting detached ap_list pointers and inserting them into another vCPU's ap_list_head enables out-of-bounds kernel linked-list traversal and disclosure of adjacent kmalloc slab memory (struct vgic_irq and neighboring objects); per kernel guidance, this list corruption is leverageable for arbitrary host memory read primitives.
I:H - The vulnerable path performs list_del() on an already removed entry and may follow with list_add_tail() onto another vCPU's ap_list, letting a guest steer kernel list pointers and overwrite adjacent vgic_irq/host heap metadata for control-flow or data corruption on the hypervisor.
A:H - Re-running list_del() on an entry already removed by vgic_flush_pending_lpis() dereferences poisoned list pointers and corrupts live ap_list_heads, causing immediate host kernel BUG/oops/panic or persistent interrupt-delivery failure during subsequent VGIC processing.
CVSS 3.1