Cloudanix VulnDB

CVE-2026-99174

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux ext4 filesystem can cause the operating system to crash when a disk is unmounted at the same time certain file operations are happening.

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

What it actually does

Use-after-free and null pointer dereference in ext4 during RCU pathwalk when ext4_put_super frees sbi and percpu counters without a grace period, allowing concurrent ext4_get_link to dereference freed or NULL s_fs_info.

Why it matters to the business

Kernel crashes or panics can occur during unmount of ext4 filesystems when last references are dropped outside normal namespace unlock paths, leading to unplanned downtime on systems using ext4.

How an attack unfolds

An attacker triggers a race by holding a pathwalk (such as via fstatat on a symlink) in ext4_get_link while the final reference to the mount is released via close or chdir on a lazily unmounted directory, causing the walker to access freed sbi structures.

How to fix it

Apply the upstream fix that moves sbi and extent status counter freeing after a grace period and splits counters from ext4_es_unregister_shrinker; rebuild and reboot to the patched kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting ext4_put_super and ext4_es_unregister_shrinker for grace-period delayed freeing of sbi; test by reproducing the described race on a patched kernel and verifying absence of KASAN reports.

Typical attack path

  1. Mount an ext4 filesystem and create symlinks
  2. Initiate a slow pathwalk that enters ext4_get_link under RCU
  3. Drop the final mount reference outside normal unmount (close file or chdir from lazy unmount)
  4. Trigger dereference of freed s_fs_info or destroyed counters in ext4_getblk or ext4_es_lookup_extent

How to detect it

Review kernel logs for KASAN null-ptr-deref reports with stack traces containing ext4_get_link, pick_link, and ext4_getblk; correlate with ext4 unmount events and lazy unmount activity.

What your security team should do

  • Prioritize kernel updates for all systems using ext4
  • Monitor for ext4 unmount-related kernel panics in production workloads
  • Audit scripts or services that perform lazy unmounts or chdir operations on ext4 mounts

The record

In the Linux kernel, the following vulnerability has been resolved: ext4: free the sbi after a grace period ext4_get_link() follows a symlink that keeps its target in a data block in rcu pathwalk mode with ext4_getblk(EXT4_GET_BLOCKS_CACHED_NOWAIT). That reads s_mount_state in the ASSERT() of ext4_getblk() and again in ext4_es_lookup_extent(), and the lookup bumps the extent status hit or miss counter, all through sb->s_fs_info. ext4_put_super() destroys those counters, clears sb->s_fs_info and frees the sbi without waiting for a grace period. A pathwalk that is still in ext4_get_link() when the last reference to the mount goes away then dereferences a NULL s_fs_info, the freed sbi or the destroyed percpu counters. With a pathwalk held up in ext4_get_link() while the last reference goes away: KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] RIP: 0010:ext4_getblk+0xf0/0x640 Call Trace: <TASK> ext4_get_link+0x26c/0x410 pick_link+0xf96/0x1780 step_into_slowpath+0x9b8/0x1250 path_lookupat+0x484/0xb00 filename_lookup+0x1f1/0x5b0 vfs_statx+0xd7/0x3b0 vfs_fstatat+0x4d/0x90 __do_sys_newfstatat+0xa0/0x100 do_syscall_64+0x10e/0x5e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f So far that has been hard to hit. umount(2) waits for a grace period in namespace_unlock() before it drops the mount, so only a mount whose last reference goes away elsewhere, like the close of a file or a chdir out of a lazily unmounted directory, can race a walker. Keep sb->s_fs_info and free the sbi together with the extent status counters after a grace period. Split the counters out of ext4_es_unregister_shrinker() for that. The shrinker still gets wasted in ext4_put_super(), the counters go with the sbi.

Affected packages

Ecosystem Package Introduced Fixed