CVE-2026-72089 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Reject firmware log with size smaller than header
fw_log_from_bo() validates the tracing buffer header_size and that the log fits within the BO, but never checks that log->size is at least log->header_size. fw_log_print_buffer() then computes:
u32 data_size = log->size - log->header_size;
which underflows to a near-U32_MAX value when firmware reports a log whose size is smaller than its header. That huge data_size defeats the log_start/log_end bounds clamps added by commit dd1311bcf0e6 ("accel/ivpu: Add bounds checks for firmware log indices"), so fw_log_print_lines() reads far past the small real data region of the BO. A size of 0 also makes fw_log_from_bo() advance the offset by 0, causing the callers to loop forever on the same header.
Reject logs whose size is smaller than the header (which also rejects size == 0).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability exists within the Linux kernel's iGPU acceleration driver specifically in the ivpu component where firmware logging functionality is handled. This issue stems from inadequate validation of firmware log structures before processing, creating a potential avenue for memory corruption and system instability. The flaw manifests when the firmware provides logging data that violates fundamental size relationships between the log header and the actual log content.
The technical root cause involves the fw_log_from_bo() function which performs validation checks on tracing buffer header_size but fails to verify that the total log size meets minimum requirements relative to the header size. When firmware reports a log with a size smaller than its header, the subsequent calculation u32 data_size = log->size - log->header_size produces an integer underflow resulting in a value approaching UINT32_MAX. This massive data_size parameter bypasses the bounds checking mechanisms that were previously introduced through commit dd1311bcf0e6, which was specifically designed to protect firmware log indices.
The operational impact of this vulnerability extends beyond simple memory access violations into potential system exploitation scenarios. The fw_log_print_lines() function reads far past the intended small data region of the buffer object, potentially accessing uninitialized memory or corrupting adjacent data structures. Additionally, when the log size equals zero, the offset advancement logic fails completely causing infinite loops in the calling functions that process firmware logs. This creates both denial-of-service conditions and potential information disclosure risks as the system attempts to parse malformed logging data.
This vulnerability aligns with CWE-129, representing an insufficient input validation issue where the system fails to properly validate size relationships within structured data. The flaw also maps to ATT&CK technique T1059.001 for command and scripting interpreter execution, as the malformed firmware logs could potentially be used to trigger unexpected behavior in kernel processing routines. Furthermore, it represents a memory safety issue categorized under CWE-128, involving integer underflow conditions that lead to unintended memory access patterns. The exploitability of this vulnerability increases when considering that firmware updates often occur with elevated privileges, making successful exploitation potentially devastating for system integrity and availability.
The recommended mitigation strategy involves implementing strict size validation checks before any firmware log processing begins, ensuring that log->size is always greater than or equal to log->header_size. This approach directly addresses the core issue by rejecting malformed logs at the earliest possible stage in the processing pipeline. System administrators should also consider updating to kernel versions containing the fix, which specifically rejects logs with size smaller than headers and handles zero-sized logs appropriately to prevent infinite loops. The fix demonstrates proper defensive programming practices by incorporating comprehensive input validation that prevents arithmetic underflows from propagating through the system's memory management and logging subsystems.