CVE-2026-89573

The Linux kernel's device-mapper array code (dm-array) fails to validate that a metadata block's declared value size matches the value size the caller expects: array_block_check() only checks a block header against itself, so an internally consistent but mismatched block (e.g., value_size 4 with max_entries 1018) passes validation. An attacker who can craft on-disk dm-cache metadata — for example, pointing the superblock's mappings root (8-byte entries) at a hint block (4-byte entries) — makes __load_mappings() stride 8 bytes over 4-byte entries and read offset 8160 of a 4096-byte block, an out-of-bounds access that can leak data or corrupt kernel memory and crash the machine (CVSS 3.1 base 7.8). Exploitation requires local access with privileges sufficient to write crafted metadata to the dm-cache metadata device; the flaw fires only on maliciously crafted metadata, never on legitimately written arrays. In principle, any Linux system running a kernel prior to the fix that activates device-mapper cache volumes (e.g., lvmcache) is affected. No public proof of concept exists and the issue is not listed in CISA's KEV catalog.

What to do: Apply your distribution's kernel updates as soon as they backport the upstream fix (which rejects blocks whose value_size disagrees with the caller in get_ablock() and __shadow_ablock()) and reload/reboot affected dm-cache mappings. Restrict write access to LVM/dm-cache metadata devices, and never activate dm-cache or thin-provisioned volumes sourced from untrusted media such as imported VM disks, forensic images, or removable storage. Treat kernel crashes or splats during dm-cache metadata loading as a possible tampering indicator.