[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"repo-stars":3,"vuln-DEBIAN-CVE-2026-64191":6},{"stargazers_count":4,"fetched_at":5},8,"2026-09-19T04:32:17.889Z",{"id":7,"descriptions":8,"cisa":9,"weaknesses":10,"exploits":11,"aliases":12,"duplicate_of":9,"upstream":13,"downstream":16,"duplicates":17,"related":18,"reserved_at":9,"published_at":19,"modified_at":20,"state":9,"summary":21,"references_raw":23,"kevs":30,"epss":9,"epss_history":31,"metrics":32,"affected":33},"DEBIAN-CVE-2026-64191","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:   \u003CTASK>   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)   \u003C/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().",null,[],[],[],[14],{"_key":15},"CVE-2026-64191",[],[],[],"2026-07-20T17:18:22.217Z","2026-07-21T08:48:08.804602290Z",{"cisa_kev":22,"cisa_ransomware":22,"cisa_vendor":9,"epss_severity":9,"epss_score":9,"severity":9,"severity_score":9,"severity_version":9,"severity_source":9,"severity_vector":9,"severity_status":9},false,[24],{"url":25,"sources":26,"tags":28},"https://security-tracker.debian.org/tracker/CVE-2026-64191",[27],"osv_debian",[29],"Advisory",[],[],[],[34],{"ecosystem":35,"name":36,"vendor":37,"product":36,"cpe_part":9,"purl_type":38,"purl_namespace":37,"purl_name":36,"source":9,"versions":39},"Debian","linux","debian","deb",[40,44,48,51],{"version":41,"is_range":42,"range_type":43,"version_start":9,"version_start_type":9,"version_end":9,"version_end_type":9,"fixed_in":9},"all",true,"ecosystem",{"version":45,"is_range":42,"range_type":43,"version_start":9,"version_start_type":9,"version_end":46,"version_end_type":47,"fixed_in":9},"lt6_1_177_1","6.1.177-1","excluding",{"version":49,"is_range":42,"range_type":43,"version_start":9,"version_start_type":9,"version_end":50,"version_end_type":47,"fixed_in":9},"lt6_12_95_1","6.12.95-1",{"version":52,"is_range":42,"range_type":43,"version_start":9,"version_start_type":9,"version_end":53,"version_end_type":47,"fixed_in":9},"lt7_0_14_1","7.0.14-1"]