Re: [PATCH v3 1/8] HID: asus: mitigate possible use-after-free

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing initialization of `fn_lock_sync_work` leading to `WARN_ON` in `cancel_work_sync()`.
--

commit 317502709e07b71f7cfc9f30cf392aa744d4f88d
Author: Denis Benato <denis.benato@linux.dev>

HID: asus: mitigate possible use-after-free

The kbd_backlight pointer is not being set to NULL after being freed in
asus_kbd_register_leds and other portions of the driver checks that field,
therefore set the pointer to NULL after being freed.

Link: https://lore.kernel.org/all/20260612130125.AAAE71F000E9@smtp.kernel.org/

> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..c2a5edebbd7a7 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -777,6 +777,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
>  	if (ret < 0) {
>  		/* No need to have this still around */
>  		devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> +		drvdata->kbd_backlight = NULL;
>  	}
>  
>  	return ret;

[Severity: High]
This is a pre-existing issue, but since the patch touches driver teardown
safety, does the current teardown logic in asus_remove() safely handle
uninitialized work structs?

In drivers/hid/hid-asus.c:asus_input_configured(), the work struct is
conditionally initialized:

    if (drvdata->quirks & QUIRK_HID_FN_LOCK) {
        drvdata->fn_lock = true;
        INIT_WORK(&drvdata->fn_lock_sync_work, asus_sync_fn_lock);
        asus_kbd_set_fn_lock(hdev, true);
    }

However, for some devices (like those with QUIRK_ROG_NKEY_KEYBOARD and
QUIRK_HID_FN_LOCK quirks), the HID core might skip input checks if the
device does not have inputs. If asus_input_configured() is never called,
fn_lock_sync_work remains zero-initialized.

When the device is unbound, drivers/hid/hid-asus.c:asus_remove() calls:

    if (drvdata->quirks & QUIRK_HID_FN_LOCK)
        cancel_work_sync(&drvdata->fn_lock_sync_work);

Can this trigger a WARN_ON(!work->func) in __flush_work() if
cancel_work_sync() is called on the zero-initialized work struct,
potentially causing a panic on systems with panic_on_warn=1?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260613153029.2559774-1-denis.benato@linux.dev?part=1