CVE-2026-53341

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fhandle: fix UAF due to unlocked -&gt;mnt_ns read in may_decode_fh()<br /> <br /> may_decode_fh() accesses mount::mnt_ns without holding any locks; that<br /> means the mount can concurrently be unmounted, and the mnt_namespace can<br /> concurrently be freed after an RCU grace period.<br /> <br /> This race can happens as follows, assuming that the mount point was<br /> created by open_tree(..., OPEN_TREE_CLONE):<br /> <br /> thread 1 thread 2 RCU<br /> __do_sys_open_by_handle_at<br /> do_handle_open<br /> handle_to_path<br /> may_decode_fh<br /> is_mounted<br /> [mount::mnt_ns access]<br /> [mount::mnt_ns access]<br /> __do_sys_close<br /> fput_close_sync<br /> __fput<br /> dissolve_on_fput<br /> umount_tree<br /> class_namespace_excl_destructor<br /> namespace_unlock<br /> free_mnt_ns<br /> mnt_ns_tree_remove<br /> call_rcu(mnt_ns_release_rcu)<br /> mnt_ns_release_rcu<br /> mnt_ns_release<br /> kfree<br /> [mnt_namespace::user_ns access] **UAF**<br /> <br /> Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like<br /> in __prepend_path().<br /> Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE()<br /> for writers that can race with lockless readers.<br /> <br /> This bug is unreachable unless one of the following is set:<br /> <br /> - CONFIG_PREEMPTION<br /> - CONFIG_RCU_STRICT_GRACE_PERIOD<br /> <br /> because it requires an RCU grace period to happen during a syscall without<br /> an explicit preemption.<br /> <br /> This doesn&amp;#39;t seem to have interesting security impact; worst-case, it could<br /> leak the result of an integer comparison to userspace (from the level<br /> check in cap_capable()), cause an endless loop, or crash the kernel by<br /> dereferencing an invalid address.