{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-64191", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-64191" ], "published": "2026-07-20T16:28:05Z", "summary": "i2c: stub: Reject I2C block transfers with invalid length", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: stub: Reject I2C block transfers with invalid length\n\nThe I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]\nas the transfer length. The existing check only clamps it to avoid\noverrunning the chip->words[256] register array, but does not validate\nit against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union\ni2c_smbus_data.block buffer (34 bytes total). The driver is a\ndevelopment/test tool (CONFIG_I2C_STUB=m, not built by default)\nthat must be loaded with a chip_addr= parameter.\n\nA local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl\nwith I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing\nstub_xfer() to read or write past the end of the union\ni2c_smbus_data.block buffer:\n\n BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)\n Read of size 1 at addr ffff88800abcfd92 by task exploit/81\n Call Trace:\n \n stub_xfer (drivers/i2c/i2c-stub.c:223)\n __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)\n i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)\n i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)\n i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)\n __x64_sys_ioctl (fs/ioctl.c:583)\n do_syscall_64 (arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n \n\nThe bug exists because i2c-stub implements .smbus_xfer directly,\nbypassing the I2C_SMBUS_BLOCK_MAX validation in\ni2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same\nfunction correctly validates against I2C_SMBUS_BLOCK_MAX, but the\nI2C_SMBUS_I2C_BLOCK_DATA case does not.\n\nFix by rejecting transfers with data->block[0] == 0 or\ndata->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with\nboth the I2C_SMBUS_BLOCK_DATA case in the same function and the\nI2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.177", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-64191" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7e9072dbd5f2f17934751873450d2c22080ead80" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/21e87f336ac6303fed54a69b1d0d79a23b25c8d0" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3fd225f3e4cd67ec8ddab1afed9da03c7c43537c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/1c4ffe6b4f04365485ed58d64c9bb86b46fc9037" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/4bd8635f28c135a08aac6badcd7d9b5cdb34335f" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5f4d2bd028ebb6e4c09a9d64842546022321d4a7" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/0526931b16e5a118d367b7bfce7d797e63f7ac69" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T13:16:28Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable path is reached by a local process issuing I2C_SMBUS ioctls on an i2c-stub /dev/i2c-* character device; it is neither remotely nor physically reachable.\nAC:L - Once i2c-stub is loaded, the attacker controls the address, direction, length, and register contents, making the corruption deterministic without a race. The non-default module configuration defines the vulnerable deployment rather than complicating exploitation within it.\nPR:L - The attacker needs unprivileged local access to the applicable /dev/i2c-* node, but no capability or namespace-specific administrative privilege is checked anywhere along the ioctl path.\nUI:N - After the vulnerable adapter is configured, exploitation requires only attacker-issued ioctls and no action by another user.\nS:U - The corruption occurs within the host kernel and represents conventional local privilege escalation, without crossing a separate virtualization or hardware security authority.\nC:H - An oversized block write reads up to 222 bytes beyond the 34-byte stack union and persists those bytes in attacker-readable stub registers, enabling substantial kernel-stack disclosure.\nI:H - An oversized block read writes up to 222 attacker-chosen bytes beyond the stack union because the attacker can prepopulate the stub registers, enabling control-data corruption and potential kernel code execution.\nA:H - The controlled stack overwrite can corrupt stack canaries, return state, or other control data, causing a repeatable kernel oops or panic even when code execution is unsuccessful." } } }