Live › vulnerability › CVE-2026-99174
Go to dashboardWhen an ext4 filesystem unmounts while a path lookup is following a symlink, the kernel can read freed or cleared mount state, causing a null pointer dereference. The sources describe a kernel crash and do not describe an attacker gaining code execution or data access.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
Systems running Linux kernels with ext4 mounts where filesystems are unmounted or have their last reference dropped while other processes are doing path lookups. The sources do not describe a specific configuration or deployment. Hosts that use only other filesystems, or that never unmount ext4 volumes under load, are unlikely to be exposed.
No product ranges from the sources yet.
uname -r to see the running kernel versiongrep -i ext4 /proc/filesystems to confirm the ext4 driver is presentEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99174")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.