Re: [BUG] HID: steelseries-arctis: NULL deref in xhci_urb_enqueue from status timer during resume from suspend (Arctis 9) -> system hang

[Michal Pecio <michal.pecio@gmail.com>]

On Tue, 10 Nov 2026 10:34:24 +0200, Mathias Nyman wrote:
> On 11/8/26 09:35, Olli Salenius wrote:
> > The hid-steelseries-arctis driver reliably-but-intermittently freezes the
> > whole machine on resume from suspend (S3 and s2idle). The battery/status
> > polling work submits a HID control request to the Arctis 9 dongle while
> > the device is still being reset/re-enumerated by the xHCI controller after
> > resume, which oopses in xhci_urb_enqueue(). The oops happens in a context
> > that takes down the system (keyboard dead, no log reaches disk); I could
> > only capture it via efi-pstore.

This driver should stop submitting URBs to suspended devices.

> > Steps to reproduce
> > ------------------
> > 1. Arctis 9 dongle plugged in, hid-steelseries-arctis loaded.
> > 2. systemctl suspend (deep/S3; also reproduced with s2idle).
> > 3. Wake. In roughly half or more of the attempts the machine hangs: black
> >     screen (occasionally the desktop appears and then freezes), keyboard
> >     LEDs unresponsive, hard reset required.
> > 
> > Every resume on this controller logs:
> >    xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit
> >    usb usb1: root hub lost power or was reset

We are resetting the host controller, all devices will be reset-resumed,
all xhci-hcd per-device state is being freed now.

(BTW, this happening to AMD chipsets every time should be fixed soon.)

> > after which the dongle is reset/disconnected and re-enumerated, sometimes
> > with "device descriptor read/64, error -71" retries taking ~2 s. The crash
> > happens inside that window.

At this point xhci_resume() should have completed and USB core is
performing those reset-resumes. The device has been resumed and reset,
its xhci-hcd state should have been reallocated, and now it's being
enumerated again (with mixed success, apparently).

> > Oops (captured via efi_pstore)
> > ------------------------------
> > [  116.909249] PM: suspend entry (deep)
> > [  119.777239] ACPI: PM: Waking up from system sleep state S3
> > [  119.920603] xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit
> > ...
> > [  123.275980] usb 1-3.1: WARN: invalid context state for evaluate
> > context command.

This bug is unrelated and likely harmless here. But this tells us that
xhci-hcd device state may be freed and recreated a few more times.

> > [  123.300361] BUG: kernel NULL pointer dereference, address: 0000000000000020
> > [  123.300363] #PF: supervisor read access in kernel mode
> > [  123.300365] #PF: error_code(0x0000) - not-present page
> > [  123.300367] PGD 0 P4D 0
> > [  123.300369] Oops: Oops: 0000 [#1] SMP NOPTI
> > [  123.300372] CPU: 1 UID: 0 PID: 287 Comm: kworker/1:2 Not tainted
> > 7.3.1-1-cachyos #1 PREEMPT(full)
> > [  123.300375] Hardware name: ASUS System Product Name/TUF GAMING
> > B550-PLUS, BIOS 3645 09/10/2026
> > [  123.300377] Workqueue: events steelseries_status_timer_work_handler
> > [hid_steelseries_arctis]
> > [  123.300381] RIP: 0010:xhci_urb_enqueue+0x1c8/0x350
> > [  123.300386] Code: 0f 84 58 ff ff ff 48 8d bb 48 02 00 00 49 8b 44
> > 24 40 8b 88 70 05 00 00 48 8b 83 a0 03 00 00 48 8b 04 c8 48 8b 90 88
> > 12 00 00 <f6> 42 20 01 0f 85 c9 00 00 00 f6 83 d8 03 00 00 01 0f 85 f1
> > 00 00
> > [  123.300388] RSP: 0018:ffffcde6417d3cd8 EFLAGS: 00010002
> > [  123.300390] RAX: ffff89fb0b84a000 RBX: ffff89fb01eb8800 RCX: 0000000000000002
> > [  123.300391] RDX: 0000000000000000 RSI: ffff89fb015f9800 RDI: ffff89fb01eb8a48
> > [  123.300392] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffb8810860
> > [  123.300394] R10: 0000000000000001 R11: ffffffffb6e6a730 R12: ffff89fcb89bc780
> > [  123.300395] R13: ffff89fb01eb8800 R14: ffff89fd2854ee00 R15: 00000000ffffff94
> > [  123.300399] CR2: 0000000000000020 CR3: 00000002d7e75000 CR4: 0000000000f50ef0
> > [  123.300401] Call Trace:
> > [  123.300402]  <TASK>
> > [  123.300405]  usb_hcd_submit_urb+0x91/0x190
> > [  123.300408]  usb_start_wait_urb+0x8f/0x1d0
> > [  123.300412]  usb_control_msg+0xdd/0x150

Offending URB is submitted to ep0, which generally "always exists".

> xhci should not crash even if something is misbehaving and sending
> URBs during resume. The timer should also be fixed, but I'm now only
> looking at the xhci side
> 
> There are some pending xhci fixes in this area. Michal just posted a
> patch that touches the "WARN: invalid context state for evaluate
> context command" case in your log.
> 
> I added another patch for the NULL pointer deref.
> 
> All relevant patches for this case are now in a test branch named
> "fix_null_deref_reset_resume" in my tree. (based on Greg's usb-linus
> branch)
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git fix_null_deref_reset_resume
> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=fix_null_deref_reset_resume

The log looks like core switched to "old scheme" enumeration after
getting a few -EPROTO on "new scheme" attempts to read the device
descriptor (maybe device isn't ready yet).

If core were submitting URBs concurrently with xhci_resume() we would
probably know about it already. Core should have called reset_device(),
which allocates a slot and recreates vdev. This should exist now.

Hard to tell why urb_enqueue() crashes here without debug info and
line numbers, but I would guess it's something like:

1. It crashes if URBs are submitted after reset_device() but before
   enable_device() or address_device(). That normally doesn't happen.
2. The HID driver submits URB concurrently with xhci_setup_deice()
   which frees vdev, possibly after the NULL check in urb_enqueue().

If 2 is possible it may be tricky to protect from.

Regards,
Michal