CVE-2026-72089

The IVPU firmware log vulnerability (CVE-2026-72089) exposes a failure mode where defensive bounds checks were layered onto untrusted interface parsing without closing the upstream input validation gap — making the hardening functionally ineffective against the actual attack surface. The vulnerability is an integer underflow in the calculation `data_size = log->size - log->header_size`. When `log->header_size` exceeds `log->size`, this underflow produces a near-U32_MAX value that bypasses downstream bounds clamping entirely. The bounds checks in commit dd1311bcf0e6 were added in response to a prior issue where indices escaped the valid buffer region — but those checks operate on values that have already been corrupted by the upstream arithmetic failure. This is the critical gap: the developers fixed what the prior incident exposed (malformed indices escaping a valid buffer) without tracing backward to ask what upstream arithmetic could produce values that collapse the buffer before bounds checking even executes. The failure manifests in two distinct ways. First, the underflow allows the clamped index to exceed the actual buffer bounds, creating a read-past-end condition. Second, and less discussed, is the infinite loop case: when `log->size` equals zero, the offset calculation stagnates and the processing loop never terminates — a denial-of-service condition in driver code that handles hardware acceleration paths. Neither the header validation nor the size check catches this case, suggesting the error handling paths weren't systematically reasoned about because they were considered unreachable under normal conditions. This is not an isolated incident. The underflow-into-bounds-bypass pattern has surfaced repeatedly in ACPI table parsing, device tree handling, and SMBIOS interfaces — anywhere the kernel ingests structured metadata from firmware. The consistent failure is treating the firmware interface as implicitly trusted because the hardware vendor "owns" that layer. When firmware bugs produce malformed input (indistinguishable from malicious firmware), the defensive code has no fallback posture. The EPSS score of 0.00166 correctly reflects low probability — exploiting this requires either malicious firmware or a firmware bug in a specific hardware configuration. But the vulnerability class has a stable recurrence rate. Each time, the patch commit reads like a security improvement; each time, the actual fix is incomplete because it assumes the data model is trustworthy up to the point of clamping. For defenders: validate the structural relationship between firmware-provided fields before arithmetic — a simple comparison like `log->size < log->header_size` would have closed this gap. More importantly, when adding defensive checks, trace backward through the arithmetic that feeds those checks and ask what upstream values could render them irrelevant. This is a documented anti-pattern with a clear genealogy — treat it as such.

Reviewed through automated stages and approved by a human before publication.