CVE-2024-50278

What it actually does

Out-of-bounds memory access in dm-cache during first resume after unexpected expansion of the fast device, because cache_preresume size validation is skipped and in-core structures sized for the original smaller device are used.

Why it matters to the business

Systems relying on device-mapper caching can experience kernel crashes, memory corruption, or potential local privilege escalation, leading to unplanned downtime and data integrity risks on storage servers and virtualized environments.

How an attack unfolds

An attacker with local access crafts dmsetup commands to load a cache table sized for a small fast device, expands the underlying device, then resumes and later suspends the cache target, triggering out-of-bounds reads or writes inside is_dirty_callback and related bitset operations.

How to fix it

Apply the upstream kernel fix for CVE-2024-50278 or later stable releases that include the cache_preresume size check on first resume; rebuild and reboot with the patched kernel; re-create cache tables after any fast-device resize.

How to confirm the fix worked

Confirm the running kernel contains the cache_preresume check added after 2024-11-19; reproduce the provided dmsetup sequence in a test environment and verify no KASAN or out-of-bounds reports occur on suspend.

Typical attack path

1. Prepare linear devices for metadata, cache data, and origin
2. Load undersized cache table with dmsetup reload
3. Expand the fast device backing store
4. Resume the cache target for the first time
5. Suspend the cache to flush dirty bitset and hint array
6. Trigger KASAN-detected out-of-bounds access

How to detect it

Search kernel logs for KASAN vmalloc-out-of-bounds reports mentioning is_dirty_callback or cache_ctr; inspect auditd and syslog entries around dmsetup suspend operations on cache targets; correlate with unexpected device-mapper table reloads followed by device expansion.

• BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback
• Read of size 8 at addr ffffc90000085040
• cache_ctr+0x176a/0x35f0
• dmsetup suspend cache

What your security team should do

• Prioritize kernel updates on all systems using dm-cache within the next patching cycle
• Audit storage configurations for dynamic fast-device resizing workflows
• Add kernel memory-safety monitoring (KASAN or similar) to CI test pipelines for dm targets
• Review and restrict unprivileged dmsetup access via policy