Описание
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.
A flaw was found in the KVM (Kernel-based Virtual Machine) arm64 vgic (Virtual Generic Interrupt Controller) component of the Linux kernel. During interrupt migration, the vgic_prune_ap_list() function temporarily drops and reacquires locks. If an interrupt is removed from the active processor list (ap_list) during this unlocked period, a subsequent check for interrupt affinity may still pass, leading to a double deletion of the interrupt from the list. This double free-like condition could potentially lead to system instability or denial of service.
Отчет
KVM arm64 vgic has a race in vgic_prune_ap_list while migrating a pending interrupt between vCPUs. The code drops locks and later checks only that the target affinity is unchanged, but the interrupt may already have been removed from the old ap_list by vgic_flush_pending_lpis while enabled and pending state still makes the affinity check pass. This can make list_del run a second time on an already removed list entry, leading to host kernel list corruption or a crash. For the CVSS the PR:L is used because the attacker typically needs the ability to run or control a guest VM or local KVM context, not full host administrator privileges. The issue is not directly network reachable and is a local or guest-to-host virtualization attack surface. Impact is at least denial of service on the host.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel | Affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat Enterprise Linux 10 | kernel | Fixed | RHSA-2026:81406 | 12.10.2026 |
| Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2026:76739 | 08.10.2026 |
| Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2026:76739 | 08.10.2026 |
| Shadow Migration Toolkit for Virtualization for RHEL 10 | kernel | Fixed | RHSA-2026:81406 | 12.10.2026 |
Показывать по
Дополнительная информация
Статус:
7 High
CVSS3
Связанные уязвимости
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...
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 vCP
In the Linux kernel, the following vulnerability has been resolved: K ...
7 High
CVSS3