How the Vulnerability Works
The vulnerability occurs in the Linux kernel’s ext4 filesystem implementation when processing corrupted directory entries. When a directory contains a ‘.’ entry with rec_len equal to the block size (typically 4KB), ext4_empty_dir() fails to properly validate the entry, leading to an out-of-bounds read:
1. The function loads the ‘.’ directory entry and performs basic checks
2. The rec_len value of exactly one block size bypasses validation checks
3. The pointer advances past the allocated memory boundary
4. Subsequent ext4_check_dir_entry() attempts to read past buffer bounds
5. This can trigger use-after-free or OOB read conditions
6. The issue stems from insufficient boundary checking in __ext4_check_dir_entry()
7. Attackers could craft malicious filesystems to exploit this flaw
8. The vulnerability is reachable through mounting crafted filesystems
9. Successful exploitation could lead to kernel memory disclosure
10. The bug was found via syzkaller fuzzing tool
11. KASAN detects this as slab-use-after-free
12. The vulnerability affects directory removal operations
- The corrupted ‘.’ entry must have rec_len == block_size
- The ‘..’ entry check then occurs outside valid memory
- No proper validation exists for this edge case
- The issue is in fs/ext4/namei.c in the kernel
- The flaw can crash the system or leak kernel memory
- Privilege escalation may be possible in some scenarios
19. The vulnerability requires mounting a malicious filesystem
20. Kernel versions before the fix are vulnerable
DailyCVE Form
Platform: Linux Kernel
Version: pre-fix versions
Vulnerability: OOB Read
Severity: Critical
date: 04/18/2025
What Undercode Say:
Exploitation Analysis:
- Craft filesystem with malformed directory entries
- Set ‘.’ entry rec_len to block size (4096)
- Trigger via mount + directory operations
- Exploit requires local filesystem access
- May combine with other flaws for escalation
Detection Commands:
Check kernel version
uname -r
Verify ext4 module loaded
lsmod | grep ext4
Scan for suspicious filesystems
find / -type f -exec file {} + | grep "ext4 filesystem"
Protection Measures:
// Kernel patch adds this check:
if (unlikely(de->rec_len == blocksize)) {
ext4_error(sb, "invalid rec_len for '.'");
return -EFSCORRUPTED;
}
Mitigation Steps:
1. Update to patched kernel version
2. Restrict mount privileges
3. Use kernel hardening (KASAN)
4. Audit filesystem sources
5. Monitor for crash reports
Debugging Commands:
Trigger crash repro mkdir -p /mnt/corrupt && mount -o loop malicious.img /mnt/corrupt rmdir /mnt/corrupt/baddir Check kernel logs dmesg | grep -i "KASAN" Verify mitigation grep -r "rec_len.blocksize" /usr/src/linux/fs/ext4
Vulnerable Code Pattern:
// Before fix: de = (struct ext4_dir_entry_2 ) bh->b_data; if (ext4_check_dir_entry(dir, NULL, de, bh, bh->b_data, bh->b_size, 0)) return false; de = ext4_next_entry(de, blocksize); // OOB here if rec_len == blocksize
Fixed Code:
// After fix: de = (struct ext4_dir_entry_2 ) bh->b_data; if (ext4_check_dir_entry(dir, NULL, de, bh, bh->b_data, bh->b_size, 0) || de->rec_len >= blocksize) return false; de = ext4_next_entry(de, blocksize);
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
