Cloudanix VulnDB

CVE-2026-92499

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux reads certain damaged folders can cause the system to crash or allow unauthorized memory access when listing directory contents.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A corrupted ext4 directory allows ext4_readdir to resume from an invalid offset when rec_len validation only checks the lower bound, permitting out-of-bounds reads that land in adjacent freed pages and are reported as use-after-free in __ext4_check_dir_entry.

Why it matters to the business

Systems using ext4 may experience kernel crashes or memory corruption when reading malformed directories, resulting in denial of service for file operations and potential escalation to arbitrary code execution in the kernel.

How an attack unfolds

An attacker supplies a crafted ext4 filesystem image containing a directory entry whose rec_len crosses a block boundary; when the kernel performs readdir or getdents, the invalid offset causes the main loop or rescan path to dereference truncated metadata, triggering the use-after-free.

How to fix it

Apply a kernel patch that caches the metadata checksum feature, derives the minimum safe directory entry length from the on-disk format, validates the rescan offset, and skips any remainder of a block whose tail is truncated.

How to confirm the fix worked

Confirm the presence of bounds checks on rec_len against inode-dependent minimum length (including hash bytes and checksum tail) before any dereference in ext4_readdir and __ext4_check_dir_entry; test with a reproducer that places a truncated entry at block offset 4092.

Typical attack path

  1. Create or obtain a malicious ext4 filesystem image with a directory entry whose rec_len spans a block boundary
  2. Mount the image on a vulnerable kernel
  3. Trigger directory enumeration via readdir, getdents, or ls on the corrupted directory
  4. Cause the kernel to resume iteration from the invalid cookie and dereference the out-of-bounds entry

How to detect it

Inspect kernel logs for KASAN use-after-free reports citing __ext4_check_dir_entry and ext4_readdir; correlate with processes performing getdents64 or iterate_dir on ext4 mounts shortly before the crash.

  • BUG: KASAN: use-after-free in __ext4_check_dir_entry
  • ext4_readdir+0xcde/0x2b70
  • __ext4_check_dir_entry+0x5ef/0x820
  • Read of size 2 at addr ffff888

What your security team should do

  • Upgrade to a patched kernel release that contains the ext4 readdir offset validation fix
  • Scan untrusted ext4 images or disks for directory corruption before mounting
  • Enable kernel memory safety features such as KASAN in test environments to surface similar issues early
  • Restrict mounting of untrusted or removable ext4 media until patches are deployed

The record

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.

Affected packages

Ecosystem Package Introduced Fixed