CVE-2026-52948

What it actually does

This is a local denial-of-service flaw in the Linux kernel I2C character-device interface. The I2C_TIMEOUT ioctl accepts a user-controlled timeout value in 10 millisecond units, validates it too weakly, and then multiplies it by 10 before conversion to jiffies. A large value can overflow during that multiplication and later be interpreted as a negative timeout. When the corrupted timeout is used by SMBus/I2C wait logic, the kernel can emit schedule_timeout warnings, return prematurely from waits, and leave the SMBus controller state machine in an unrecoverable or inconsistent state. Exploitation requires local ability to issue ioctls to an I2C device node, typically /dev/i2c-*; it is not a remote code execution issue and does not directly grant privilege escalation.

Why it matters to the business

Systems exposing Linux I2C device nodes to local users, containers, hardware-management agents, or untrusted workloads may be susceptible to local disruption of I2C/SMBus operations. On affected platforms, this can impair hardware monitoring, sensor reads, power-management interactions, embedded controller communication, or other board-management functions that depend on I2C/SMBus. The public exploitation signal is currently low: EPSS is 0.00129, it is not listed in CISA KEV, and no known exploit maturity is reported. However, because the issue was found by fuzzing and the triggering condition is simple for anyone with device-node access, organizations running multi-user Linux systems or products exposing I2C devices should still prioritize routine kernel updates or device-node access restrictions.

How an attack unfolds

An attacker first needs local execution on a vulnerable Linux system and permission to open an I2C character device such as /dev/i2c-0. They then issue the I2C_TIMEOUT ioctl with a specially chosen large timeout value that passes the existing upper-bound check but overflows when multiplied by 10 inside the kernel. The overflowed value is converted and stored as the adapter timeout, where it is effectively interpreted as a negative timeout. Subsequent SMBus or I2C operations use this corrupted timeout in wait_for_completion_timeout(), causing immediate or incorrect timeout behavior and kernel schedule_timeout warnings. The premature timeout path can leave the SMBus controller state machine corrupted, resulting in denial of service for I2C/SMBus functionality until recovery, driver reset, or reboot depending on the platform and driver behavior.

How to fix it

Update to a Linux kernel version that includes the upstream fix bounding the I2C_TIMEOUT ioctl argument to INT_MAX / 10 before multiplying by 10. If vendor packages are used, apply the distribution or appliance vendor’s kernel update containing the fix for CVE-2026-52948. No fixed package versions were provided in the input, so administrators should rely on vendor advisories and kernel changelogs referencing the I2C dev timeout overflow fix. Where immediate patching is not possible, restrict access to /dev/i2c-* device nodes to only trusted users and services, remove unnecessary users from groups that grant I2C access, avoid exposing I2C devices into containers or sandboxes, and consider disabling unneeded I2C character-device access on systems that do not require it.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the patch that limits I2C_TIMEOUT ioctl input to INT_MAX / 10. Check the active kernel version with uname -r and compare it against the vendor advisory or patched kernel build. On source-based or custom kernels, inspect drivers/i2c/i2c-dev.c or the relevant I2C dev ioctl handling path to ensure the timeout argument is bounded before multiplication. Validate exposure by checking whether /dev/i2c-* exists and which users, groups, containers, or services can access those device nodes. After patching, controlled testing in a non-production environment can confirm that oversized I2C_TIMEOUT ioctl values are rejected or safely bounded and no schedule_timeout warnings are produced.

Typical attack path

1. Obtain local code execution on a Linux system with an affected kernel.
2. Identify accessible I2C device nodes, commonly /dev/i2c-*.
3. Open an accessible I2C character device with sufficient permissions.
4. Call the I2C_TIMEOUT ioctl with a large crafted value, such as a value near 429496729, that overflows when multiplied by 10.
5. Trigger or wait for subsequent I2C/SMBus operations that use the corrupted adapter timeout.
6. Cause kernel timeout warnings and disrupt the SMBus/I2C controller state machine, producing a local denial of service.

How to detect it

Look for evidence of local processes accessing I2C device nodes followed by kernel timeout warnings or SMBus/I2C errors. Useful log sources include kernel ring buffer output, journald kernel logs, /var/log/kern.log, /var/log/messages, auditd logs for device-node access, EDR process telemetry, and container runtime device-mount records. Search for schedule_timeout warnings occurring near I2C/SMBus errors, especially where the same host shows recent opens of /dev/i2c-* by unusual processes, user shells, fuzzers, test binaries, containers, or non-hardware-management services. If auditd was configured to monitor /dev/i2c-* access, correlate open/ioctl activity with kernel warnings. Because the exploit primarily changes kernel state and may not leave a unique file artifact, absence of logs does not prove non-exploitation; focus on temporal correlation between suspicious local device access and I2C/SMBus instability.

• schedule_timeout: wrong timeout value
• wait_for_completion_timeout
• /dev/i2c-
• I2C_TIMEOUT
• SMBus controller
• i2c-dev
• drivers/i2c/i2c-dev.c
• kernel: schedule_timeout: wrong timeout value
• audit: PATH name="/dev/i2c-
• SYSCALL ioctl

What your security team should do

• Inventory Linux systems that expose /dev/i2c-* device nodes, especially embedded, industrial, appliance, server-management, and hardware-monitoring platforms.
• Prioritize kernel updates for systems where untrusted local users, containers, plugins, or third-party agents can access I2C character devices.
• Restrict /dev/i2c-* permissions to the minimum required users and services; remove broad group access where not operationally necessary.
• Review container, VM, and device-passthrough configurations to ensure I2C device nodes are not exposed to untrusted workloads.
• Monitor kernel logs for schedule_timeout warnings and I2C/SMBus controller errors that may indicate attempted exploitation or fuzzing activity.
• For custom kernels, backport the specific bounds-check fix if a full kernel upgrade is not immediately feasible.
• Document any systems that cannot be patched and apply compensating controls such as device-node permission hardening and workload isolation.