CVE-2026-74685: hwmon: (ltc4282) Clamp negative current limits
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (ltc4282) Clamp negative current limits
When a negative value is passed to ltc4282writecurr(), the signed long val is cast directly to u64:
drivers/hwmon/ltc4282.c:ltc4282writecurr() { / need to pass it in millivolt / u32 in = DIVROUNDCLOSESTULL((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 ltc4282writevoltagebyte(), 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update ltc4282_write_curr() to clamp negative current limits (val) to 0, and clamp values to the maximum supported upper limit, before casting and subsequent arithmetic/division to prevent underflow/overflow.
Linux kernel drivers/hwmon/ltc4282.c (ltc4282) ltc4282_write_curr() input handling (val) = Clamp val to 0 and to the maximum supported upper limit before casting
Event History
Frequently Asked Questions
What conditions are required to trigger the incorrect limit handling?
A negative value must be passed to ltc4282_write_curr(). The vulnerable conversion casts that signed value to u64 before calculation, causing it to become a large positive value and ultimately be treated as a maximum limit rather than zero.
What is the practical effect of supplying a negative current limit?
The calculated value can overflow and truncate to an unintended positive value. When written through ltc4282_write_voltage_byte(), it is clamped to the maximum limit instead of the expected zero limit.
What does the fix change?
The fix clamps the input value to zero and the maximum supported upper limit before casting it. It also uses a 64-bit temporary for the division result to avoid both the negative-value underflow path and possible overflow.