Answer in brief
CVE-2026-72142 records a Unknown severity vulnerability in i2c: imx: fix locked bus on SMBus block-read of 0 (atomic). 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 | >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <016ef0f6ca4bc9bf0330ac41bd2ea349759643e3 || >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <c882e8cc68fb993700dc21fd6e754001e6297934 || >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <6d2c973926d0612360693bc559be2ffde836151b || >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <60ed00d46616a9232e42ea7a3e3c0273d7cf7543 || >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <cb2fc37857693b55909fb77dc2c87cfbc1cdc476 | 016ef0f6ca4bc9bf0330ac41bd2ea349759643e3, c882e8cc68fb993700dc21fd6e754001e6297934, 6d2c973926d0612360693bc559be2ffde836151b, 60ed00d46616a9232e42ea7a3e3c0273d7cf7543, cb2fc37857693b55909fb77dc2c87cfbc1cdc476 |
| Linux/Linuxgeneric | 3.16 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path 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 for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-72142 records a Unknown severity vulnerability in i2c: imx: fix locked bus on SMBus block-read of 0 (atomic). 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 | >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <016ef0f6ca4bc9bf0330ac41bd2ea349759643e3 || >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <c882e8cc68fb993700dc21fd6e754001e6297934 || >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <6d2c973926d0612360693bc559be2ffde836151b || >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <60ed00d46616a9232e42ea7a3e3c0273d7cf7543 || >=8e8782c71595a5ad29e234ce6b3d2fce787fb07a <cb2fc37857693b55909fb77dc2c87cfbc1cdc476 | 016ef0f6ca4bc9bf0330ac41bd2ea349759643e3, c882e8cc68fb993700dc21fd6e754001e6297934, 6d2c973926d0612360693bc559be2ffde836151b, 60ed00d46616a9232e42ea7a3e3c0273d7cf7543, cb2fc37857693b55909fb77dc2c87cfbc1cdc476 |
| Linux/Linuxgeneric | 3.16 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path 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 for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.
Quoted source text, attributed separately from HOL analysis.