From: Ali Ahmet Memis <ali@iusegentoo.com>
To: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Cc: Guenter Roeck <linux@roeck-us.net>,
linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hwmon: (corsair-psu) null terminate the vendor and product strings
Date: Sun, 2 Aug 2026 13:42:44 +0000 [thread overview]
Message-ID: <20260802134244.29107-1-ali@iusegentoo.com> (raw)
In-Reply-To: <20260802150354.04fd3857@posteo.net>
On Sun, Aug 02 2026, Wilken Gottwalt wrote:
> The device always provides terminated strings. The vendor string ("CORSAIR"
> or "Corsair") and the device string (3/4 numbers + 3 letters) are allways
> around 10-16 bytes.
Thanks, that settles it. So there is no reachable bug here, only a driver
that relies on the device terminating the string. That changes what the
patch should look like: v2 will say that outright, and I will drop the
Fixes: tag, since this is hardening rather than a fix and it has no
business going to stable.
> Actually, it would make more sense to change the memcpy to
> "REPLY_SIZE - 1". Just my thought.
That works. One detail worth weighing before you pick: corsairpsu_usb_cmd()
is also reached with a non NULL data from corsairpsu_request(), and
corsairpsu_get_value() passes an uninitialized u8 data[REPLY_SIZE] on the
stack. With REPLY_SIZE - 1 the last byte of that buffer is never written.
Only data[0..3] are read, so nothing breaks, but the shortening is not
confined to the two string callers.
Either is fine by me and it is your driver, so say which you prefer and I
will send v2 that way:
a) memcpy(data, priv->cmd_buffer + 2, REPLY_SIZE - 1), arrays unchanged
b) vendor and product as char[REPLY_SIZE + 1], memcpy unchanged
No rush on the locking patch either, whenever you get to testing it.
--
Ali
next prev parent reply other threads:[~2026-08-02 13:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 12:53 [PATCH] hwmon: (corsair-psu) null terminate the vendor and product strings Ali Ahmet Memis
2026-08-02 13:03 ` Wilken Gottwalt
2026-08-02 13:42 ` Ali Ahmet Memis [this message]
2026-08-02 16:22 ` Guenter Roeck
2026-08-02 16:32 ` Ali Ahmet Memis
2026-08-02 13:10 ` 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=20260802134244.29107-1-ali@iusegentoo.com \
--to=ali@iusegentoo.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--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.