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

[Mathias Nyman <mathias.nyman@linux.intel.com>]

Hi

On 11/8/26 09:35, Olli Salenius wrote:
> Hi,
> 
> 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.
> 
> Blacklisting hid_steelseries_arctis fixes the hang completely.
> 
> Environment
> -----------
> Kernel:   7.3.1-1-cachyos (CachyOS build, x86_64, PREEMPT(full))
> Board:    ASUS TUF GAMING B550-PLUS, BIOS 3645 09/10/2026
> CPU/GPU:  AMD Ryzen 7 5800X3D, AMD Radeon RX 9070 (Navi 48)
> Headset:  SteelSeries Arctis 9 wireless
>            1038:12c2 (HID interface, bcdDevice 1.01) -> bound to
>                       hid-steelseries-arctis
>            1038:12c4 (audio + HID, bcdDevice 0.03)  -> snd-usb-audio
>            both behind an Alcor Micro hub (058f:9254), on the AMD 500
>            series chipset xHCI controller (0000:02:00.0, 1022:43ee)
> 
> 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
> 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.
> 
> 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.
> [  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
> [  123.300415]  usbhid_raw_request+0x11e/0x140
> [  123.300419]  steelseries_arctis_9_request_status+0x63/0xb0
> [hid_steelseries_arctis]
> [  123.300422]  steelseries_status_timer_work_handler+0x21/0x70
> [hid_steelseries_arctis]
> [  123.300424]  process_scheduled_works+0x21f/0x650
> [  123.300428]  worker_thread+0x193/0x3b0
> [  123.300432]  kthread+0xfd/0x130
> [  123.300436]  ret_from_fork+0xec/0x2b0
> [  123.300441]  ret_from_fork_asm+0x1a/0x30
> [  123.300446]  </TASK>
> [  123.300527] CR2: 0000000000000020
> [  123.300532] WARNING: kernel/printk/printk.c:4631 at
> wake_up_klogd+0x64/0x80, CPU#1: kworker/1:2/287
>                 (console_irqwork_blocked)
> 
> Analysis
> --------
> The status timer/work keeps running across system suspend/resume and
> fires while the USB device is being reset after the xHC "Reinit". The
> control request then reaches xhci_urb_enqueue() for a device whose
> endpoint state has not been rebuilt yet (NULL at offset 0x20).
> 
> Looking at drivers/hid/hid-steelseries-arctis.c (new in v7.3; unchanged
> in current master, hid.git for-next and linux-next), the driver has no
> .suspend/.resume/.reset_resume callbacks:
> 
>    static struct hid_driver steelseries_arctis_driver = {
>            .name = "hid-steelseries-arctis",
>            .id_table = steelseries_arctis_devices,
>            .probe = steelseries_arctis_probe,
>            .remove = steelseries_arctis_remove,
>            .raw_event = steelseries_arctis_raw_event,
>    };
> 
> and steelseries_status_timer_work_handler() unconditionally re-arms
> status_work (for non-async devices such as the Arctis 9); it is only
> cancelled in remove. So the poll keeps firing across system sleep.
> 
> Suggested fix: cancel_delayed_work_sync(&sd->status_work) in a .suspend
> callback, and re-schedule it from .resume and .reset_resume. Separately,
> it may be worth a look from the USB side whether xhci_urb_enqueue()
> should reject rather than dereference in this state.
> 
> Possibly related: on the 6.18 LTS kernel, where the Arctis 9 (1038:12c2)
> is handled by hid-steelseries instead, I also saw identical resume hangs,
> but I did not capture a trace there.
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

Much appreciated if you can give that a try

Thanks
Mathias