From: sashiko-bot@kernel.org
To: "Guenter Roeck" <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: [PATCH] hwmon: (ltc4282) Fix reading the minimum alarm voltage
Date: Sat, 25 Jul 2026 22:05:42 +0000 [thread overview]
Message-ID: <20260725220542.856D01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260725215755.1926830-1-linux@roeck-us.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Calculation of `st->power_max` causes a 32-bit integer overflow, resulting in a severely truncated max power limit being written to the device.
--
--- Patch [1]: [PATCH] hwmon: (ltc4282) Fix reading the minimum alarm voltage ---
commit 42cce0899ae28102bd89120aefb684af52579bfe
Author: Guenter Roeck <linux@roeck-us.net>
hwmon: (ltc4282) Fix reading the minimum alarm voltage
Coverity reports an out-of-bounds access when reading the minimum alarm
voltage for the VGPIO channel. Add the missing return statement to fix
the problem.
Fixes: cbc29538dbf7 ("hwmon: Add driver for LTC4282")
Cc: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> diff --git a/drivers/hwmon/ltc4282.c b/drivers/hwmon/ltc4282.c
> index 39b9d3abca990..cc698803f8bf8 100644
> --- a/drivers/hwmon/ltc4282.c
> +++ b/drivers/hwmon/ltc4282.c
[ ... ]
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential 32-bit
integer overflow in ltc4282_set_max_limits() during device probe:
drivers/hwmon/ltc4282.c:ltc4282_set_max_limits() {
...
/* Power is given by ISENSE * Vout. */
st->power_max = DIV_ROUND_CLOSEST(st->vsense_max * DECA * MILLI, st->rsense) * st->vfs_out;
ret = ltc4282_write_power_byte(st, LTC4282_POWER_MAX, st->power_max);
...
}
Because the result of DIV_ROUND_CLOSEST() and st->vfs_out are both 32-bit
or smaller types, does this multiplication overflow 32-bit precision before
being assigned to st->power_max?
If the device tree configures a small sense resistor (e.g., 100 nOhm,
making st->rsense = 1) and the voltage is high, the division result can be
around 343,750,000 and st->vfs_out can be 33,280. The resulting product is
over 11.44 trillion, which would overflow a 32-bit integer.
Could this cause a severely truncated max power limit to be written to the
hardware, potentially triggering spurious power-bad faults or shutting down
the monitored power rail?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260725215755.1926830-1-linux@roeck-us.net?part=1
prev parent reply other threads:[~2026-07-25 22:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 21:57 [PATCH] hwmon: (ltc4282) Fix reading the minimum alarm voltage Guenter Roeck
2026-07-25 22:05 ` sashiko-bot [this message]
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=20260725220542.856D01F000E9@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.