mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>
Subject: [PATCH 0/2] KVM: Fix dangling IRQ bypass on x86 and arm64
Date: Tue, 13 Jan 2026 09:46:04 -0800	[thread overview]
Message-ID: <20260113174606.104978-1-seanjc@google.com> (raw)

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


             reply	other threads:[~2026-01-13 17:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-13 17:46 Sean Christopherson [this message]
2026-01-13 17:46 ` [PATCH 1/2] KVM: Don't clobber irqfd routing type when deassigning irqfd Sean Christopherson
2026-01-13 17:46 ` [PATCH 2/2] KVM: x86: Assert that non-MSI doesn't have bypass vCPU when deleting producer Sean Christopherson
2026-01-15 18:03 ` [PATCH 0/2] KVM: Fix dangling IRQ bypass on x86 and arm64 Sean Christopherson

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=20260113174606.104978-1-seanjc@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=pbonzini@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®