CVE-2026-64205

What it actually does

This flaw affects the Linux kernel i2c-i801 SMBus controller driver. In an error path, the driver clears SMBus hardware status and ownership flags even when it failed to acquire the controller because BIOS, ACPI, or another firmware component was already using it. That can corrupt the SMBus controller state machine, causing repeated i801 access failures, continuous kernel log messages, CPU starvation from console logging, hung tasks, and potentially a kernel panic. The practical impact is local denial of service rather than code execution or privilege escalation.

Why it matters to the business

Systems using affected Linux kernels with the i2c-i801 driver may become unstable, unresponsive, or panic under certain SMBus contention conditions. This can interrupt production workloads, cause node reboots or outages, and complicate incident response because the symptom may appear as a kernel hang or hardware fault. The currently low EPSS score and absence from CISA KEV suggest broad active exploitation is not known, but the impact can still be material for servers, appliances, embedded systems, or fleet nodes where kernel availability is critical.

How an attack unfolds

An attacker would need a way to trigger repeated SMBus/i2c-i801 access on a vulnerable Linux system while the SMBus controller is busy or in use by BIOS/ACPI. When the driver pre-check fails, the vulnerable error path still writes to the SMBus host status register and clears flags it does not own. This disrupts the firmware or hardware transaction and leaves the controller in a corrupted busy state. Subsequent SMBus requests repeatedly fail with busy errors, producing a printk flood. On slower consoles or systems with synchronous logging, the log storm can monopolize CPU time, starve kernel tasks waiting on locks, trigger hung task detection, and potentially lead to a kernel panic or service outage.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the i2c-i801 fix moving the error-path cleanup so hardware registers are not cleared when the controller was not acquired. No exact fixed package versions were provided in the input, so use vendor advisories, stable kernel changelogs, or distribution security updates to identify the first fixed build for each deployed kernel stream. Where immediate patching is not possible, reduce exposure by limiting local untrusted code execution, disabling unnecessary SMBus/i2c tooling for non-administrative users, avoiding aggressive hardware sensor polling or fuzzing on affected systems, and considering disabling or blacklisting the i2c-i801 driver only if operationally safe and validated for the hardware platform.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor patch for the i2c-i801 error path. Validate by checking the installed kernel package changelog or source for the corrected control flow where the cleanup label is below the hardware register cleanup and failed i801_check_pre() paths do not execute the SMBHSTSTS write. After updating, reboot into the fixed kernel and confirm the vulnerable kernel is no longer running with uname -a and package manager queries. Operationally, monitor dmesg or journald during SMBus activity and confirm that repeated 'SMBus is busy, can't use it!' messages, hung task warnings, and i2c-i801-related panics do not recur.

Typical attack path

1. Obtain local code execution or another mechanism capable of causing repeated SMBus/i2c-i801 access on a vulnerable Linux host.
2. Create contention with BIOS/ACPI or firmware SMBus activity so i801_check_pre() fails because the controller is busy.
3. Trigger the vulnerable i801_access() error path repeatedly.
4. Cause the driver to clear SMBus hardware status flags without owning the controller.
5. Induce persistent SMBus busy failures and a high-volume kernel log flood.
6. Drive the system into CPU starvation, hung tasks, degraded responsiveness, or kernel panic.

How to detect it

To assess whether this issue was triggered, review kernel logs from journald, dmesg, syslog, serial console captures, netconsole, and crash dump metadata. Look for repeated i2c-i801 or SMBus busy errors followed by high-volume printk activity, hung task watchdog messages, blocked task reports, soft lockup or hard lockup warnings, and panic traces. Correlate the start of the log storm with local activity that accesses SMBus or hardware sensors, such as sensor polling, hardware inventory agents, firmware/ACPI activity, fuzzing, or administrative i2c tools. Useful artifacts include /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd journal entries for the kernel facility, vmcore/kdump output, pstore logs, and serial console logs. Because this is a denial-of-service condition, indicators show triggering or attempted triggering rather than persistence or post-exploitation compromise.

• SMBus is busy, can't use it!
• i2c-i801
• i801_access
• i801_check_pre
• Hung task
• hung task
• INFO: task
• blocked for more than
• kernel panic
• Kernel panic
• soft lockup
• hard lockup
• watchdog: BUG: soft lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/module/i2c_i801
• i2c_i801

What your security team should do

• Inventory Linux systems that load the i2c-i801 driver, especially servers, appliances, embedded systems, and hosts using hardware monitoring or SMBus sensor polling.
• Prioritize patching systems where local users, containers, monitoring agents, or hardware-management tools can trigger SMBus access repeatedly.
• Apply vendor kernel updates containing the i2c-i801 fix and reboot into the fixed kernel.
• Until patched, restrict untrusted local workloads and review permissions for tools that access i2c, SMBus, hardware sensors, or /dev interfaces related to hardware management.
• Add monitoring for kernel log floods containing i2c-i801 SMBus busy errors, hung task warnings, and unexpected kernel panics.
• If repeated symptoms are observed, preserve kernel logs, console logs, and crash dumps before rebooting where possible.
• Do not treat the issue as remote code execution; response should focus on availability risk, local abuse paths, and stability monitoring.