CVE-2024-42305

What it actually does

Missing sanity checks on dot and dotdot entries in a directory block allow a crafted ext4 filesystem image to cause do_split() to compute split=0, resulting in an out-of-bounds read of the hash map during make_indexed_dir and a subsequent page fault.

Why it matters to the business

Local users on Linux systems using ext4 can trigger kernel crashes or denial of service; the affected kernel code is present in 303 downstream dependents, increasing the operational blast radius of unpatched hosts.

How an attack unfolds

An attacker with local access supplies a malicious ext4 image lacking valid dot/dotdot entries. When a rename operation forces directory indexing, make_indexed_dir assumes the first two entries are dot and dotdot, miscalculates the split point, and performs an out-of-bounds access. Threat actors in 2024 espionage and financially motivated campaigns as well as known Linux kernel uninitialized-resource and out-of-bounds write operations have targeted similar kernel flaws.

How to fix it

Upgrade the Linux kernel to the commit b80575ffa98b5bb3a5d4d392bfe4c2e03e9557db or later stable releases that include the ext4_check_dx_root helper; for undici (npm) consumers update to version 5.19.1 or newer.

How to confirm the fix worked

Confirm the running kernel contains commit b80575ffa98b5bb3a5d4d392bfe4c2e03e9557db, then attempt to mount and exercise the previously triggering directory operations on a test image that lacks dot/dotdot entries; verify no page fault occurs.

Typical attack path

1. Mount a crafted ext4 filesystem image lacking proper dot and dotdot entries
2. Perform a rename that increases dentry name length beyond available space
3. Trigger make_indexed_dir via ext4_add_entry
4. Cause do_split to set split=0 and read map[split-1]
5. Trigger kernel page fault and potential crash

How to detect it

Search kernel logs for oops messages referencing make_indexed_dir, ext4_add_entry, or ext4_rename on ext4 volumes; inspect mounted filesystem images for directories whose first two entries are not dot and dotdot; correlate with local process activity that performs rename operations on ext4.

What your security team should do

• Prioritize kernel upgrades on all ext4-using systems within the CISA remediation window if applicable
• Restrict untrusted local filesystem mounts until patches are applied
• Monitor for kernel oops involving make_indexed_dir and ext4_rename
• Inventory all 303 downstream dependents and schedule coordinated updates