From: sashiko-bot@kernel.org
To: "Guenter Roeck" <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH v2 1/4] hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop
Date: Wed, 08 Jul 2026 03:16:12 +0000 [thread overview]
Message-ID: <20260708031612.BD7E61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260708030507.227193-2-linux@roeck-us.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing cleanup of debugfs files in probe error path leads to a Use-After-Free vulnerability.
--
--- Patch [1]: [PATCH v2 1/4] hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop ---
commit 93ea292134a6e9bcca068675cf1869020bdac096
Author: Guenter Roeck <linux@roeck-us.net>
hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop
This commit fixes a UAF vulnerability caused by a race condition between
hid_input_report() and driver probe failure by calling hid_device_io_stop()
before hid_hw_stop().
> diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
> index b6e508e43fa17..8354a002f4c5e 100644
> --- a/drivers/hwmon/corsair-cpro.c
> +++ b/drivers/hwmon/corsair-cpro.c
> @@ -645,6 +645,7 @@ static int ccp_probe(struct hid_device *hdev, const struct hid_device_id *id)
>
> out_hw_close:
> hid_hw_close(hdev);
> + hid_device_io_stop(hdev);
[Severity: High]
This is a pre-existing issue, but does this error path also need to clean up
the debugfs files?
In ccp_probe(), the debugfs files are created just before registering the
hwmon device:
ccp_debugfs_init(ccp);
ccp->hwmon_dev = hwmon_device_register_with_info(&hdev->dev, ...
if (IS_ERR(ccp->hwmon_dev)) {
ret = PTR_ERR(ccp->hwmon_dev);
goto out_hw_close;
}
If hwmon_device_register_with_info() fails, we jump here to out_hw_close, but
we don't remove the newly created ccp->debugfs.
Since devres automatically frees the ccp structure when the probe function
returns, this leaves dangling files in debugfs.
If a user-space process later reads these leaked files, won't callback
functions like firmware_show() dereference the freed ccp pointer and cause
a Use-After-Free?
> out_hw_stop:
> hid_hw_stop(hdev);
> return ret;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708030507.227193-1-linux@roeck-us.net?part=1
next prev parent reply other threads:[~2026-07-08 3:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 3:05 [PATCH v2 0/4] Fix error handling in HID device probe functions Guenter Roeck
2026-07-08 3:05 ` [PATCH v2 1/4] hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Guenter Roeck
2026-07-08 3:16 ` sashiko-bot [this message]
2026-07-08 3:05 ` [PATCH v2 2/4] hwmon: (gigabyte_waterforce) " Guenter Roeck
2026-07-08 3:19 ` sashiko-bot
2026-07-08 3:05 ` [PATCH v2 3/4] hwmon: (nzxt-smart2) " Guenter Roeck
2026-07-08 3:27 ` sashiko-bot
2026-07-08 3:05 ` [PATCH v2 4/4] hwmon: (nzxt-kraken3) " Guenter Roeck
2026-07-08 3:27 ` sashiko-bot
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=20260708031612.BD7E61F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.net \
--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