Re: [PATCH] hwmon: (corsair-psu) Fix linear11 calculation

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:

Pre-existing issues:
- [High] Missing null termination in USB string attributes leads to a kerne=
l memory disclosure.
- [High] Concurrent sysfs and debugfs reads cause a data race on the shared=
 USB command buffer and wait completion.
--

--- Patch [1]: [PATCH] hwmon: (corsair-psu) Fix linear11 calculation ---
Note: The format of this report has been altered to use a free-form summary=
=20
rather than inline diff quotes due to recitation restrictions.

commit 00dd75e6c6959cf10ed39455a52e60c23722db89
Author: Guenter Roeck <[email protected]>
Subject: hwmon: (corsair-psu) Fix linear11 calculation

This commit fixes the linear11 to integer calculation by correctly casting=
=20
the shifted values to s16 and using 64-bit temporary variables. It prevents=
=20
sign-extension issues with negative temperatures and clamps the final resul=
t=20
to avoid overflow.

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for the USB
string attributes to lack null termination, leading to a kernel memory
disclosure?

Looking at corsairpsu_usb_cmd() in drivers/hwmon/corsair-psu.c, it
unconditionally copies REPLY_SIZE bytes from the USB response into the
string buffers like priv->vendor using memcpy(). If a USB device returns
exactly 24 bytes of non-null characters, no null terminator is appended.

Later, when a user reads the corresponding world-readable debugfs file,
vendor_show() uses seq_printf() with "%s" to read priv->vendor. Could this
result in an out-of-bounds read that leaks adjacent kernel memory fields?

[Severity: High]
This is a pre-existing issue, but does this code have a data race when
handling concurrent sysfs and debugfs reads?

In drivers/hwmon/corsair-psu.c, the shared USB command buffer
(priv->cmd_buffer) and wait_completion state are mutated in
corsairpsu_usb_cmd() without thread synchronization. While sysfs accesses
are protected by the hwmon core lock, debugfs callbacks like print_uptime()
funnel through to the USB request path without acquiring any locks.

If a user issues concurrent reads to hwmon sysfs attributes and debugfs
attributes, could this mutate the shared priv->cmd_buffer and
priv->wait_completion simultaneously, potentially leading to data corruption
or deadlocks via corrupted wait_completion state?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803232005.2339=
[email protected]?part=3D1