CVE-2026-64191 in Linux
Resumen
por VulDB • 2026-07-20
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
i2c: stub: Rechazar transferencias en bloque I2C con longitud no válida
El caso `I2C_SMBUS_I2C_BLOCK_DATA` en `stub_xfer()` utiliza `data->block[0]` como la longitud de la transferencia. La comprobación existente solo limita este valor para evitar desbordamientos fuera del array de registros `chip->words[256]`, pero no lo valida frente a `I2C_SMBUS_BLOCK_MAX` (32), que es el límite del búfer `i2c_smbus_data.block` en la unión (34 bytes en total). El controlador es una herramienta de desarrollo/pruebas (`CONFIG_I2C_STUB=m`, no compilado por defecto) que debe cargarse con un parámetro `chip_addr=`.
Un usuario local con acceso a `/dev/i2c-*` puede emitir un ioctl I2C_SMBUS con `I2C_SMBUS_I2C_BLOCK_DATA` y `data->block[0] > 32`, lo que provoca que `stub_xfer()` lea o escriba más allá del final del búfer de la unión `i2c_smbus_data.block`:
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: 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)
El error existe porque i2c-stub implementa `.smbus_xfer` directamente, omitiendo la validación de `I2C_SMBUS_BLOCK_MAX` en `i2c_smbus_xfer_emulated()`. El caso `I2C_SMBUS_BLOCK_DATA` en la misma función valida correctamente frente a `I2C_SMBUS_BLOCK_MAX`, pero el caso `I2C_SMBUS_I2C_BLOCK_DATA` no lo hace.
Solución: Rechazar transferencias con `data->block[0] == 0` o `data->block[0] > I2C_SMBUS_BLOCK_MAX` devolviendo `-EINVAL`, en coherencia tanto con el caso `I2C_SMBUS_BLOCK_DATA` de la misma función como con la validación de `I2C_SMBUS_I2C_BLOCK_DATA` en `i2c_smbus_xfer_emulated()`.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.