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

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Moving cancel_work_sync() before led_classdev_unregister() in the probe error path introduces a TOCTOU race with concurrent sysfs writes, leading to a Use-After-Free.

Pre-existing issues:
- [High] Hardware events can trigger Use-After-Free in corsair_event() due to hid_hw_stop() being called after freeing driver data in corsair_remove().
- [High] TOCTOU Use-after-free in LED workers due to led_classdev_unregister() being called before cancel_work_sync() in cleanup functions.
--

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

commit 4542e75f6964d50f56a268d347abdebb867081d5
Author: Chen Changcheng [off-list ref]

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

This commit attempts to fix a use-after-free by preventing the LED worker
from being re-scheduled after it has been cancelled. It adds a removed flag
check and reorders the cleanup sequence in the probe error path.

[ ... ]

[Severity: High]
Does swapping these calls introduce a Time-of-Check to Time-of-Use race
with concurrent sysfs writes?

Since led_classdev_unregister() acts as the synchronization barrier against
sysfs writes, moving cancel_work_sync() before it might allow a concurrent
write to bypass the barrier.

Could a concurrent sysfs write evaluate led->removed as false in
k90_brightness_set(), get preempted, and then schedule the work after
cancel_work_sync() has already finished?

Sysfs thread:
k90_brightness_set()
    if (led->removed)
        return;
    <preempted>

Probe error thread:
fail_sysfs:
    k90->record_led.removed = true;
    cancel_work_sync(&k90->record_led.work);
    led_classdev_unregister(&k90->record_led.cdev);

Sysfs thread resumes:
    led->brightness = brightness;
    schedule_work(&led->work);

If the probe error thread then finishes and frees the k90 struct, wouldn't
the newly queued work execute later on freed memory?

 fail_record_led:
 	kfree(k90->record_led.cdev.name);
 fail_record_led_alloc:

This is a pre-existing issue, but looking at the commit message and the
cleanup functions:

The commit message states that a previous commit moved cancel_work_sync()
ahead of led_classdev_unregister() in k90_cleanup_backlight() and
k90_cleanup_macro_functions() to fix a use-after-free. However, looking at
those functions in the current code, led_classdev_unregister() is still
called first:

k90_cleanup_macro_functions(struct hid_device *dev) {
    ...
    led_classdev_unregister(&k90->record_led.cdev);
    cancel_work_sync(&k90->record_led.work);
    ...
}

[Severity: High]
Does calling led_classdev_unregister() before cancel_work_sync() cause a
use-after-free during driver unbind?

led_classdev_unregister() drops the refcount and frees the underlying device
struct. If a worker thread like k90_backlight_work is executing concurrently,
passes the removed check, and gets preempted, it could resume after the
device is freed:

k90_backlight_work(struct work_struct *work) {
    ...
    dev = led->cdev.dev->parent;
    ...
}


This is also a pre-existing issue, but looking at corsair_remove():

corsair_remove(struct hid_device *dev) {
    ...
    k90_cleanup_macro_functions(dev);
    k90_cleanup_backlight(dev);

    hid_hw_stop(dev);
}

[Severity: High]
Does calling hid_hw_stop() after freeing driver data allow hardware events
to trigger a use-after-free?

In k90_cleanup_macro_functions(), the k90 struct is freed via kfree(k90),
but the drvdata->k90 pointer is not set to NULL. Since hid_hw_stop() hasn't
been called yet, the HID core can still deliver incoming USB hardware events.

If an event arrives in this window before the hardware is stopped, could
corsair_event() dereference the dangling pointer?

corsair_event(...) {
    ...
    drvdata->k90->record_led.brightness = 1;
    ...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817072831.139954-1-ccc194101@163.com?part=1