CVE-2024-26860

What it actually does

A memory leak occurs in dm-integrity when data is rechecked after a checksum failure because the checksums pointer is not freed due to an early goto skip_io, bypassing the associated kfree.

Why it matters to the business

Systems using dm-integrity on Linux kernels may experience gradual memory exhaustion during repeated checksum error scenarios, leading to degraded performance, instability, or crashes in long-running storage environments with high device-mapper usage.

How an attack unfolds

An attacker triggers repeated checksum failures on dm-integrity protected volumes to force recheck paths, causing the leak to accumulate memory without release; no remote code execution or direct privilege escalation is enabled by this flaw alone.

How to fix it

Upgrade the Linux kernel to version 6.1.83 or later, or apply commit 20e21c3c0195d915f33bc7321ee6b362177bf5bf from the stable git tree; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel reports a fixed version via uname or /proc/version; exercise dm-integrity recheck paths under checksum failure conditions and monitor for absence of memory growth using slabinfo or kmemleak.

Typical attack path

1. Identify or configure a dm-integrity target with checksum verification enabled
2. Induce checksum failures through data corruption or fault injection
3. Trigger recheck operations that hit the leaky code path
4. Repeat to accumulate unreleased memory allocations

How to detect it

Review kernel logs for dm-integrity checksum failure messages followed by recheck activity; monitor slab allocator statistics for growth in checksum-related allocations over time.

What your security team should do

• Prioritize kernel upgrades on all systems exposing dm-integrity volumes within standard maintenance windows
• Audit device-mapper configurations for integrity targets and document exposure
• Implement memory usage monitoring for kernel dm modules as a temporary compensating control