On Fri, Nov 28, 2025 at 08:43:51PM +0800, Gui-Dong Han wrote:
The function max6620_read checks shared data (tach and target) for zero before passing it to max6620_fan_tach_to_rpm, which uses it as a divisor. These accesses are currently lockless. If the data changes to zero between the check and the division, it causes a divide-by-zero error.
Explicitly acquire the update lock around these checks and calculations to ensure the data remains stable, preventing Time-of-Check to Time-of-Use (TOCTOU) race conditions.
This change also aligns the locking behavior with the hwmon_fan_alarm case, which already uses the update lock.
Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8... Fixes: e8ac01e5db32 ("hwmon: Add Maxim MAX6620 hardware monitoring driver") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han hanguidong02@gmail.com
Based on the discussion in the link, I will submit a series of patches to address TOCTOU issues in the hwmon subsystem by converting macros to functions or adjusting locking where appropriate.
This patch is not necessary. The driver registers with the hwmon subsystem using devm_hwmon_device_register_with_info(). That means the hwmon subsystem handles the necessary locking. On top of that, removing the existing driver internal locking code is queued for v6.19.
Thanks, Guenter