CVE-2026-64191 Linux CVE debrief

Who should care

Users running Linux kernel with I2C stub enabled should apply patches to prevent local exploitation. Developers loading i2c-stub module with chip_addr= parameter are at risk. System administrators and security teams should review system logs for suspicious I2C_SMBUS ioctl activity and consider restricting access to /dev/i2c-* to trusted users.

Technical summary

The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length, but only clamps it to avoid overrunning chip->words[256]. It does not validate against I2C_SMBUS_BLOCK_MAX (32). A local user can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to access beyond the union i2c_smbus_data.block buffer. The fix involves rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL.

Defensive priority

Apply patches immediately. Restrict access to /dev/i2c-* to trusted users. Monitor for suspicious I2C_SMBUS ioctl activity and review system logs.

Recommended defensive actions

• Apply patches to update Linux kernel I2C stub
• Restrict access to /dev/i2c-* to trusted users
• Monitor system logs for suspicious I2C_SMBUS ioctl activity
• Inventory Linux systems for I2C stub usage
• Consider disabling I2C stub if not required
• Review compensating controls for exposed systems
• Track exceptions and retest remediated assets

Evidence notes

The CVE record was published on 2026-07-20T17:18:22.217Z and has been modified on 2026-07-27T05:16:35.123Z. Multiple source references are provided, including kernel.org stable commits. The I2C stub vulnerability allows local users to cause a stack-out-of-bounds read or write. Evidence is limited to public sources and may not reflect the full scope of affected systems. Defenders should verify system logs for suspicious I2C_SMBUS ioctl activity and review compensating controls.

Official resources