CVE-2024-50250

What it actually does

Misaligned pos/len in dax_unshare_iter causes dax_iomap_direct_access to return pointers to the wrong offsets within fsdax pages, resulting in partial block copies that corrupt user data or leak stale pmem contents; missing invalidate_inode_pages2_range leaves mmap'd views stale.

Why it matters to the business

Organizations running Linux kernels on persistent memory hardware risk silent data corruption or exposure of previous file contents in DAX-enabled filesystems, potentially leading to integrity failures in databases, virtual machines, or high-performance storage workloads until systems are updated.

How an attack unfolds

An attacker with local write access to a DAX file issues unshare operations on ranges that are not fsblock-aligned; the broken iter logic copies to incorrect offsets or only partial blocks, allowing corruption of file contents or disclosure of prior pmem data. Publicly discussed Linux kernel memory issues have been leveraged by espionage and financially motivated actors in zero-day campaigns, though this specific flaw has no confirmed in-the-wild exploitation.

How to fix it

Upgrade the Linux kernel to version 6.1.116 or later; rebuild and reboot affected systems. For Ubuntu 14.04 LTS users of flashplugin-nonfree, ensure package version 11.2.202.540ubuntu0.14.04.2 or newer is installed.

How to confirm the fix worked

Confirm the running kernel reports version 6.1.116 or newer via uname -r; test DAX unshare operations on aligned and unaligned ranges with fsx or similar tools to verify full-block copies and proper page invalidation occur.

Typical attack path

1. Obtain local access or code execution on a Linux system using fsdax
2. Open or create a DAX-backed file and trigger dax_file_unshare on an unaligned range
3. Observe or force subsequent reads to receive corrupted or stale data from pmem
4. Leverage the integrity or confidentiality violation for further attacks such as tampering with application data

How to detect it

Review kernel logs for DAX-related warnings around unshare or iomap operations; examine application logs for unexpected data integrity errors on DAX filesystems; no specific post-exploitation artifacts are known.

What your security team should do

• Prioritize kernel upgrades on any systems using DAX or persistent memory within the next patch cycle
• Audit workloads that rely on DAX files for data integrity exposure
• Monitor vendor advisories for backports to older supported kernel branches
• Enable strict fsblock alignment checks in custom DAX applications until patches are deployed