CVE-2026-64191

What it actually does

CVE-2026-64191 is a Linux kernel buffer bounds flaw in the i2c-stub test/development driver. When the i2c-stub module is loaded and exposed through /dev/i2c-* device nodes, a local user who can issue I2C_SMBUS ioctls can submit an I2C_SMBUS_I2C_BLOCK_DATA transfer with an invalid block length greater than I2C_SMBUS_BLOCK_MAX. The vulnerable path uses data->block[0] as a length without validating it against the 32-byte SMBus block limit, causing stub_xfer() to read or write beyond the end of the i2c_smbus_data.block buffer. The most likely impact is a kernel memory safety violation resulting in a kernel warning, KASAN report, or denial of service; depending on kernel build, memory layout, and exploitability of the out-of-bounds access, it may also create a path toward information disclosure or local privilege escalation. Exposure is limited because i2c-stub is a development/test driver, is not built by default in typical configurations, and must be explicitly loaded with a chip_addr= parameter.

Why it matters to the business

This vulnerability primarily creates local system stability and hardening risk on Linux systems where the i2c-stub module is enabled and local users or processes have access to /dev/i2c-* devices. A successful attack could crash affected hosts or potentially compromise kernel integrity, disrupting workloads that depend on those systems. Business risk is lower than for remotely exploitable flaws because exploitation requires local access and a non-default test driver configuration, but it is still important for shared Linux hosts, lab infrastructure, CI systems, embedded development environments, and systems where untrusted users or containers may reach I2C device nodes. EPSS is currently low at 0.00127, it is not listed in CISA KEV, and no public exploit maturity is indicated, so remediation should be prioritized based on exposure rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker first needs local execution on a Linux system where the i2c-stub kernel module is present, loaded, and configured with a chip_addr parameter. The attacker also needs permission to access an I2C character device such as /dev/i2c-*. They then open the I2C device and send an I2C_SMBUS ioctl using the I2C_SMBUS_I2C_BLOCK_DATA transaction type. By setting data->block[0] to a value greater than 32, the attacker causes the vulnerable i2c-stub transfer handler to trust an invalid length and access memory past the end of the stack-based SMBus block buffer. On kernels with memory debugging, this may generate a KASAN stack-out-of-bounds report. On production kernels, the result may be a kernel oops, panic, unexpected data corruption, or potentially exploitable kernel memory access depending on mitigations and surrounding stack layout.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for i2c-stub validation of I2C_SMBUS_I2C_BLOCK_DATA lengths. The fixed behavior rejects block lengths of 0 or greater than I2C_SMBUS_BLOCK_MAX with -EINVAL. If fixed vendor package versions are not yet published for a distribution, track the relevant kernel security advisories and apply the first kernel update that includes the i2c-stub bounds-checking patch. As compensating controls, avoid loading the i2c-stub module on production systems, remove or blacklist the module where it is not required, restrict access to /dev/i2c-* device nodes to trusted administrative users only, and avoid exposing I2C devices into containers, sandboxes, CI jobs, or multi-user environments unless strictly necessary.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the i2c-stub fix or is at a vendor kernel release that incorporates it. Validate that i2c-stub is not loaded where it is unnecessary by checking loaded kernel modules. If the module must be used, confirm that /dev/i2c-* permissions restrict ioctl access to trusted users only. Functional validation can be performed in a controlled non-production test environment by issuing an I2C_SMBUS_I2C_BLOCK_DATA request with a block length greater than 32 and confirming that the kernel returns -EINVAL without a KASAN report, kernel oops, panic, or stack trace involving stub_xfer(). Do not run exploit-style validation on production systems because it may destabilize the kernel.

Typical attack path

1. Obtain local code execution on a Linux system, such as through an unprivileged shell, compromised application, or local user account.
2. Determine whether i2c-stub is available and loaded, for example by checking loaded modules or I2C device exposure.
3. Confirm access to an I2C device node such as /dev/i2c-* and the ability to issue I2C_SMBUS ioctls.
4. Craft an SMBus request using the I2C_SMBUS_I2C_BLOCK_DATA operation with data->block[0] set to an invalid length greater than 32.
5. Send the malicious ioctl to the vulnerable i2c-stub handler.
6. Trigger an out-of-bounds read or write in kernel context, potentially causing a KASAN report, kernel oops, denial of service, or further memory corruption.

How to detect it

Look for evidence of prior exploitation in kernel logs, audit logs, endpoint telemetry, and shell/process history. Relevant log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd records for /dev/i2c-* access, EDR telemetry for ioctl-heavy local utilities, and module load history. Kernel evidence is likely to appear as KASAN stack-out-of-bounds reports, kernel oopses, panics, or call traces referencing stub_xfer(), i2c_smbus_xfer(), i2cdev_ioctl_smbus(), i2cdev_ioctl(), or drivers/i2c/i2c-stub.c. Also review whether i2c-stub was loaded unexpectedly, especially with a chip_addr= parameter, and correlate the timestamp with users or processes opening /dev/i2c-* devices. Because this is a local kernel memory safety bug, network indicators are not expected; host telemetry and kernel logs are the primary detection sources.

• BUG: KASAN: stack-out-of-bounds in stub_xfer
• stub_xfer (drivers/i2c/i2c-stub.c
• drivers/i2c/i2c-stub.c:223
• __i2c_smbus_xfer
• i2c_smbus_xfer
• i2cdev_ioctl_smbus
• i2cdev_ioctl
• I2C_SMBUS_I2C_BLOCK_DATA
• /dev/i2c-
• i2c_stub
• i2c-stub
• chip_addr=

What your security team should do

• Inventory Linux systems for the i2c-stub module and prioritize systems where it is loaded or available to untrusted users.
• Patch exposed systems to a kernel release containing the i2c-stub invalid block length rejection fix.
• Blacklist or unload i2c-stub on production systems where it is not explicitly required for testing or development.
• Restrict /dev/i2c-* access using file permissions, udev rules, group membership, container device policies, and least-privilege controls.
• Review container, CI, and lab configurations to ensure I2C device nodes are not passed through to untrusted workloads.
• Monitor kernel logs for KASAN, oops, or panic messages referencing i2c-stub, stub_xfer, i2cdev_ioctl_smbus, or I2C_SMBUS_I2C_BLOCK_DATA.
• Treat exploitation evidence as a local compromise signal and investigate the originating user, process, and workload that accessed /dev/i2c-*.