Re: [PATCH 0/2] HID: corsair: fix two use-after-free bugs on device removal
Jeffin Philip <[email protected]>
| Newsgroups | org.kernel.vger.linux-input,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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.