CVE-2026-89574: dm array: validate array block headers on read
In the Linux kernel, the following vulnerability has been resolved:
dm array: validate array block headers on read
arrayblockcheck() validates blocknr and csum and nothing else, while nodecheck(), next to it, has bounded the structural fields since both were written. dmarraycursornext() takes its loop bound from the on-disk nrentries and elementat() 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 -- dmcacheloadmappings() drives it once per cache block at activation.
Check the header against itself: reject a zero valuesize, require maxentries to equal calcmaxentries() for that valuesize and block size, and require nrentries to fit. Equality rather than an upper bound, since a count below the real capacity trips BUGON() in fillablock() and trimablock(). Metadata dm-array writes satisfies all three.
Affected Software
Event History
Frequently Asked Questions
When is the affected code path exercised?
The path is exercised when dm_cache_load_mappings() runs during dm-cache activation, once for each cache block.
What metadata conditions indicate a problematic array block?
A problematic header can have a zero value_size, a max_entries value that does not equal the calculated capacity for its value_size and block size, or an nr_entries value that exceeds the block’s capacity.
What behavior can malformed metadata trigger before the fix?
An oversized on-disk nr_entries value can keep the cursor on one block while its index advances beyond that block, causing reads to walk off the dm-bufio buffer.