linux-kernel - [PATCH 0/2] KVM: Fix dangling IRQ bypass on x86 and arm64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260113174606.104978-1-seanjc@google.com>
Date: Tue, 13 Jan 2026 09:46:04 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Marc Zyngier <maz@...nel.org>, Oliver Upton <oupton@...nel.org>
Subject: [PATCH 0/2] KVM: Fix dangling IRQ bypass on x86 and arm64

Fix three bugs in one, where KVM can incorrectly leave an IRQ configured
for bypass after the associated irqfd is deassigned from the VM (if the VMM
deassigns the irqfd while it's in bypass mode).

Two of the bugs are recent-ish, one each in x86 and arm64.  The x86 bug is
the most visible/noisy as it leads to kernel panics on AMD due to SVM's use
of a per-CPU list to track IRQs/irqfds that are being posted to the vCPU.

The third bug has existed since IRQ bypass was added ~10 years ago.  That
bug is much less likely as it requires hitting a race with a small window,
and likely requires the VMM to do some rather weird stuff on top.

The underlying issue of the x86 and arm64 bugs is that KVM clobbers the
irqfd's copy of the routing information prior to fully deassigning the irqfd,
which results in false negatives when kvm_arch_irq_bypass_del_producer()
checks for "irqfd->irq_entry.type == KVM_IRQ_ROUTING_MSI".

While the x86/arm64 bugs are fixable in arch code, e.g. by explicitly tracking
if an irqfd is in bypass mode (x86 already does this), leaving the routing
information in the irqfd as-is and instead checking if the irqfd is still
active prior to consuming its copy of the routing information fixes both the
arch bugs as well as the latent third bug.

The second patches hardens x86 against similar bugs in the future, by
essentially implementing the arch fix describes above, but wrapped in a WARN
so that bugs elsewhere are detected but less likely to be fatal.

The SVM bug was originally hit with Google's VMM, and confirmed via selftest
(which is also how I verified the fix).  I'm not entirely sure why this hasn't
been hit with QEMU.  My best guess is that QEMU always updates IRQ routing
when deassigning a VFIO IRQFD?

Sean Christopherson (2):
  KVM: Don't clobber irqfd routing type when deassigning irqfd
  KVM: x86: Assert that non-MSI doesn't have bypass vCPU when deleting
    producer

 arch/x86/kvm/irq.c |  3 ++-
 virt/kvm/eventfd.c | 44 ++++++++++++++++++++++++--------------------
 2 files changed, 26 insertions(+), 21 deletions(-)

base-commit: f62b64b970570c92fe22503b0cdc65be7ce7fc7c
-- 
2.52.0.457.g6b5491de43-goog