CVE-2026-89786
mass1Out-of-Bounds Read in Linux Kernel ext4 Inline-Data Directory Handling
CVE-2026-89786 is a slab out-of-bounds read in the Linux kernel's ext4 filesystem, in ext4_read_inline_dir(), which handles directories whose contents are stored inline in the inode (the inline_data feature). The iteration code accepts a directory position whose minimum dirent header would extend past the end of the exactly-sized inline buffer, and dereferences de->rec_len (via the rescan probe and __ext4_check_dir_entry) before the entry is rejected, because the length check is passed the larger extra_size instead of the physical inline_size. Triggering it requires listing such a directory via getdents64(); the flaw yields kernel memory disclosure and potential kernel crash/denial of service (CVSS rates confidentiality high, availability high, integrity none), and although it is scored AV:N, the described trigger is the directory-read path, so an attacker needs the ability to read a crafted or corrupted inline directory (e.g. local access or a supplied filesystem image). Any Linux system running a kernel with ext4 inline-data directory support is potentially affected, with practical exposure concentrated on systems where the ext4 inline_data feature is actually in use. No exploitation in the wild, public proof-of-concept, or CISA KEV listing is known.
What to do: Deploy kernels containing this upstream ext4 fix as soon as your distribution ships it (no fixed release version is given in the source data). Audit ext4 volumes for the inline_data feature (dumpe2fs -h <device> | grep inline_data) and, where it is not required, plan to clear it (tune2fs -O ^inline_data after confirming no inline data is in use). Until patched, avoid mounting untrusted ext4 images and restrict untrusted local users on systems using inline_data, since triggering requires listing a crafted inline directory.
| Linux kernel (ext4 filesystem, inline-data directory handling) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: dir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic "." and ".." land at their block-dir offsets. A dirent is formed at "dir_buf + pos - extra_offset", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.