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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.