CVE-2026-89573

What it actually does

Mismatched value_size metadata in dm-array blocks allows element_at() to stride beyond block bounds during __load_mappings(), causing out-of-bounds memory access and corruption when crafted superblock roots are loaded by dm-cache.

Why it matters to the business

Local attackers can achieve arbitrary code execution or kernel crash on systems using device-mapper caching, leading to full host compromise, data exposure, or denial of service with no remote vector required.

How an attack unfolds

An attacker with local access crafts a dm-cache superblock whose mappings root references a hint block (value_size 4) instead of a mappings block (value_size 8). When the kernel loads the array, get_ablock and element_at walk the block using the wrong stride, reading or writing past the 4096-byte boundary and corrupting adjacent kernel memory.

How to fix it

Upgrade the Linux kernel to a version containing the dm-array size-mismatch rejection in get_ablock and __shadow_ablock. Rebuild any custom kernels with the fix applied and reboot affected hosts. Until patched kernels are available, avoid exposing untrusted device-mapper metadata images to the kernel.

How to confirm the fix worked

Confirm the running kernel contains the array_block value-size check; attempt to activate a test volume whose mappings root points at a 4-byte hint block and verify the operation is rejected before any element_at stride occurs.

Typical attack path

1. Obtain local unprivileged shell on target Linux system
2. Create or modify a device-mapper thin-pool or cache metadata image with inconsistent array-block headers
3. Mount or activate the crafted volume so dm-cache calls __load_mappings on the malicious root
4. Trigger out-of-bounds access via normal cache population or mapping lookup
5. Escalate via corrupted kernel structures to root or execute arbitrary code

How to detect it

Inspect kernel logs (dmesg, journalctl) for oops traces containing dm_array, element_at, or get_ablock; look for unexpected activation of dm-cache volumes with mismatched array roots in audit logs or udev events.

What your security team should do

• Prioritize kernel updates on all systems that use dm-cache or device-mapper thin provisioning
• Restrict local user ability to create or attach arbitrary block devices and metadata images
• Monitor for kernel oops or panic messages referencing dm-array or element_at
• Audit device-mapper configuration scripts and initramfs images for use of untrusted metadata