Thread (14 messages) 14 messages, 5 authors, 2026-08-31

[PATCH] HID: corsair: do not re-schedule LED worker after it has been cancelled

COLD32d

From: Jeffin Philip <hidden>
Date: 2026-08-31 05:50:23
Also in: lkml

On Mon, 17 Aug 2026 15:28:31 +0800, Chen Changcheng wrote:
Commit eb51c9f8cb4f0 ("HID: corsair: cancel worker before unregistering
LED to fix use-after-free") moved cancel_work_sync() ahead of
led_classdev_unregister() in k90_cleanup_backlight() and
k90_cleanup_macro_functions().  led_classdev_unregister() internally
calls led_set_brightness(LED_OFF), which reaches the driver's
k90_brightness_set() callback.  Since that callback schedules the worker
unconditionally, the worker was re-queued after cancel_work_sync() had
drained it, and the subsequent kfree() freed a still-active work_struct:

   ODEBUG: free active (active state 0) object type: work_struct
           hint: k90_record_led_work

The removed flag check inside the worker itself only stops it from
dereferencing freed memory once it runs; it cannot prevent the re-queue.

Fix this by making k90_brightness_set() a no-op once removed is set, so
the LED_OFF update issued from led_classdev_unregister() can no longer
re-schedule the worker after it has been cancelled.  Also apply the
cancel-before-unregister ordering to the probe error path
(k90_init_macro_functions() fail_sysfs) for consistency.
This UAF[1] can be prevented by your patch, would you consider adding that too
in your patch?

[1]: https://lore.kernel.org/all/6a937393.1d9ded08.62e62.0113.GAE@google.com/#R (local)

Thanks,
Jeffin.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help