CVE-2026-80627 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
MIPS: mm: Fix out-of-bounds write in maar_res_walk()
maar_res_walk() uses wi->num_cfg as the index into the fixed-size wi->cfg array, but checks whether the array is full only after it has filled the selected entry. If walk_system_ram_range() reports more than 16 memory ranges, the overflow call writes one struct maar_config past the end of the array before WARN_ON() prevents num_cfg from advancing.
Move the full-array check before taking the array slot and return non-zero when the scratch array is full, so walk_system_ram_range() terminates the walk instead of invoking the callback for further ranges.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel contains a critical out-of-bounds write vulnerability within the MIPS memory management subsystem, specifically located in the maar_res_walk function. This flaw arises from an improper sequence of operations when managing the wi->cfg array, which is designed to hold configuration structures for memory ranges. The root cause lies in the fact that the code uses wi->num_cfg as an index to access this fixed-size array but performs a boundary check only after writing data into the selected entry. This logic error means that if walk_system_ram_range reports more than sixteen distinct memory ranges, the function will proceed to write one struct maar_config past the end of the allocated buffer before any warning or termination mechanism can intervene.
From a technical perspective, this vulnerability represents a classic heap-based buffer overflow resulting from incorrect bounds checking placement. The wi->cfg array has a fixed capacity, and while the code attempts to prevent excessive writes by monitoring num_cfg, it fails to validate whether the current index is valid before performing the write operation. Consequently, when the system encounters more than sixteen memory ranges during the walk process, the kernel executes an out-of-bounds write that corrupts adjacent memory structures. Although a WARN_ON macro eventually prevents num_cfg from advancing further, the damage of writing past the array boundary has already occurred at this stage, potentially leading to data corruption or unstable system behavior depending on what lies in the adjacent memory space.
The operational impact of this vulnerability is significant for systems running MIPS architecture kernels that utilize dynamic memory range reporting mechanisms. An attacker who can influence the number and nature of reported memory ranges could exploit this out-of-bounds write to overwrite critical kernel data structures, potentially leading to privilege escalation or a denial of service condition through system crash. The severity is heightened by the fact that this occurs during routine memory management operations, meaning it may be triggered under normal operating conditions if hardware configuration results in numerous distinct RAM regions being reported. This aligns with CWE-787, which describes out-of-bounds write vulnerabilities where a program writes data past the end of or before the beginning of the intended buffer.
To mitigate this risk, the vulnerability has been addressed by reordering the logic within maar_res_walk to perform the full-array check prior to accessing any array slot. This ensures that if the scratch array is already at capacity, the function returns a non-zero value immediately, signaling walk_system_ram_range to terminate the iteration process rather than invoking the callback for additional ranges. This fix prevents the out-of-bounds write from occurring by enforcing strict boundary validation before memory access takes place. Administrators should ensure their systems are updated with kernel patches that include this correction, particularly those running MIPS-based hardware configurations where dynamic memory range reporting is active. Regularly applying security updates and monitoring system logs for any anomalous behavior related to memory management can further reduce exposure to such vulnerabilities in production environments.