Re: [PATCH v2] HID: logitech-headset: add a battery driver for the PRO X 2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver cancels its delayed workqueue before calling hid_hw_stop(), which violates the mandatory HID subsystem cleanup order.
--

commit bd334ae3e07d607cf268d197e4923d3fe7f27cad
Author: Méven Car <meven29@gmail.com>

HID: logitech-headset: add a battery driver for the PRO X 2
    
This commit introduces a battery driver for the Logitech PRO X 2 LIGHTSPEED
headset. The device reports its battery status over a vendor collection
rather than HID++, so a custom driver is implemented to poll and parse these
reports.

> diff --git a/drivers/hid/hid-logitech-headset.c b/drivers/hid/hid-logitech-headset.c
> new file mode 100644
> index 0000000000000..9081ddf5f42f2
> --- /dev/null
> +++ b/drivers/hid/hid-logitech-headset.c
[ ... ]
> +static void logi_headset_remove(struct hid_device *hdev)
> +{
> +	struct logi_headset *headset = hid_get_drvdata(hdev);
> +
> +	cancel_delayed_work_sync(&headset->poll);
> +	hid_hw_close(hdev);
> +	hid_hw_stop(hdev);

[Severity: High]
Could this teardown sequence in logi_headset_remove() lead to a
use-after-free?

In drivers/hid/hid-logitech-headset.c:logi_headset_remove(), the delayed work
is cancelled before hid_hw_stop() is called. When a device is unplugged or
unbound, cancelling workers before stopping the hardware (which unregisters
the device interfaces) means that hardware events or userspace interactions
could theoretically queue new work after the cancellation.

Since devres automatically frees the driver's private data after remove()
returns, any lingering work executing subsequently would access freed memory.
Calling hid_hw_stop() before cancelling the work would ensure no new work can
be queued.

> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911120208.21698-1-meven@kde.org?part=1