From: sashiko-bot@kernel.org
To: DevExalt <exalt.dev.team@gmail.com>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH v8] HID: logitech-hidpp: Add support for HID++ Multi-Platform feature (0x4531)
Date: Wed, 26 Aug 2026 08:08:06 +0000 [thread overview]
Message-ID: <20260826080806.E2CFB1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260826075758.47287-1-exalt.dev.team@gmail.com>
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 the `hidpp_probe` error path, leading to a potential Use-After-Free.
--
commit 452cf6e851cc2adb7ff83d84efb83964e63b45a1
Author: Baraa Atta (Dev Exalt) <exalt.dev.team@gmail.com>
HID: logitech-hidpp: Add support for HID++ Multi-Platform feature (0x4531)
This commit adds support for the HID++ Multi-Platform feature, introducing a
per-device sysfs attribute to allow selecting the target platform. It detects
the feature, validates requests, and alters device behavior accordingly.
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index 90b0184df777f..1cb78096f31c5 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
[ ... ]
> @@ -4557,6 +5154,7 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id)
> hid_hw_open_fail:
> hid_hw_stop(hdev);
> hid_hw_start_fail:
> + hidpp_multiplatform_cleanup(hidpp);
> 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 I noticed a potential use-after-free
vulnerability in this error path.
Could this leave a pending work item running on freed memory if a device
sends a raw hardware event during the probe sequence?
The reset_hi_res_work is initialized earlier in hidpp_probe() and
could be scheduled immediately after hid_device_io_start() is called.
If a subsequent initialization step like hid_connect() fails, we end up
in this error path which cancels hidpp->work, but skips canceling
hidpp->reset_hi_res_work.
The core devres mechanism will then free the hidpp structure, potentially
allowing the pending work to execute on freed memory.
Should cancel_work_sync(&hidpp->reset_hi_res_work); be added to this
cleanup path, similarly to how it is correctly handled in hidpp_remove()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260826075758.47287-1-exalt.dev.team@gmail.com?part=1
next prev parent reply other threads:[~2026-08-26 8:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 8:08 [PATCH v2] HID: logitech-hidpp: Add support for HID++ Multi-Platform feature (0x4531) DevExalt
2026-06-25 8:18 ` sashiko-bot
2026-06-30 9:48 ` [PATCH v3] " DevExalt
2026-06-30 10:13 ` sashiko-bot
2026-07-01 6:30 ` [PATCH v4] " DevExalt
2026-07-01 6:43 ` sashiko-bot
2026-07-01 7:37 ` [PATCH v5] " DevExalt
2026-07-15 14:01 ` dev exalt
2026-07-27 14:04 ` Bastien Nocera
2026-07-29 15:02 ` Bastien Nocera
2026-08-02 11:50 ` [PATCH v6] " DevExalt
2026-08-02 11:58 ` sashiko-bot
2026-08-02 12:01 ` [PATCH v7] " DevExalt
2026-08-26 7:57 ` [PATCH v8] " DevExalt
2026-08-26 8:08 ` sashiko-bot [this message]
2026-09-13 4:46 ` [PATCH v9] " DevExalt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260826080806.E2CFB1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=exalt.dev.team@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox