CVE-2026-99174

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: 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.