Answer in brief
CVE-2026-64191 records a Unknown severity vulnerability in i2c: stub: Reject I2C block transfers with invalid length. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-64191 records a Unknown severity vulnerability in i2c: stub: Reject I2C block transfers with invalid length. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=4710317891e4824ce1510a6b5066abbd3e917750 <7e9072dbd5f2f17934751873450d2c22080ead80 || >=4710317891e4824ce1510a6b5066abbd3e917750 <21e87f336ac6303fed54a69b1d0d79a23b25c8d0 || >=4710317891e4824ce1510a6b5066abbd3e917750 <3fd225f3e4cd67ec8ddab1afed9da03c7c43537c || >=4710317891e4824ce1510a6b5066abbd3e917750 <1c4ffe6b4f04365485ed58d64c9bb86b46fc9037 || >=4710317891e4824ce1510a6b5066abbd3e917750 <4bd8635f28c135a08aac6badcd7d9b5cdb34335f || >=4710317891e4824ce1510a6b5066abbd3e917750 <5f4d2bd028ebb6e4c09a9d64842546022321d4a7 || >=4710317891e4824ce1510a6b5066abbd3e917750 <0526931b16e5a118d367b7bfce7d797e63f7ac69 || >=4710317891e4824ce1510a6b5066abbd3e917750 <6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e | 7e9072dbd5f2f17934751873450d2c22080ead80, 21e87f336ac6303fed54a69b1d0d79a23b25c8d0, 3fd225f3e4cd67ec8ddab1afed9da03c7c43537c, 1c4ffe6b4f04365485ed58d64c9bb86b46fc9037, 4bd8635f28c135a08aac6badcd7d9b5cdb34335f, 5f4d2bd028ebb6e4c09a9d64842546022321d4a7, 0526931b16e5a118d367b7bfce7d797e63f7ac69, 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e |
| Linux/Linuxgeneric | 2.6.33 | Not reported |
Published upstream
Jul 20, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=4710317891e4824ce1510a6b5066abbd3e917750 <7e9072dbd5f2f17934751873450d2c22080ead80 || >=4710317891e4824ce1510a6b5066abbd3e917750 <21e87f336ac6303fed54a69b1d0d79a23b25c8d0 || >=4710317891e4824ce1510a6b5066abbd3e917750 <3fd225f3e4cd67ec8ddab1afed9da03c7c43537c || >=4710317891e4824ce1510a6b5066abbd3e917750 <1c4ffe6b4f04365485ed58d64c9bb86b46fc9037 || >=4710317891e4824ce1510a6b5066abbd3e917750 <4bd8635f28c135a08aac6badcd7d9b5cdb34335f || >=4710317891e4824ce1510a6b5066abbd3e917750 <5f4d2bd028ebb6e4c09a9d64842546022321d4a7 || >=4710317891e4824ce1510a6b5066abbd3e917750 <0526931b16e5a118d367b7bfce7d797e63f7ac69 || >=4710317891e4824ce1510a6b5066abbd3e917750 <6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e | 7e9072dbd5f2f17934751873450d2c22080ead80, 21e87f336ac6303fed54a69b1d0d79a23b25c8d0, 3fd225f3e4cd67ec8ddab1afed9da03c7c43537c, 1c4ffe6b4f04365485ed58d64c9bb86b46fc9037, 4bd8635f28c135a08aac6badcd7d9b5cdb34335f, 5f4d2bd028ebb6e4c09a9d64842546022321d4a7, 0526931b16e5a118d367b7bfce7d797e63f7ac69, 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e |
| Linux/Linuxgeneric | 2.6.33 | Not reported |
Published upstream
Jul 20, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().
Quoted source text, attributed separately from HOL analysis.