CVE-2026-52948: Linux Kernel I2C Integer Overflow Local DoS

Technical summary

The i2c-dev driver's I2C_TIMEOUT ioctl handler validates user-supplied timeout arguments against INT_MAX but fails to account for subsequent multiplication by 10. A malicious argument (e.g., 429496729) passes the initial check but overflows to a small unsigned value when multiplied by 10 in a 32-bit context. This truncated value then bypasses the signed-integer check within msecs_to_jiffies(). When assigned to the adapter's timeout field (a signed 32-bit int), the value is reinterpreted as negative. Passing this negative timeout to wait_for_completion_timeout() triggers sign extension to 64-bit, causing schedule_timeout() to emit warnings and return immediately with unrecovered SMBus state. The fix restricts user arguments to INT_MAX / 10 before multiplication.

Business impact

Organizations relying on I2C or SMBus subsystems (common in embedded systems, IoT devices, and specialized hardware interfaces) face potential service disruption. A local attacker could render I2C devices unresponsive, disrupting sensor polling, hardware monitoring, or device communication. Physical recovery may require system reboot. In production environments where uptime is critical—such as industrial controllers or networked appliances—repeated exploitation could inflict repeated downtime. The attack requires local access, limiting exposure in hardened cloud environments but posing risk in multi-tenant or physically accessible systems.

Affected systems

Linux kernel across multiple versions (specific affected release ranges require verification against vendor advisories). Any system exposing the i2c-dev interface to untrusted local users is vulnerable. This includes IoT gateways, industrial controllers, and Linux systems where users or unprivileged processes have access to /dev/i2c-* character devices.

Exploitability

Exploitability is straightforward for local attackers with access to i2c-dev character device nodes. No special privileges are required beyond standard user-level capabilities; the ioctl call is available to any process with device file access. Proof-of-concept is trivial: craft and submit a single malformed ioctl request. No user interaction is required, no network component exists, and the attack executes synchronously. However, remote exploitation is not possible; the attacker must have local code execution.

Remediation

Apply the kernel patch that adds arithmetic bounds checking to enforce user argument ≤ INT_MAX / 10 before multiplication. For systems unable to patch immediately, restrict device file permissions via udev rules or SELinux/AppArmor policies to prevent unprivileged user access to /dev/i2c-* nodes. Monitor system logs for schedule_timeout warnings, which may indicate exploitation attempts or vulnerable configurations.

Patch guidance

Retrieve the latest kernel security advisory for your distribution. Patches will implement explicit validation of the timeout argument prior to the multiplication step. Verify that the fix enforces `arg ≤ INT_MAX / 10` or equivalent arithmetic safeguard. Test patched kernels in a staging environment, especially if I2C/SMBus hardware is integral to your system. Kernel updates may be combined with other fixes, so review release notes for any concurrent behavioral changes to i2c-dev.

Detection guidance

Monitor kernel logs (dmesg, journalctl) for recurring 'schedule_timeout: wrong timeout value' warnings, particularly correlating with i2c-dev ioctl calls. Use auditd rules to log I2C_TIMEOUT ioctl invocations from unexpected processes. On systems with SELinux or AppArmor, enable denial logging for i2c-dev access. Note that successful exploitation may not always produce visible warnings if the system continues operation; correlation with I2C device functionality degradation (e.g., sensor timeouts, hardware unresponsiveness) may be necessary.

Why prioritize this

This is a local denial-of-service vulnerability affecting core hardware communication infrastructure. While CVSS 5.5 (Medium) reflects the local-access requirement, the practical impact in production environments can be severe: loss of I2C-dependent services, hardware malfunction, or forced reboots. Prioritize patching for systems where I2C is mission-critical or where local access controls are weak. Organizations managing IoT fleets, embedded appliances, or industrial controllers should treat this as higher priority despite the CVSS rating.

Risk score, explained

The CVSS 3.1 score of 5.5 (Medium) appropriately reflects a low attack vector (local only), low complexity, and a low privilege requirement balanced against high availability impact. The vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H indicates no confidentiality or integrity compromise, only denial of service. The score does not elevate to High because exploitation requires prior local access; however, in environments where local access is abundant or insufficiently controlled, effective risk may be higher. Consider context: privilege requirement (PR:L) may be lower than expected if unprivileged users can access device files by default.

Frequently asked questions