From: sashiko-bot@kernel.org
To: "Wilken Gottwalt" <wilken.gottwalt@posteo.net>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH] hwmon: corsair-psu: fix possible out-of-bounds access on missing string termination
Date: Wed, 05 Aug 2026 07:30:33 +0000 [thread overview]
Message-ID: <20260805073034.C71C01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <anLj9gPWRoRDbQBV@monster.localdomain>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Data race on shared `priv->cmd_buffer` and `priv->wait_completion` due to missing driver-level locking for debugfs attributes.
--
--- Patch [1]: [PATCH] hwmon: corsair-psu: fix possible out-of-bounds access on missing string termination ---
commit cfc2e894e816ca1d7330d9074123e16e3ad443b7
Author: Wilken Gottwalt <wilken.gottwalt@posteo.net>
hwmon: corsair-psu: fix possible out-of-bounds access on missing string termination
This commit limits the debugfs seq_printf() calls for vendor and product
strings to a maximum length of REPLY_SIZE. This prevents potential
out-of-bounds accesses if the strings are not properly null-terminated by
the hardware.
> diff --git a/drivers/hwmon/corsair-psu.c b/drivers/hwmon/corsair-psu.c
> index ce958cdaef58a..3c01ae3fc4af2 100644
> --- a/drivers/hwmon/corsair-psu.c
> +++ b/drivers/hwmon/corsair-psu.c
> @@ -701,7 +701,7 @@ static int vendor_show(struct seq_file *seqf, void *unused)
> {
> struct corsairpsu_data *priv = seqf->private;
>
> - seq_printf(seqf, "%s\n", priv->vendor);
> + seq_printf(seqf, "%.*s\n", REPLY_SIZE, priv->vendor);
>
> return 0;
> }
> @@ -711,7 +711,7 @@ static int product_show(struct seq_file *seqf, void *unused)
> {
> struct corsairpsu_data *priv = seqf->private;
>
> - seq_printf(seqf, "%s\n", priv->product);
> + seq_printf(seqf, "%.*s\n", REPLY_SIZE, priv->product);
>
> return 0;
> }
[Severity: High]
This is a pre-existing issue, but does the lack of driver-level locking
cause a data race on priv->cmd_buffer and priv->wait_completion when debugfs
attributes are read concurrently with sysfs attributes?
Looking at print_uptime(), it calls into corsairpsu_get_value() bypassing
the hwmon core sysfs locks:
drivers/hwmon/corsair-psu.c:print_uptime() {
...
ret = corsairpsu_get_value(priv, cmd, 0, &val);
...
}
This proceeds into corsairpsu_usb_cmd() where the shared buffer and
completion are mutated without any synchronization lock:
drivers/hwmon/corsair-psu.c:corsairpsu_usb_cmd() {
...
memset(priv->cmd_buffer, 0, CMD_BUFFER_SIZE);
priv->cmd_buffer[0] = p0;
priv->cmd_buffer[1] = p1;
priv->cmd_buffer[2] = p2;
reinit_completion(&priv->wait_completion);
...
}
The hwmon subsystem requires drivers to implement internal locking for
attributes registered outside the core, such as debugfs interfaces. Without
a transaction lock, interleaved USB commands can corrupt hardware state and
result in mismatched telemetry data.
--
Sashiko AI review · https://sashiko.dev/#/patchset/anLj9gPWRoRDbQBV@monster.localdomain?part=1
next prev parent reply other threads:[~2026-08-05 7:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 7:19 [PATCH] hwmon: corsair-psu: fix possible out-of-bounds access on missing string termination Wilken Gottwalt
2026-08-05 7:30 ` sashiko-bot [this message]
2026-08-05 14:51 ` Guenter Roeck
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=20260805073034.C71C01F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wilken.gottwalt@posteo.net \
/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.