UBUNTU-CVE-2026-99171: Use After Free
In the Linux kernel, the following vulnerability has been resolved: ntfs3: free the sbi after a grace period If the "nocase" mount option ntfs3 uses custom hash and dentry compare functions. Both access ntfs3 superblock private information in rcu pathwalk. ntfsputsuper() and ntfs3killsb() drop the info without any rcu delay. A lookup that's still inside the filesystem when the last reference to the mount is dropped causes a UAF. With a pathwalk held up in ntfsdhash() while the last reference to the mount goes away: BUG: KASAN: slab-use-after-free in ntfsnlstoutf16+0x752/0x940 Read of size 8 at addr ff1100010453c850 by task walker/99 Call Trace: <TASK> ntfsnlstoutf16+0x752/0x940 ntfsdhash+0x22b/0x500 linkpathwalk+0x11ad/0x1d30 pathlookupat+0x63/0xb00 filenamelookup+0x1f1/0x5b0 vfsstatx+0xd7/0x3b0 [...] Allocated by task 95: kmalloccachenoprof+0x249/0x560 ntfsinitfscontext+0x2db/0x5a0 allocfscontext+0x52e/0xc70 [...] Freed by task 98: kfree+0x1db/0x5b0 deactivatelockedsuper+0x9c/0xf0 cleanupmnt+0x9f/0x130 taskworkrun+0x131/0x250 The bug is currently masked by the grace period in namespaceunlock() for umount(2). Keep the necessary information until the filesystem private info is freed and free it with an rcu delay. ntfs3freesbi() now runs from an rcu callback and drops the upcase table via ntfsputshared(). So switch ssharedlock over to spinlockbh(). Otherwise the callback can deadlock against a task holding the lock on the same cpu.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected condition is specific to ntfs3 mounts using the "nocase" mount option. The listed Ubuntu kernel packages include linux, linux-aws, linux-azure, linux-azure-fde, linux-gcp, linux-gke, linux-realtime, and linux-riscv.
What race is required to trigger the use-after-free?
A lookup must still be traversing the ntfs3 filesystem in the RCU pathwalk while the last reference to that mount is dropped. In the reported scenario, the lookup is held in ntfs_d_hash() as the mount is being torn down.
What can be done if a fixed kernel is not immediately available?
Avoid mounting ntfs3 filesystems with the "nocase" option where possible. The vulnerable custom hash and dentry comparison functions are used when that option is enabled.
How might this appear during investigation?
Kernel memory checking may report a KASAN slab-use-after-free in ntfs_nls_to_utf16(), reached from ntfs_d_hash() during path lookup. The freeing path can include deactivate_locked_super(), cleanup_mnt(), and task_work_run().