All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.