Re: [PATCH 0/2] HID: corsair: fix two use-after-free bugs on device removal

[Jeffin Philip <jeffinphilip14@gmail.com>]

On Mon, 27 Jul 2026 09:35:00 +0800, Chen Changcheng wrote:

>The cleanup functions k90_cleanup_backlight() and
>k90_cleanup_macro_functions() call led_classdev_unregister() before
>cancel_work_sync():
>
>    led_classdev_unregister()     <-- may free led->cdev.dev
>    cancel_work_sync()            <-- wait for worker
>
>If the LED worker (k90_backlight_work / k90_record_led_work) is
>already running on another CPU, the following race can occur:
>
>    CPU 1 (worker)               CPU 2 (remove)
>    ---------------------         --------------------
>    if (led->removed) -> false
>    (passed the guard, about to read led->cdev.dev)
>    * preempted
>                                   removed = true
>                                   led_classdev_unregister()
>                                     -> led->cdev.dev freed
>                                   cancel_work_sync()
>                                     -> waits for worker
>    * resumes
>    dev = led->cdev.dev->parent   <-- UAF!
>
>Fix by swapping the order so that the worker is cancelled first:
>
>    cancel_work_sync()            <-- wait for worker first
>    led_classdev_unregister()     <-- then safe to unregister
>
>The removed flag is set before cancel_work_sync() so that if
>led_classdev_unregister() internally triggers another brightness
>update (which re-schedules the work), the worker will see the flag
>and return immediately.

The premise looks good, but after re-scheduling the work(possibly),
what happens when we call kfree in the cleanup function, that leads
to a ODEBUG warning as our work might be active when we try to kfree.
How can this solve the ODEBUG warning?

Reproduced here: https://syzkaller.appspot.com/bug?extid=0a031a76585d1c7e737d

Thanks,
Jeffin.