CVE-2026-89573: dm array: reject an array block whose value size is not the caller's
In the Linux kernel, the following vulnerability has been resolved:
dm array: reject an array block whose value size is not the caller's
arrayblockcheck() can only compare the header against itself, so a block with valuesize 4 and maxentries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and loadmappings() walks it through an info whose value size is 8, so elementat() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block.
getablock() and shadowablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.
Event History
Frequently Asked Questions
What systems are realistically exposed to this issue?
Systems using the Linux kernel device-mapper cache target are exposed only when dm-cache processes crafted metadata. Normal array operation reads only its own blocks, so the issue does not trigger on ordinary internally generated metadata.
What does an attacker need to exploit it?
An attacker needs a way to cause dm-cache to load crafted metadata in which the mappings root points to a hint block. This creates a value-size mismatch between the expected 8-byte mapping entries and 4-byte hint entries.
How can I tell whether a system may already be affected?
Investigate dm-cache metadata for a mappings root that references a hint block or other array block with a different value size than the caller expects. The described condition causes 8-byte traversal over 4-byte entries and can reach beyond the 4096-byte block boundary.