On Thu, Jan 23, 2025, syzbot wrote: > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:94 [inline] > dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 > lockdep_rcu_suspicious+0x226/0x340 kernel/locking/lockdep.c:6845 > __kvm_memslots include/linux/kvm_host.h:1036 [inline] > kvm_vcpu_memslots include/linux/kvm_host.h:1050 [inline] > kvm_vcpu_gfn_to_memslot+0x429/0x4c0 virt/kvm/kvm_main.c:2554 > kvm_vcpu_write_guest_page virt/kvm/kvm_main.c:3238 [inline] > kvm_vcpu_write_guest+0x7c/0x130 virt/kvm/kvm_main.c:3274 > kvm_xen_write_hypercall_page+0x2ff/0x5f0 arch/x86/kvm/xen.c:1299 > kvm_set_msr_common+0x150/0x3da0 arch/x86/kvm/x86.c:3751 > vmx_set_msr+0x15da/0x2790 arch/x86/kvm/vmx/vmx.c:2487 > __kvm_set_msr arch/x86/kvm/x86.c:1877 [inline] The Xen hypercall page MSR is configured to be MSR_IA32_XSS, which results in KVM's write of XSS during vCPU creation to do bad things. I'll post a path to restrict the Xen MSR to the unofficial virtualization-defined range, and cross my fingers that doing so won't break userspace. There are myriad things that can go wrong if KVM effectively lets userspace redirect any MSR write. > kvm_vcpu_reset+0xbea/0x1740 arch/x86/kvm/x86.c:12456 > kvm_arch_vcpu_create+0x8dc/0xa80 arch/x86/kvm/x86.c:12305 > kvm_vm_ioctl_create_vcpu+0x3d6/0xa00 virt/kvm/kvm_main.c:4106 > kvm_vm_ioctl+0x7e2/0xd30 virt/kvm/kvm_main.c:5019 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:906 [inline] > __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f
