[Bug]: Guru Meditation triggered by USB HID passthrough traffic on AMD host

[torrmercury]

Version

trunk/main

Host OS Type

Linux

Host OS name + version

CachyOS (kernel: 7.2.6-1-cachyos) using VB version 7.2.18 r175117

Host Architecture

x86

Guest OS Type

Windows

Guest Architecture

x86

Guest OS name + version

Win 11 25H2 fresh install

Component

VMM

What happened?

A VM reproducibly dies with a Guru Meditation within seconds of the guest generating sustained USB control-transfer traffic to passed-through USB HID devices.

Two assertion signatures appear, both preceded in every case by the same VMMR0EmtPrepareToBlock warning:

VMMR0EmtPrepareToBlock: Preemption is disabled! pvLock=ffffcf5c942a3040 pszCaller=pdmCritSectEnter rcBusy=0000000000000000
!!R0-Assertion Failed!!
Expression: pCritSect->s.Core.NativeThreadOwner == hNativeSelf && hNativeSelf != (~(RTNATIVETHREAD)0)
Location  : VirtualBox-7.2.18/src/VBox/VMM/VMMAll/PDMAllCritSect.cpp(827) int PDMCritSectLeave(PVMCC, PPDMCRITSECT)
ffffcf5c942a3040 <R3_STRING>: ffffffffffffffff != 00007ff3394fe6c0; cLockers=-1 cNestings=1

VMMR0EmtPrepareToBlock: Preemption is disabled! pvLock=ffffcf5c93d47040 pszCaller=pdmCritSectEnter rcBusy=0000000000000000
!!R0-Assertion Failed!!
Expression: RT_SUCCESS(rc)
Location  : VirtualBox-7.2.18/src/VBox/VMM/VMMAll/PGMAll.cpp(3908) int pgmLock(PVMCC, bool)
pVM=ffffcf5c93c2e000 pCritSect=ffffcf5c93d47040: -2720

Resulting in VCPU<n>: Guru Meditation -2701 (VERR_VMM_RING0_ASSERTION).

The VMMR0EmtPrepareToBlock: Preemption is disabled! ... pszCaller=pdmCritSectEnter rcBusy=0 line appears immediately before every occurrence, on both execution backends (see below). An EMT is attempting to enter a contended critical section in a preemption-disabled context with no busy-return path available; the acquire fails with -2720 and the critical section's owner bookkeeping is left inconsistent, which is what the PDMCritSectLeave assertion then trips on.

Host kernel log consistently shows a burst of USB resets on the passed-through devices in the seconds immediately preceding each crash:

[16:07:43] usb 1-5.3: reset full-speed USB device number 11 using xhci_hcd
[16:07:43] usb 3-5:   reset full-speed USB device number 3 using xhci_hcd
[16:07:44] usb 1-5.3: reset full-speed USB device number 11 using xhci_hcd
[16:07:44] usb 3-5:   reset full-speed USB device number 3 using xhci_hcd
[16:07:48] usb 1-5.3: reset full-speed USB device number 11 using xhci_hcd
[16:07:48] usb 1-5.3: reset full-speed USB device number 11 using xhci_hcd
[16:07:49] usb 3-5:   reset full-speed USB device number 3 using xhci_hcd
[16:07:49] usb 3-5:   reset full-speed USB device number 3 using xhci_hcd
[16:08:04] VMMR0EmtPrepareToBlock: Preemption is disabled! ... pszCaller=pdmCritSectEnter rcBusy=0
[16:08:04] !!R0-Assertion Failed!! (PDMCritSectLeave)

The two devices are both full-speed (USB 1.1) HID:

• 0CF2:A100 ENE LianLi-UNI FAN-SL-v1.8 (Lian Li Uni Fan controller)
• 0B05:18F3 AsusTek AURA LED Controller

Secondary observation: KVM API path active on AMD host

With kvm_amd loaded, vboxdrv logs opened /dev/kvm on this AMD host. The 7.2.18 changelog annotates the KVM-API VT-x acquisition work as "Intel KVM only", so this may be unintended. It is not the cause of the crash above — the crash reproduces identically with kvm_amd unloaded, where the log instead reads vboxdrv: /dev/kvm not found (ENODEV) — but flagging it in case the AMD host reaching that path is itself a bug.

How can we reproduce this?

1. Host: AMD Ryzen (Zen 3), Linux kernel 7.2.x, VirtualBox 7.2.18.
2. Create a Windows 11 VM: EFI enabled, TPM 2.0, Secure Boot on, 4 vCPU, 8192 MB RAM, VirtIO... (SATA AHCI storage, VMSVGA, NAT), USB 2.0 (EHCI) + USB 3.0 (xHCI) controllers enabled.
3. Add USB device filters for a Lian Li Uni Hub and an ASUS AURA LED controller (both full-speed HID).
4. Install Windows 11, then install Lian Li L-Connect 3.
5. Start the VM. L-Connect 3 launches at startup and begins polling both controllers.
6. VM dies with Guru Meditation within seconds of L-Connect3 starting up (which is set to run on start up) — reliably, on every boot.

Already ruled out

These were each tested individually; the crash reproduces unchanged with every one of them:

• --paravirtprovider set to kvm, none, and default
• vCPU count reduced from 4 to 2
• --nestedpaging off
• USB device filters removed entirely
• kvm_amd/kvm unloaded so vboxdrv uses the native SVM path (/dev/kvm not found (ENODEV) confirmed in log)
• kvm.enable_virt_at_load=0 — no effect on whether vboxdrv opens /dev/kvm
• VBoxInternal/RamPreAlloc=1 — removes GMMR0AllocateHandyPages from the contention picture; crash unchanged
• Completely fresh Windows 11 install (crash returned immediately on reinstalling L-Connect 3)
• DKMS module confirmed built against the running kernel (modinfo vboxdrv vermagic matches uname -r)
• USB controllers set to OHCI only (--usbxhci off --usbehci off) — crash unchanged. Since the devices are full-speed and reproduce identically across OHCI, EHCI and xHCI, the fault does not appear to be specific to any one controller emulation, which would point below them at the shared VUSB/PDM layer.

VBlog-2026-09-17-16-14-04.log

dmesg.log

Did you upload all of your necessary log files, screenshots, etc.?

• Yes, I've uploaded all pertinent files to this issue.