CVE-2026-53171 in Linux
Summary
by MITRE • 06/25/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/ethosu: fix arithmetic issues in dma_length()
dma_length() derives DMA region usage from command stream values and updates region_size[]:
len = ((len + stride[0]) * size0 + stride[1]) * size1
region_size[region] = max(..., len + dma->offset)
Several arithmetic issues can corrupt the derived region size:
- signed stride values may underflow when added to len - intermediate multiplications may overflow - len + dma->offset may overflow during region_size updates - dma_length() error returns were not validated by the caller
region_size[] is later used by ethosu_job.c to validate command stream
accesses against GEM buffer sizes. Arithmetic wraparound can therefore under-report region usage and bypass the bounds validation.
Fix by validating signed additions, using overflow helpers for multiplications and offset updates, and propagating dma_length() failures to the caller.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 06/27/2026
The vulnerability in question affects the linux kernel's acceleration subsystem specifically within the ethosu driver which handles DMA operations for hardware accelerators. This flaw exists in the dma_length() function that computes memory region usage based on command stream parameters and subsequently updates the region_size[] array. The core issue stems from inadequate arithmetic handling during the computation process where multiple operations can produce incorrect results due to overflow conditions.
The technical implementation contains several critical arithmetic flaws that compound to create exploitable conditions. The primary problem occurs when signed stride values are added to the length variable, potentially causing underflow conditions that corrupt the computed values. Additionally, intermediate multiplication operations lack proper overflow protection mechanisms, allowing large values to wrap around and produce incorrect results. The final addition operation involving dma->offset can also overflow during region_size updates, further compromising the integrity of the calculated memory usage. These mathematical errors are particularly dangerous because they occur within a validation function that's meant to enforce memory bounds checking.
The operational impact of this vulnerability extends beyond simple computational errors to potentially allow privilege escalation and memory corruption attacks. When region_size[] values become corrupted due to arithmetic wraparound, the subsequent bounds validation in ethosu_job.c fails to properly check command stream accesses against GEM buffer sizes. This allows attackers to bypass memory protection mechanisms and access unauthorized memory regions, effectively undermining the kernel's memory safety guarantees. The vulnerability creates a scenario where legitimate memory usage calculations are replaced with incorrect values that appear valid to the system but actually permit unauthorized access patterns.
The fix addresses these issues through comprehensive arithmetic validation measures that align with established security practices and industry standards such as those defined in CWE-191 for signed integer underflow and CWE-194 for unsigned integer overflow. Proper validation of signed additions prevents the underflow conditions that were previously possible, while implementing overflow helpers for multiplication operations ensures that intermediate calculations don't produce incorrect results. The offset update mechanism now includes proper boundary checking to prevent overflow during the final stage of computation. Most importantly, the fix ensures that error returns from dma_length() are properly validated by callers, preventing silent failures that could lead to exploitable conditions.
This vulnerability demonstrates the critical importance of arithmetic overflow protection in kernel space operations and aligns with ATT&CK techniques related to privilege escalation through memory corruption. The remediation strategy follows best practices for secure coding by implementing comprehensive input validation, proper error handling, and defensive programming techniques that prevent mathematical errors from propagating into security vulnerabilities. The fix essentially transforms a function that could silently produce incorrect values into one that explicitly handles all potential arithmetic edge cases and reports failures appropriately to prevent exploitation.