The Linux kernel SMBus block transfer logic allows user‑supplied block lengths that are zero or greater than the allowed maximum to escape validation before tracepoints or driver callbacks are executed. This results in out‑of‑bounds reads or writes into fixed buffers, producing kernel memory corruption. Two specific code paths are affected: the smbus_write tracepoint copies data->block[0]+1 bytes into a 34‑byte buffer, and the i2c‑stub driver performs array indexing based on block[0] without clamping to the SMBus maximum. Kernel crashes, data corruption, or an opportunity for privilege escalation can arise from these overflows.

All Linux kernels that include the native i2c_smbus_xfer path without the early block‑length check are affected. The fix was introduced with a commit adding validation in __i2c_smbus_xfer. Any distribution or embedded system running a kernel released before that commit, and exposing /dev/i2c devices to users, is in scope.

With a CVSS score of 7.8 the vulnerability is high severity, but the EPSS score is less than 1%, indicating a very low exploitation probability. The vulnerability is not listed in the CISA KEV catalog, implying no publicly known incidents. The likely attack vector is local: an attacker who can write to an /dev/i2c‑* device can provide an oversized block length via i2c‑dev ioctls, triggering the overflow. If a local attacker obtains kernel privilege, the resulting memory corruption can enable privilege escalation or arbitrary code execution in the kernel context.