What is the CVSS score of CVE-2026-72141?

CVE-2026-72141 has a contested CVSS base score of 7.5 from a third party (e.g. CISA-ADP), while the vendor rates it High. vuln.today uses the vendor rating as authoritative.

Which versions of Linux Kernel are affected by CVE-2026-72141?

The Linux i2c-imx driver in NXP i.MX systems contains a flaw that can permanently disable I2C bus communication, requiring full device power-cycle to restore operations.. A patch is available.

How to fix or mitigate CVE-2026-72141?

Within 24 hours, identify all systems running Linux kernels on NXP i.MX SoCs and determine current kernel versions. No public exploit identified at time of analysis, though the vulnerability presents significant availability risk. Within 7 days, test and begin deployment of vendor patches (kernel versions 6.18.40, 7.1.5, or 7.2-rc4 matching your kernel branch) in staging environments, prioritizing production-critical systems. Complete enterprise-wide deployment within 30 days.

Linux Kernel CVE-2026-72141

EUVD-2026-58899 HIGH

2026-08-15 416baaa9-dc9f-4396-8d5f-8c081fb06d67

GHSA-m5rq-h5xv-g5g9

Information Disclosure Linux Red Hat Suse

High

Disputed · 7.5 Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Severity by source

Sources disagree (Low–High)

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

5.5 MEDIUM

Local kernel I2C driver bug requires /dev/i2c access (PR:L, AV:L); impact is purely availability (bus lockup); no confidentiality or integrity effect.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

SUSE

5.5 MEDIUM

AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Red Hat

5.5 LOW

qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 17, 2026 - 07:12 vuln.today

CVSS changed

Aug 17, 2026 - 06:22 NVD

7.5 (HIGH)

Patch available

Aug 15, 2026 - 07:20 EUVD

CVE Published

Aug 15, 2026 - 06:21 cve.org

UNKNOWN (no severity yet)

CVE Published

Aug 15, 2026 - 06:21 cve.org

HIGH 7.5

DescriptionCVE.org

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.

AnalysisAI

Permanent I2C bus lockup in the Linux kernel i2c-imx driver (NXP i.MX SoCs) occurs when an SMBus block-read response returns a byte count of 0, a condition explicitly permitted by SMBus 3.1 specification section 6.5.7. The interrupt-driven state machine introduced in the v6.13 rework rejects count=0 with -EPROTO but critically fails to issue NACK+STOP before returning, leaving the target device holding SDA and the entire I2C bus permanently stuck until the controller is power-cycled. A secondary bug on the count > I2C_SMBUS_BLOCK_MAX error path exhibits the same failure mode. No public exploit or active exploitation is identified; vendor-released patches are available in kernel versions 6.18.40, 7.1.5, and 7.2-rc4.

Technical ContextAI

The i2c-imx driver implements the I2C controller found on NXP i.MX SoCs (System-on-Chip), widely used in embedded Linux platforms including automotive, industrial, and IoT devices. The v6.13 kernel introduced a state-machine rework of the interrupt-driven (IRQ) block-read path; the atomic (polling) path had already regressed in v3.16 and is addressed separately. The root cause is a missing NACK+STOP sequence in two error exit paths within i2c_imx_isr_read_continue(): when the received byte count is 0 and when count exceeds I2C_SMBUS_BLOCK_MAX. Reading I2DR (the I2C data register) arms the hardware for the next byte transfer, so abandoning the state machine without asserting TXAK (transmit acknowledge bit, which NACKs the in-flight byte) and triggering STOP leaves the bus in an unrecoverable held state. No CWE was assigned by NVD; the closest applicable root cause class would be CWE-755 (Improper Handling of Exceptional Conditions) or CWE-703 (Improper Check or Handling of Exceptional Conditions). Affected commits span from 5f5c2d4579ca6836f5604cca979debd68ecfe23f through the stable-tree fix commits.

RemediationAI

The primary fix is upgrading to a patched kernel version: 6.18.40, 7.1.5, or 7.2-rc4, all of which contain the corrected i2c_imx_isr_read_continue() logic. Stable-tree patch commits are available at https://git.kernel.org/stable/c/07fd9385f0d87dff4b34f355f68adf701080cb24, https://git.kernel.org/stable/c/56ddfc18ea8f7d77747658892873eb632b2ed530, and https://git.kernel.org/stable/c/5d3240f42a667e29262aff76fdebfcdac4980626; vendors shipping custom i.MX kernels should cherry-pick the relevant commit. As a compensating control where patching is not immediately possible, restricting access to /dev/i2c-* device nodes (removing world-readable permissions, limiting to a trusted i2c group) reduces the software-trigger surface, though it does not prevent a malfunctioning I2C peripheral from organically triggering the bug. Avoiding SMBus block-read operations on peripherals that may legitimately return 0-byte counts is a further application-level mitigation, with the trade-off of reduced SMBus 3.1 compliance. Physical monitoring of I2C bus state and automated watchdog-triggered controller resets can limit downtime on systems that cannot be patched immediately.

Same technique Information Disclosure

View all

CVE-2019-2725 CRITICAL POC

9.8

CVE-2021-34523 CRITICAL POC

9.0

CVE-2013-2251 CRITICAL POC

9.8

CVE-2017-5638 CRITICAL POC

9.8

CVE-2025-24813 CRITICAL POC

9.8

CVE-2015-1701 HIGH POC

7.8

CVE-2017-0147 HIGH POC

7.5

CVE-2014-6324 HIGH POC

8.8

Vendor StatusVendor

SUSE

Severity: Moderate

Product	Status
SUSE Linux Enterprise Desktop 15 SP7	Not-Affected
SUSE Linux Enterprise Desktop 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0	Not-Affected

CVE-2026-72141 vulnerability details – vuln.today

Back

Linux Kernel CVE-2026-72141

Severity by source

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Lifecycle Timeline

DescriptionCVE.org

AnalysisAI

Technical ContextAI

RemediationAI

Same technique Information Disclosure

Vendor StatusVendor

SUSE

Share

External POC / Exploit Code