Re: [PATCH v3 2/2] HID: logitech-hidpp: enable reprogrammable buttons on Signature M650

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

Pre-existing issues:
- [High] Missing cancellation of `reset_hi_res_work` in `hidpp_probe()` error path.
--

--- Patch [2]: [PATCH v3 2/2] HID: logitech-hidpp: enable reprogrammable buttons on Signature M650 ---

commit 21d2c84d622f6c1b7cd8dfbe446bc728f3b8bf10
Author: Elliot Douglas [off-list ref]

HID: logitech-hidpp: enable reprogrammable buttons on Signature M650

This patch enables reprogrammable buttons on the Signature M650 mouse over
Bluetooth. It handles the short click-like events emitted for side buttons
by using HID++ REPROG_CONTROLS_V4 diversion to provide real press and
release timing. The diverted controls are reported as BTN_BACK and
BTN_FORWARD.

Link: https://support.logi.com/hc/en-nz/articles/4414473810583-Getting-Started-Signature-M650

[ ... ]

[ ... ]

While reviewing this file, I noticed a pre-existing issue in hidpp_probe():

hid_hw_start_fail:
	sysfs_remove_group(&hdev->dev.kobj, &ps_attribute_group);
	cancel_work_sync(&hidpp->work);
	mutex_destroy(&hidpp->send_mutex);
	return ret;

[Severity: High]
This is a pre-existing issue, but does this error path need to cancel
reset_hi_res_work?

During hidpp_probe(), hid_device_io_start() is called, which enables
incoming packets. If a device with the HIDPP_QUIRK_RESET_HI_RES_SCROLL
quirk sends a battery event before the probe finishes, the event handler
can call:

    schedule_work(&hidpp->reset_hi_res_work);

If a subsequent operation fails and the code branches to hid_hw_start_fail,
it cancels hidpp->work but does not cancel hidpp->reset_hi_res_work.

Since devres automatically frees the hidpp_device struct when probe()
returns, can this pending work item execute hidpp_reset_hi_res_handler()
and cause a use-after-free when it dereferences the freed memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812195842.77724-1-edouglas7358@gmail.com?part=2