VulnerabilityPublished 28 Oct 2026

CVE-2026-99174: Linux kernel · ext4: free the sbi after a grace period

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in c17b44266a1f9fcb49b894d4611d1254bf1aa313 : update Linux kernel when convenient.

Data as of 28 Oct 2026, 10:58 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

Patch: Available – fixed in c17b44266a1f9fcb49b894d4611d1254bf1aa313, 87d29b8b849738d52fe820d495fa0aa2d5a1ec82, 80d5db1686b05fad6f384be017714297d828a714

Exploitation evidence

Disclosed: evidence found.
CVE published 28 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade Linux kernel to c17b44266a1f9fcb49b894d4611d1254bf1aa313, 87d29b8b849738d52fe820d495fa0aa2d5a1ec82 or 80d5db1686b05fad6f384be017714297d828a714.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 6493792d3299b3e33f887ef8a150099d271faf9c, < c17b44266a1f9fcb49b894d4611d1254bf1aa313	Fixed in c17b44266a1f9fcb49b894d4611d1254bf1aa313
LinuxLinux	Affected ≥ 6493792d3299b3e33f887ef8a150099d271faf9c, < 87d29b8b849738d52fe820d495fa0aa2d5a1ec82	Fixed in 87d29b8b849738d52fe820d495fa0aa2d5a1ec82
LinuxLinux	Affected ≥ 6493792d3299b3e33f887ef8a150099d271faf9c, < 80d5db1686b05fad6f384be017714297d828a714	Fixed in 80d5db1686b05fad6f384be017714297d828a714
LinuxLinux	Affected =5.19	Fixed in–
Red Hatredhat/kernel`pkg:rpm/redhat/kernel`Other threats	Affected =5.19	Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

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.

References

Community reviews

Loading reviews…