CVE-2026-89574 in Linux
Summary
by MITRE • 09/12/2026
In the Linux kernel, the following vulnerability has been resolved:
dm array: validate array block headers on read
array_block_check() validates blocknr and csum and nothing else, while node_check(), next to it, has bounded the structural fields since both were written. dm_array_cursor_next() takes its loop bound from the on-disk nr_entries and element_at() is unguarded pointer arithmetic, so a count larger than the block holds keeps the cursor in one block while the index grows past it and the read walks off the dm-bufio buffer -- dm_cache_load_mappings() drives it once per cache block at activation.
Check the header against itself: reject a zero value_size, require max_entries to equal calc_max_entries() for that value_size and block size, and require nr_entries to fit. Equality rather than an upper bound, since a count below the real capacity trips BUG_ON() in fill_ablock() and trim_ablock(). Metadata dm-array writes satisfies all three.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The Linux kernel device mapper array subsystem contains a critical validation deficiency within its block header checking mechanism that can lead to out-of-bounds memory access and potential system instability or denial of service. The vulnerability stems from the insufficient scope of the array_block_check function, which currently validates only the block number and checksum but fails to verify structural integrity fields such as value size and entry counts against their calculated limits. This oversight creates a scenario where malformed metadata can bypass initial checks while still causing logical errors during subsequent operations that rely on these unchecked values for memory management decisions.
The operational impact of this flaw is most severe when the dm_cache_load_mappings function processes cache blocks during activation, as it drives the cursor iteration logic once per block. The loop bound for iterating through array entries is derived directly from the nr_entries field stored in the on-disk metadata without sufficient validation against the actual physical capacity of the buffer. Concurrently, the element_at function performs unguarded pointer arithmetic based on this potentially inflated entry count. Consequently, if a crafted or corrupted header specifies an nr_entries value larger than what the block can physically hold, the cursor remains within the current memory block while the index increments beyond its valid range. This results in the read operation walking off the end of the dm-bufio buffer, leading to out-of-bounds reads that may expose sensitive kernel memory or cause a kernel panic due to invalid memory access patterns.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-119 Buffer Overflow beyond bounds, as the system fails to enforce constraints on input data derived from external sources before using it for critical buffer indexing operations. From an ATT&CK perspective, this represents a potential path for exploitation in scenarios where attackers can influence metadata structures, potentially leading to information disclosure or denial of service through kernel-level crashes. The lack of bounds checking on structural fields allows malformed inputs to propagate deeper into the subsystem without triggering appropriate error handling mechanisms that would normally prevent such unsafe memory accesses.
To mitigate this risk, the resolution involves enhancing the validation logic within array_block_check to enforce strict consistency between header values and their calculated limits. Specifically, the fix requires rejecting any block with a zero value_size, ensuring that max_entries exactly equals the result of calc_max_entries for the given value size and block size, and verifying that nr_entries fits within the allocated capacity. The use of equality checks rather than simple upper bounds is critical because values below the real capacity can trigger BUG_ON assertions in fill_ablock and trim_ablock functions due to internal assumptions about metadata structure integrity. By ensuring that all written metadata satisfies these three conditions, the kernel prevents malformed headers from causing out-of-bounds memory access during array cursor operations, thereby restoring structural safety guarantees for device mapper array functionality.