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

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

[Olli Salenius]

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.

Workaround
----------
  echo 'blacklist hid_steelseries_arctis' >
/etc/modprobe.d/no-steelseries-hid.conf
Several suspend/resume cycles since then have been clean.

I'm happy to test patches.

Resending in plain text
Apologies for the spam.

Thanks,
Olli

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]

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

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

[Michal Pecio]

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

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

[Olli Salenius]

Hi Mathias, Michal,

Disclaimer, I am not well versed kernel level stuff and using Claude
Opus 5.5 in debugging this issue, so the following info may not be
accurate, however the patch did seem to fix the hang at least on a few
test suspend/resume -cycles.

Thanks for the quick patches and the analysis.

Michal wrote:
> Hard to tell why urb_enqueue() crashes here without debug info and
> line numbers

I got the matching debug vmlinux for the crashing kernel
(linux-cachyos-dbg 7.3.1-1, build ID 86590b412f55... matches the oops)
and resolved the RIP:

  xhci_urb_enqueue+0x1c8/0x350 -> drivers/usb/host/xhci.c:1668 (v7.3.1)

    if (xhci->devs[slot_id]->rhub_port->link_inactive) {

  ; xhci.c:1668
  mov  0x3a0(%rbx),%rax
  mov  (%rax,%rcx,8),%rax      ; xhci->devs[slot_id], slot_id = RCX = 2
  mov  0x1288(%rax),%rdx       ; ->rhub_port, RDX = 0
  testb $0x1,0x20(%rdx)        ; ->link_inactive  <-- fault, CR2 = 0x20

So the virt device exists and xhci_check_args() passed, but its
rhub_port is still NULL. As far as I can tell rhub_port is only set
in xhci_setup_addressable_virt_dev(), so this looks like Michal's
case 1: the URB arrives after the virt device was (re)allocated, e.g.
via xhci_discover_or_reset_device() -> xhci_alloc_dev() after the
Reinit, but before address_device() set it up. Since the host isn't
halted at that point, I don't think the XHCI_STATE_HALTED check in
e44fcfdabcd2 would catch it; the same dereference is still at
xhci.c:1688 on the test branch.

The fault also happens under spin_lock_irqsave(&xhci->lock) (EFLAGS
0x10002, IF clear), which would explain why the whole machine froze
instead of just USB dying.

Testing the branch
------------------
I tested fix_null_deref_reset_resume (e44fcfdabcd2) with
hid-steelseries-arctis loaded and bound to the Arctis 9 (1038:12c2).
4 S3 suspend/resume cycles so far: no hang, no oops, no "invalid
context state" warning.

However, the controller reset no longer happens on this branch. On
7.3.1 every resume logged:

  xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit
  usb usb1: root hub lost power or was reset

On the test branch this is gone and only the individual devices are
reset. My controller is the AMD 500 series chipset xHCI (1022:43ee),
so I suspect 555040535 ("usb: pci-quirks: always assert xHCI OS
ownership"), which is in the usb-linus base, fixes the restore error
here too, as Michal mentioned. So the crash path wasn't exercised in
my testing.

If it helps, I can rebuild with 555040535 reverted so the Reinit path
is active, and test any patch for the rhub_port case. I'm away for a
couple of days, so I can test again from Friday on.

Thanks,
Olli


On Tue, Nov 10, 2026 at 11:57 AM Michal Pecio <michal.pecio@gmail.com> wrote:
>
> 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

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

[Michal Pecio]

On Tue, 10 Nov 2026 22:46:27 +0200, Olli Salenius wrote:
> Disclaimer, I am not well versed kernel level stuff and using Claude
> Opus 5.5 in debugging this issue, so the following info may not be
> accurate, however the patch did seem to fix the hang at least on a few
> test suspend/resume -cycles.

Your LLM is right. The test patch makes no difference, but commit
555040535 removed the trigger. If you revert 555040535, the crash
will be back.

It happens because xhci_reset_or_discover_device() allocates new
state for the device, but it doesn't bother to update the root hub
pointer, leaving this job to xhci_setup_device().

To fix the crash we need either the dumb patch below or some rework
to preserve more state during resets. Probably the dumb fix is the
only viable short-term option.

It doesn't solve my problem #2, but that one is a race condition,
so much less likely to actually happen in practice.

Regards,
Michal

---

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e5c8b3a945a6..81656bfdaf66 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1662,6 +1662,11 @@ static int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flag
 		goto free_priv;
 	}
 
+	if (!xhci->devs[slot_id]->rhub_port) {
+		ret = -EHOSTUNREACH;
+		goto free_priv;
+	}
 	if (xhci->devs[slot_id]->rhub_port->link_inactive) {
 		xhci_dbg(xhci, "Can't queue urb, port error, link inactive\n");
 		ret = -ENODEV;