CVE-2026-89625: HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind

Published Sep 11, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

HID: sony: fix UAF of ghlpoketimer / ghlurb at driver unbind

For GHL (Guitar Hero Live) dongles, sonyprobe() arms a periodic timer: ghlmagicpoke() (the timer callback) submits sc->ghlurb, and the URB completion ghlmagicpokecb() re-arms the timer with modtimer().

sonyremove() drained the timer with timerdeletesync() and then freed the URB with usbfreeurb():

timerdeletesync(&sc->ghlpoketimer); usbfreeurb(sc->ghlurb);

timerdeletesync() does not block re-arming, and while the URB is in flight the timer is not pending, so the sync delete is a no-op. A URB completion that runs after the delete re-arms the timer, and usbfreeurb() only drops a reference -- it does not kill an in-flight URB. sc is allocated with devmkzalloc() and freed once sonyremove() returns, so the re-armed ghlpoketimer (embedded in sc) then fires on freed memory, a use-after-free from timer softirq. This is a disconnect/rmmod race.

Poison the URB first, then shut the timer down, before freeing the URB. usbpoisonurb() kills any in-flight URB and permanently rejects further submissions, so a poke timer that is still pending cannot re-submit the URB from ghlmagicpoke() in the window before timershutdownsync() runs. usbkillurb() would not suffice: it only cancels the in-flight URB and leaves it submittable once it returns, so the pending timer could re-submit it and put a fresh URB in flight over the freed sc. timershutdownsync() then drains any last callback and blocks re-arming. The probe error path is unaffected: it is only reached before the timer is armed.

Reproduced under KASAN on next-20260710 via dummyhcd + raw-gadget emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds and arms the poke timer, the poke URB is held in flight, the driver is unbound (freeing sc), then the URB is released. The completion re-arms the timer on the freed sc, and the re-armed timer fires ~8 s later:

BUG: KASAN: slab-use-after-free in ghlmagicpoke+0x98/0xb0 Read of size 8 at addr ffff88810b02fd50 by task swapper/0/0 ghlmagicpoke+0x98/0xb0 calltimerfn+0x35/0x2b0 runtimers+0x69c/0x9a0 runtimersoftirq+0x173/0x2a0 Allocated by task 169: sonyprobe Freed by task 338: devresreleasegroup <- hiddeviceremove (sonyremove)

Found by 0sec (https://0sec.ai) using automated source analysis.

Affected Software

1 affected component
Linux kernel HID sony driver (Guitar Hero Live dongles)

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Patch HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind
  2. Compensating control

    For the affected HID sony driver (GHL Guitar Hero Live dongles emulation), avoid performing disconnect/rmmod operations concurrently with device activity; ensure the driver is fully unbound/drained before removing the module or device to prevent the disconnect/rmmod race where the poke timer can re-arm after unbind.

Event History

Sep 11, 2026
CVE Published
via MITRE·07:45 PM
Data Sourced
via MITRE·07:45 PM
Description

Frequently Asked Questions

1

Which systems are exposed to this issue?

Systems using the Linux kernel HID Sony driver with a Guitar Hero Live dongle are exposed. The affected path is specific to GHL dongles, which use the periodic poke timer and associated USB request.

2

What event is required to trigger the use-after-free?

The issue requires a race between driver unbind, such as device disconnect or module removal, and completion of an in-flight USB request. The completion can re-arm the timer after removal has attempted to delete it, allowing the timer to run after its containing driver state has been freed.

3

What mitigation is available if an updated kernel cannot be deployed immediately?

Avoid disconnecting the Guitar Hero Live dongle or removing the relevant driver while the dongle is in use. This reduces exposure to the described disconnect/rmmod race, though the data does not provide a complete workaround.

4

How does the fix prevent the race?

The fix poisons the USB request before shutting down the timer and freeing the request. Poisoning kills in-flight requests and permanently rejects further submissions, preventing a completion handler from re-arming the timer during driver removal.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203