From: Guenter Roeck <linux@roeck-us.net>
To: Gui-Dong Han <hanguidong02@gmail.com>
Cc: linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com
Subject: Re: [PATCH v2] hwmon: (lm63) Add locking to avoid TOCTOU
Date: Thu, 30 Apr 2026 16:00:22 -0700 [thread overview]
Message-ID: <a8cfcc8f-1213-4424-bc91-267f6500a368@roeck-us.net> (raw)
In-Reply-To: <20260416135703.53262-1-hanguidong02@gmail.com>
On Thu, Apr 16, 2026 at 09:57:03PM +0800, Gui-Dong Han wrote:
> The functions show_fan(), show_pwm1(), show_temp11(),
> temp2_crit_hyst_show(), and show_lut_temp_hyst() access shared cached
> data without holding the update lock. This can cause TOCTOU races if
> the cached values change between the checks and the later calculations.
>
> Those cached values are updated in lm63_update_device(). In the general
> case, the affected functions combine multiple cached values without
> locking and can therefore observe a mixed old/new snapshot. In
> addition, show_fan() reads data->fan[nr] locklessly while
> lm63_update_device() updates data->fan[0] in two steps, which can
> expose an intermediate torn value and potentially trigger a
> divide-by-zero error. This means that converting the macro to a
> function is not sufficient to fix show_fan().
>
> Hold the update lock across the whole read and calculation sequence so
> that the values remain stable.
>
> Check the other functions in the driver as well. Keep them unchanged
> because they either do not access shared cached values multiple times
> or already do so under lock.
>
> Link: https://lore.kernel.org/linux-hwmon/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Fixes: e872c91e726e ("hwmon: (lm63) Add support for unsigned upper temperature limits")
> Fixes: d216f6809eb6 ("hwmon: (lm63) Expose automatic fan speed control lookup table")
> Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Applied.
Thanks,
Guenter
> ---
> v2:
> - Sashiko-bot pointed out that show_fan(), temp2_crit_hyst_show(), and
> show_lut_temp_hyst() also need locking.
>
> While learning the hwmon driver code, I found a few more potential
> TOCTOU problems in drivers still using the older non-_with_info() APIs.
> Fix them.
> ---
> drivers/hwmon/lm63.c | 37 +++++++++++++++++++++++++++++--------
> 1 file changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwmon/lm63.c b/drivers/hwmon/lm63.c
> index 035176a98ce9..b8b1de5fa90f 100644
> --- a/drivers/hwmon/lm63.c
> +++ b/drivers/hwmon/lm63.c
> @@ -333,7 +333,13 @@ static ssize_t show_fan(struct device *dev, struct device_attribute *devattr,
> {
> struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
> struct lm63_data *data = lm63_update_device(dev);
> - return sprintf(buf, "%d\n", FAN_FROM_REG(data->fan[attr->index]));
> + int fan;
> +
> + mutex_lock(&data->update_lock);
> + fan = FAN_FROM_REG(data->fan[attr->index]);
> + mutex_unlock(&data->update_lock);
> +
> + return sprintf(buf, "%d\n", fan);
> }
>
> static ssize_t set_fan(struct device *dev, struct device_attribute *dummy,
> @@ -366,12 +372,14 @@ static ssize_t show_pwm1(struct device *dev, struct device_attribute *devattr,
> int nr = attr->index;
> int pwm;
>
> + mutex_lock(&data->update_lock);
> if (data->pwm_highres)
> pwm = data->pwm1[nr];
> else
> pwm = data->pwm1[nr] >= 2 * data->pwm1_freq ?
> 255 : (data->pwm1[nr] * 255 + data->pwm1_freq) /
> (2 * data->pwm1_freq);
> + mutex_unlock(&data->update_lock);
>
> return sprintf(buf, "%d\n", pwm);
> }
> @@ -529,6 +537,7 @@ static ssize_t show_temp11(struct device *dev, struct device_attribute *devattr,
> int nr = attr->index;
> int temp;
>
> + mutex_lock(&data->update_lock);
> if (!nr) {
> /*
> * Use unsigned temperature unless its value is zero.
> @@ -544,7 +553,10 @@ static ssize_t show_temp11(struct device *dev, struct device_attribute *devattr,
> else
> temp = TEMP11_FROM_REG(data->temp11[nr]);
> }
> - return sprintf(buf, "%d\n", temp + data->temp2_offset);
> + temp += data->temp2_offset;
> + mutex_unlock(&data->update_lock);
> +
> + return sprintf(buf, "%d\n", temp);
> }
>
> static ssize_t set_temp11(struct device *dev, struct device_attribute *devattr,
> @@ -592,9 +604,14 @@ static ssize_t temp2_crit_hyst_show(struct device *dev,
> struct device_attribute *dummy, char *buf)
> {
> struct lm63_data *data = lm63_update_device(dev);
> - return sprintf(buf, "%d\n", temp8_from_reg(data, 2)
> - + data->temp2_offset
> - - TEMP8_FROM_REG(data->temp2_crit_hyst));
> + int temp;
> +
> + mutex_lock(&data->update_lock);
> + temp = temp8_from_reg(data, 2) + data->temp2_offset
> + - TEMP8_FROM_REG(data->temp2_crit_hyst);
> + mutex_unlock(&data->update_lock);
> +
> + return sprintf(buf, "%d\n", temp);
> }
>
> static ssize_t show_lut_temp_hyst(struct device *dev,
> @@ -602,10 +619,14 @@ static ssize_t show_lut_temp_hyst(struct device *dev,
> {
> struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
> struct lm63_data *data = lm63_update_device(dev);
> + int temp;
>
> - return sprintf(buf, "%d\n", lut_temp_from_reg(data, attr->index)
> - + data->temp2_offset
> - - TEMP8_FROM_REG(data->lut_temp_hyst));
> + mutex_lock(&data->update_lock);
> + temp = lut_temp_from_reg(data, attr->index) + data->temp2_offset
> + - TEMP8_FROM_REG(data->lut_temp_hyst);
> + mutex_unlock(&data->update_lock);
> +
> + return sprintf(buf, "%d\n", temp);
> }
>
> /*
prev parent reply other threads:[~2026-04-30 23:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 13:57 [PATCH v2] hwmon: (lm63) Add locking to avoid TOCTOU Gui-Dong Han
2026-04-16 19:24 ` sashiko-bot
2026-04-30 23:00 ` Guenter Roeck [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=a8cfcc8f-1213-4424-bc91-267f6500a368@roeck-us.net \
--to=linux@roeck-us.net \
--cc=baijiaju1990@gmail.com \
--cc=hanguidong02@gmail.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox