CVE-2026-74685 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (ltc4282) Clamp negative current limits
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel hardware monitoring subsystem contains a type conversion vulnerability within the ltc4282 driver that allows for improper input validation leading to potential system instability or incorrect sensor reporting. This flaw resides in the ltc4282_write_curr function, which is responsible for handling current limit configurations for the LTC4282 power monitor chip. The core technical issue stems from an unsafe casting operation where a signed long integer value, representing the user-provided current limit, is directly cast to an unsigned 64-bit integer without prior range checking or sign verification. In C programming semantics, when a negative signed integer is cast to an unsigned type, it undergoes two's complement conversion resulting in a very large positive number rather than preserving its negative nature. This behavior violates the expected logical constraints of hardware configuration parameters which typically do not accept negative current limits for this specific device interface.
The immediate operational consequence of this casting error is severe integer overflow during subsequent arithmetic operations. The code multiplies the erroneously converted large unsigned value by a resistance sense factor and divides it by scaling constants to convert the value into millivolts. Because the input was originally negative, the resulting intermediate calculation produces an extremely large number that exceeds the capacity of the target u32 variable used to store the result in millivolts. This causes integer truncation or overflow, yielding a pseudo-random positive value rather than the intended clamped zero or valid limit. When this corrupted value is passed to the lower-level function responsible for writing voltage bytes to the hardware register, it triggers an internal clamp mechanism that forces the setting to its maximum supported upper limit instead of correctly rejecting the invalid input or defaulting to zero. This results in the power monitor being configured with incorrect operational parameters, potentially leading to inaccurate current readings or improper protection thresholds.
From a security and standards perspective, this vulnerability is classified under CWE-190 Integer Overflow or Wraparound due to the arithmetic operation exceeding the bounds of the data type after invalid input processing. It also aligns with CWE-20 Improper Input Validation as the driver fails to adequately sanitize user-supplied values before performing critical hardware configuration operations. In terms of attack vectors, this could be leveraged in scenarios where an unprivileged or semi-privileged process can interact with hwmon sysfs interfaces to manipulate sensor limits, although exploitation typically requires local access and specific knowledge of the device interface. The ATT&CK framework categorizes such kernel-level misconfigurations under techniques related to Defense Evasion or Privilege Escalation if the incorrect hardware state leads to bypassing safety mechanisms that protect against overcurrent conditions.
To mitigate this vulnerability, developers must implement strict input validation before any type casting occurs. Specifically, the signed long value should be checked to ensure it is non-negative and within the acceptable range for the device's maximum supported limit prior to conversion. If a negative value or an out-of-bounds positive value is detected, the function should reject the request immediately rather than proceeding with arithmetic operations that assume valid input. Furthermore, intermediate calculations involving multiplication of potentially large values should be performed using 64-bit integers to prevent overflow before any truncation to smaller types like u32 occurs. This ensures data integrity throughout the calculation pipeline and prevents pseudo-random results from influencing hardware state. Proper validation at the entry point of such configuration functions is essential for maintaining system stability and security in kernel-space drivers that interface with physical hardware components.