From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-72289: KVM: arm64: vgic: Check the interrupt is still ours before migrating it
Date: Sat, 15 Aug 2026 15:06:08 +0900 [thread overview]
Message-ID: <2026081500-CVE-2026-72289-e85e@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
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.
The Linux kernel CVE team has assigned CVE-2026-72289 to this issue.
Affected and fixed versions
===========================
Issue introduced in 4.7 with commit 0919e84c0fc1fc73525fdcedefab89ea8460f697 and fixed in 5.10.261 with commit 3893e1fcf6f306b327a8358dcd1cbd077989a240
Issue introduced in 4.7 with commit 0919e84c0fc1fc73525fdcedefab89ea8460f697 and fixed in 5.15.212 with commit cb3efe1a354f1638726725c3ecee1ce8d1a7e2dc
Issue introduced in 4.7 with commit 0919e84c0fc1fc73525fdcedefab89ea8460f697 and fixed in 6.1.178 with commit da2d249a39a1881681c303ceea33f38ba1c5bbeb
Issue introduced in 4.7 with commit 0919e84c0fc1fc73525fdcedefab89ea8460f697 and fixed in 6.6.145 with commit 654be81c4c637af12709d47c7efc3302cd336513
Issue introduced in 4.7 with commit 0919e84c0fc1fc73525fdcedefab89ea8460f697 and fixed in 6.12.97 with commit e363c0bc0226dc5ea5046a88e9a6864b82c45399
Issue introduced in 4.7 with commit 0919e84c0fc1fc73525fdcedefab89ea8460f697 and fixed in 6.18.40 with commit 79fdd2aa774e44847cd9bb7edc811e73e3dc7bfe
Issue introduced in 4.7 with commit 0919e84c0fc1fc73525fdcedefab89ea8460f697 and fixed in 7.1.5 with commit 0658b09cba7fe866c6cd70cd2dcdfdcabe80328f
Issue introduced in 4.7 with commit 0919e84c0fc1fc73525fdcedefab89ea8460f697 and fixed in 7.2-rc4 with commit 0074b82cdfcb5fd13710a0ac308ade68ac6f6fbe
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-72289
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
arch/arm64/kvm/vgic/vgic.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/3893e1fcf6f306b327a8358dcd1cbd077989a240
https://git.kernel.org/stable/c/cb3efe1a354f1638726725c3ecee1ce8d1a7e2dc
https://git.kernel.org/stable/c/da2d249a39a1881681c303ceea33f38ba1c5bbeb
https://git.kernel.org/stable/c/654be81c4c637af12709d47c7efc3302cd336513
https://git.kernel.org/stable/c/e363c0bc0226dc5ea5046a88e9a6864b82c45399
https://git.kernel.org/stable/c/79fdd2aa774e44847cd9bb7edc811e73e3dc7bfe
https://git.kernel.org/stable/c/0658b09cba7fe866c6cd70cd2dcdfdcabe80328f
https://git.kernel.org/stable/c/0074b82cdfcb5fd13710a0ac308ade68ac6f6fbe
reply other threads:[~2026-08-15 6:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026081500-CVE-2026-72289-e85e@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.