CVE-2026-52948

In the Linux kernel, the following vulnerability has been resolved:

i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl

While fuzzing with Syzkaller, a persistent schedule_timeout: wrong timeout value warning was observed, accompanied by SMBus controller state machine corruption.

The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies().

A malicious user can pass a large value (e.g., 429496729) that passes the arg > INT_MAX check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal (int)m < 0 check in msecs_to_jiffies().

The truncated value is then assigned to client->adapter->timeout (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the schedule_timeout warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS).

Fix this by bounding the user argument to INT_MAX / 10.

[wsa: move the comment as well]

Weakness

The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.

Affected Software

Potential Mitigations

• Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
• If possible, choose a language or compiler that performs automatic bounds checking.
• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
• Use libraries or frameworks that make it easier to handle numbers without unexpected consequences.
• Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
• Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
• Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.
• Understand the programming language’s underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, “not-a-number” calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]
• Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/92.html

References

• https://git.kernel.org/stable/c/0b88ecfbc9dc33b4db8836c37b50cf174e6c0691
• https://git.kernel.org/stable/c/4576621dc6577f21a032acfd16c3ad61907a5ea7
• https://git.kernel.org/stable/c/617eb7c0961a8dfcfc811844a6396e406b2923ea
• https://git.kernel.org/stable/c/943e318eedbeaeea08ece3f5dd44c982f4ed2ef5
• https://git.kernel.org/stable/c/aa6ef734016912653a909477fb30aeb66c98b3a2
• https://git.kernel.org/stable/c/e9ffd5f5050fbb199d270a85614cd27ebed6fbac
• https://git.kernel.org/stable/c/ff02add34ffd03449b8115904ebe2ec4fed022d4
• https://git.kernel.org/stable/c/ffbcf31f032eb454ebfd29309f51366fe57f4ac4