CVE-2026-72141
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk45th percentile - higher than 45% of all known CVEs
Summary
In the Linux kernel i2c-imx driver, the interrupt-driven path rejects an SMBus block read with a byte count of 0 as -EPROTO, but does not send NACK+STOP, causing the I2C bus to lock up. The fix accepts count=0 and sends NACK and STOP.
Risk Assessment
I2C bus lockup can prevent communication with devices, leading to system failures or data loss.
Recommendation
Install the Linux kernel update that includes this fix.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the interrupt-driven block-read state machine rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle of this i2c controller. Accept count=0: NACK the in-flight dummy byte (TXAK) and set msg->len to 2 so i2c_imx_isr_read_continue() emits STOP via its normal last-byte path. The dummy byte is discarded; block-read callers only consume buf[0..count-1]. Reading I2DR has likewise already armed the next byte on the count > I2C_SMBUS_BLOCK_MAX error path, so NACK it (TXAK) before aborting with -EPROTO; otherwise the failing transfer's STOP cannot complete and the bus stays held. The atomic path regressed earlier (v3.16) and is fixed separately; this patch covers only the v6.13 state-machine rework.