summaryrefslogtreecommitdiff
path: root/tools/perf/lib/Documentation/tutorial/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2026-01-22 18:28:16 -0800
committerSean Christopherson <seanjc@google.com>2026-01-23 09:11:16 -0800
commitc4a365cd4a4ec105012ab3ae5ff5cf11f8533771 (patch)
treecfa3a4efa97e0773eab4261c6ba81e4e6adffbac /tools/perf/lib/Documentation/tutorial/git@git.tavy.me:linux.git
parentde0dc71188ca54cfe13fac5c4334715fb37fe8ce (diff)
KVM: x86: Drop WARN on INIT/SIPI being blocked when vCPU is in Wait-For-SIPI
Drop the sanity check in kvm_apic_accept_events() that attempts to detect KVM bugs by asserting that a vCPU isn't in Wait-For-SIPI if INIT/SIPI are blocked, because if INIT is blocked, then it should be impossible for a vCPU to get into WFS in the first place. Unfortunately, syzbot is smarter than KVM (and its maintainers), and circumvented the guards put in place by commit 0fe3e8d804fd ("KVM: x86: Move INIT_RECEIVED vs. INIT/SIPI blocked check to KVM_RUN") by swapping the order and stuffing VMXON after INIT, and then triggering kvm_apic_accept_events() by way of KVM_GET_MP_STATE. Simply drop the WARN as it hasn't detected any meaningful KVM bugs in years (if ever?), and preventing userspace from clobbering guest state is generally a non-goal. More importantly, fully closing the hole would likely require enforcing some amount of ordering in KVM's ioctls, which is a much bigger risk than simply deleting the WARN. Reported-by: syzbot+59f2c3a3fc4f6c09b8cd@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6925da1b.a70a0220.d98e3.00b0.GAE@google.com Link: https://patch.msgid.link/20260123022816.2283567-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/lib/Documentation/tutorial/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions