kernel/linux.git/drivers/hwmon, branch v7.1.12

hwmon: (corsair-psu) serialize debugfs access against hwmon

2026-08-19T16:20:21+00:00

[ Upstream commit 2da6050809d437a805e7a3aa22398a15073b0234 ] corsairpsu_request() sends a rail select command and then the actual read as two separate transfers, both going through the single shared cmd_buffer and wait_completion in corsairpsu_usb_cmd(). The hwmon core serializes its own callers, but the debugfs files call corsairpsu_get_value() directly and never take that lock, so a debugfs read can land between another reader's rail select and its value read. The result is a value from the wrong rail reported as the right one, because corsairpsu_usb_cmd() only checks the command echo and both transfers echo the command it expects. It can also make a caller consume the reply meant for the other one, since raw_event() writes into the shared buffer and completes whoever happens to be waiting. Locking was dropped in commit 4207069edbf0 ("hwmon: (corsair-psu) Rely on subsystem locking") on the grounds that the subsystem serializes for us, which holds for sysfs but not for these files. Take the same lock in the debugfs paths that issue commands, using the guard added in commit d1e720c7328e ("hwmon: Support guard() and scoped_guard for subsystem locks"). The lock cannot go into corsairpsu_request() itself: the hwmon core already holds it across ->read, so every sysfs read would deadlock. vendor_show() and product_show() only print strings cached during probe and issue no command, and corsairpsu_get_criticals() and corsairpsu_check_cmd_support() run before either interface is registered, so none of them need it. Fixes: 4207069edbf0 ("hwmon: (corsair-psu) Rely on subsystem locking") Signed-off-by: Ali Ahmet Memis Tested-by: Wilken Gottwalt Link: https://lore.kernel.org/r/20260806142139.168611-1-ali@iusegentoo.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (ltc4282) Fix parsing adi,current-limit-sense-microvolt

2026-08-19T16:20:21+00:00

[ Upstream commit 335698fd7f60b6707b21fda725f97f35fa956b07 ] ltc4282_parse_dt() evaluates the wrong variable when parsing the current limit. When the adi,current-limit-sense-microvolt property is parsed into st->vsense_max, the subsequent switch statement evaluates the unrelated val variable instead of st->vsense_max: drivers/hwmon/ltc4282.c:ltc4282_parse_dt() { ... ret = device_property_read_u32(dev, "adi,current-limit-sense-microvolt", &st->vsense_max); if (!ret) { int reg_val; switch (val) { case 12500: reg_val = 0; break; ... } Because val holds a small integer representing vin_mode (from 0 to 3), it never matches any of the valid current limit cases. This causes it to always fall through to the default error case, return -EINVAL, and aborts probe initialization for any device tree using this property. Validate st->vsense_max instead to fix the problem. Reported-by: Sashiko Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282") Cc: Nuno Sa Reviewed-by: Nuno Sá Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (ltc4282) Clamp negative current limits

2026-08-19T16:20:21+00:00

[ Upstream commit e253dd5f9f6d875a317895bf43ec9534ed7523cb ] When a negative value is passed to ltc4282_write_curr(), the signed long val is cast directly to u64: drivers/hwmon/ltc4282.c:ltc4282_write_curr() { /* need to pass it in millivolt */ u32 in = DIV_ROUND_CLOSEST_ULL((u64)val * st->rsense, DECA * MICRO); ... } This cast converts negative inputs into large positive values. The subsequent division result overflows the u32 in variable, truncating to a pseudo-random positive value. When this is passed to ltc4282_write_voltage_byte(), it is clamped to the maximum limit instead of zero. Clamp val to 0 and to the maximum supported upper limit before the cast and assign the result to a 64-bit temporary variable before the division to avoid the underflow and an also possible overflow. Reported-by: Sashiko Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282") Cc: Nuno Sa Reviewed-by: Nuno Sá Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (ltc4282) Avoid overflow in maximum power calculation

2026-08-19T16:20:21+00:00

[ Upstream commit edd11a94335747423569500a194c6eaa915f2963 ] During device initialization in ltc4282_set_max_limits(), the calculation of the maximum power limit can suffer from a 32-bit integer overflow. static int ltc4282_set_max_limits(struct ltc4282_state *st) { ... st->power_max = DIV_ROUND_CLOSEST(st->vsense_max * DECA * MILLI, st->rsense) * st->vfs_out; ... } The result of DIV_ROUND_CLOSEST() evaluates to a 32-bit unsigned integer on 32-bit architectures. This result is then multiplied by st->vfs_out, which is a 16-bit unsigned integer. According to C promotion rules, since both operands are 32-bit or smaller, the multiplication is performed in 32-bit precision. If the device is configured with a low sense resistor value via the device tree (for example, 100 nano-ohms, resulting in st->rsense = 1) and the voltage is high, the division result can reach 343,750,000 and st->vfs_out can be 33,280. The product of these values is approximately 11.44 trillion, which exceeds the maximum capacity of a 32-bit integer and overflows before being stored in st->power_max. This overflow causes a truncated value to be assigned to st->power_max and written to the hardware limit register. An incorrect maximum power limit can trigger spurious power-bad faults or alarms, which may lead to the shutdown of the monitored power rail. Avoid the problem by calculating and storing the maximum power using 64-bit variables. Reported-by: Sashiko Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282") Cc: Nuno Sa Reviewed-by: Nuno Sá Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (ads7828) Fix external VREF regulator handling

2026-08-19T16:20:20+00:00

[ Upstream commit fddb5ceaf901b050ed2a1a7deeecbf97e003435a ] The driver currently has two issues with the external VREF regulator handling in ads7828_probe(): 1. All errors from devm_regulator_get_optional() are ignored, causing the driver to incorrectly fall back to internal VREF even for transient errors like -EPROBE_DEFER or genuine failures like -ENOMEM. 2. The external regulator is never enabled. The driver calls regulator_get_voltage() without first calling regulator_enable(), so the VREF pin may remain unpowered if the regulator is not configured as always-on. Fix both issues by switching to devm_regulator_get_enable_read_voltage(), which handles regulator get, enable, and voltage read in one call. Only -ENODEV (no regulator specified in device tree) should trigger the fallback to internal VREF. All other errors are propagated to the caller. Fixes: a8ddfea09566 ("hwmon: (ads7828) Accept optional parameters from device tree") Signed-off-by: Qingshuang Fu Link: https://lore.kernel.org/r/20260805061645.1331652-1-fffsqian@163.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (corsair-psu) fix possible out-of-bounds access on missing string termination

2026-08-19T16:20:20+00:00

[ Upstream commit 36c4d73ce05d1d8896c2669eb0730d35a02a2ec1 ] In theory it could be possible that the REPLY_SIZE sized buffers for holding the vendor and product strings could be end up missing the null termination (for example by malicious hardware built on purpose) required by the seq_printf() call. That limits the debugfs printf calls to a maximum string length of REPLY_SIZE. Fixes: d115b51e0e567 ("hwmon: add Corsair PSU HID controller driver") Signed-off-by: Wilken Gottwalt Link: https://lore.kernel.org/r/anLj9gPWRoRDbQBV@monster.localdomain Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (pmbus/lm25066) Fix PMBus coefficient calculations

2026-08-19T16:20:18+00:00

[ Upstream commit 0dabe8a56f772f0ece46d2597799f412c277d874 ] In lm25066_probe(), the PMBus coefficients for current and power are scaled based on the shunt resistor value. The calculation evaluates the multiplication using 32-bit arithmetic because info->m is an int and shunt is a u32: static int lm25066_probe(struct i2c_client *client) { ... info->m[PSC_CURRENT_IN] = info->m[PSC_CURRENT_IN] * shunt / 1000; info->m[PSC_POWER] = info->m[PSC_POWER] * shunt / 1000; ... } For large coefficients like 26882 (LM25056) or 15076 (LM5066i), a device tree shunt-resistor-micro-ohms value exceeding approximately 159,000 (159 mOhm, which is physically valid for low-current applications) causes the intermediate product to exceed UINT_MAX (4,294,967,295). This results in a silent wraparound before the division by 1000. Furthermore, if the wrapped value has the most significant bit set, converting it back to the signed int info->m results in negative coefficients. This logic error leads to drastically corrupted current and power readings, which can cause erratic thermal or power management behavior in the system. Fix the problem by using 64-bit operations for the multiply/divide operations. This can still overflow, but only for unreasonably large shunt resistor values. Reported-by: Sashiko Fixes: 94ee5fcc240fe ("hwmon: (pmbus/lm25066) Support configurable sense resistor values") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (nzxt-smart2) Check return value of init_device() in probe

2026-08-19T16:20:18+00:00

[ Upstream commit d533882ce1060866a590257f2c77ee23eabef5b8 ] The init_device() call in nzxt_smart2_hid_probe() can fail because it sends HID output reports to the hardware to detect fans and set the update interval. If the hardware is not responding or the HID reports fail, init_device() returns a negative error code. However, the return value was ignored, causing the probe to continue and register an hwmon device even though the device was never properly initialized. This leads to an inconsistent state where the driver reports stale data or blocks on wait queues that will never be woken. The same function's return value is already checked in the reset_resume() handler, confirming the author's intent that errors should be propagated. Note that this fix was not possible before commit 59d104b54b0b ("hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop") because the out_hw_close error path was missing hid_device_io_stop(), which would have opened a use-after-free risk window. Fixes: 53e68c20aeb1 ("hwmon: add driver for NZXT RGB&Fan Controller/Smart Device v2.") Signed-off-by: Qingshuang Fu Link: https://lore.kernel.org/r/20260804074842.505923-1-fffsqian@163.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (pmbus) Fix type confusion in notification logic

2026-08-19T16:20:17+00:00

[ Upstream commit 59bd68ab05a8f9c9a60b6ec44682084184803ff4 ] Sashiko reports: At the start of the loop in pmbus_notify(), the code unconditionally casts every attribute to a struct sensor_device_attribute: drivers/hwmon/pmbus/pmbus_core.c:pmbus_notify() { for (i = 0; i < data->num_attributes; i++) { struct device_attribute *da = to_dev_attr(data->group.attrs[i]); struct sensor_device_attribute *attr = to_sensor_dev_attr(da); int index = attr->index; ... } However, data->group.attrs can contain other types like struct pmbus_samples_reg or struct pmbus_sensor, which only embed a base struct device_attribute. If da is a struct pmbus_samples_reg, dev_attr is the last member. Casting it to struct sensor_device_attribute and reading the index field appears to access memory past the end of the allocation, which might trigger a slab-out-of-bounds read. Additionally, if da is a struct pmbus_sensor, casting it causes the index field to overlap with the page, phase, and reg fields. Could this produce a garbage mask on little-endian systems that spuriously matches the target reg, page, and flags during an alert? Fix the problem by using struct sensor_device_attr in struct pmbus_sensor and struct pmbus_label. Since those attributes never trigger a notification, set the value of attr->index to -1 for them. Use this value to distinguish from boolean attributes which _can_ trigger a notification and use the index field to encode mask, page, and register values. Fixes: f469bde9afd1 ("hwmon: (pmbus/core) Notify hwmon events") Cc: Vincent Jardin Tested-by: Vincent Jardin Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (pmbus/core) Avoid race condition during probe

2026-08-19T16:20:17+00:00

[ Upstream commit 71638a456852a18a4578f52d51926ba1d223053b ] pmbus_write_smbalert_mask() is not guarded, which can cause race conditions with concurrent sysfs attribute accesses. Similar, PMBus accesses in pmbus_init_debugfs() are not guarded, also resulting in potential race conditions. Add guards to both functions to prevent the races. Reported-by: Sashiko Fixes: 221819ca4c36e ("hwmon: (pmbus/core) Add interrupt support") Fixes: 1e069dfd96dfe ("hwmon: (pmbus) Add debugfs for status registers") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin