CVE-2024-42304

What it actually does

ext4_read_dirblock() silently accepts a directory whose first data block is a hole when the lookup type is DIRENT, producing an on-disk directory lacking '.' and '..' entries that later crashes make_indexed_dir() and similar code paths.

Why it matters to the business

Unprivileged local users on Linux systems using the ext4 file system can trigger kernel crashes or denial of service by mounting or operating on a specially crafted file-system image, leading to unplanned downtime and potential loss of availability on servers and workstations.

How an attack unfolds

An attacker prepares a malicious ext4 file-system image containing a directory whose first block is a hole yet contains valid dentries, mounts the image on a vulnerable kernel, and performs directory-modifying operations such as file creation; the missing error check allows the corrupted directory to be used, resulting in a crash inside directory-indexing routines.

How to fix it

Upgrade the Linux kernel to a version containing commit 0ecfebd2b52404ae0c54a878c872bb93363ada36 or later; rebuild and reboot all affected systems; verify the fix is present by checking the ext4 source for the added corruption check in ext4_read_dirblock.

How to confirm the fix worked

Confirm the patched kernel contains the referenced commit, then attempt to mount a test image that previously triggered the hole condition and verify that ext4_read_dirblock now returns an error instead of a usable buffer.

Typical attack path

1. Craft ext4 file-system image with first directory block as a hole
2. Mount the image on a vulnerable kernel
3. Trigger ext4_mknod or similar entry-creation path
4. ext4_read_dirblock returns a valid but incomplete buffer
5. make_indexed_dir or equivalent dereferences missing dot/dotdot and crashes

How to detect it

Review kernel logs for ext4 corruption messages or oops traces referencing make_indexed_dir, ext4_add_entry, or ext4_read_dirblock around the time of unexpected reboots; examine mounted ext4 volumes for directories that lack '.' and '..' entries when inspected with debugfs or similar tools.

What your security team should do

• Apply the kernel update containing commit 0ecfebd2b52404ae0c54a878c872bb93363ada36 as soon as possible on all ext4-using systems
• Prioritize patching of internet-facing or multi-tenant Linux hosts where untrusted file-system images may be processed
• Add the patched commit ID to internal kernel-build and image-signing pipelines to prevent regression