CVE-2026-89787: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir()
In the Linux kernel, the following vulnerability has been resolved:
ext4: check dir entry fits before reading the hash trailer in ext4searchdir()
For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4DIRENTHASHES()), at an offset derived from de->namelen. On the sbnocasefoldcompatfallback() path ext4match() reads that trailer, but ext4searchdir()'s by-hand pre-check only tests de->name + de->namelen <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4DIRENTHASHES(de) lands past the block end, so ext4match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object:
BUG: KASAN: use-after-free in ext4match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4match (fs/ext4/namei.c:1435) ext4searchdir (fs/ext4/namei.c:1470) ext4findentry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filenamelookup (fs/namei.c:2842) vfsstatx (fs/stat.c:353) dosysnewfstatat (fs/stat.c:538) dosyscall64 (arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)
Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4match(). This is the same bound ext4checkdirentry() already enforces via ext4dirreclen(), so no well-formed entry is rejected. The other caller, ext4finddestde(), runs ext4checkdirentry() first and is unaffected.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using ext4 casefolded encrypted directories are exposed on the sb_no_casefold_compat_fallback() lookup path. The malformed directory entry must place its name at the directory-block boundary so that the hash trailer extends beyond the block.
What action triggers the out-of-bounds read?
An ordinary lookup of the crafted directory entry triggers ext4_search_dir() and can reach the out-of-bounds hash-trailer read in ext4_match(). The reported call path includes filename lookup and statx operations.
How could administrators identify a possible occurrence?
KASAN may report a use-after-free in ext4_match, with a read of size 4 and call frames including ext4_search_dir(), __ext4_find_entry(), and ext4_lookup(). The underlying condition is an out-of-bounds read past a directory block, even though the report may be classified as use-after-free depending on adjacent page contents.