CVE-2026-53341: fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()

CVE-2026-53341: fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()

may_decode_fh() accesses mount::mnt_ns without holding any locks; that
means the mount can concurrently be unmounted, and the mnt_namespace can
concurrently be freed after an RCU grace period.

This race can happens as follows, assuming that the mount point was
created by open_tree(..., OPEN_TREE_CLONE):

thread 1            thread 2            RCU
                    __do_sys_open_by_handle_at
                      do_handle_open
                        handle_to_path
                          may_decode_fh
                            is_mounted
                              [mount::mnt_ns access]
                            [mount::mnt_ns access]
__do_sys_close
  fput_close_sync
    __fput
      dissolve_on_fput
        umount_tree
        class_namespace_excl_destructor
          namespace_unlock
            free_mnt_ns
              mnt_ns_tree_remove
                call_rcu(mnt_ns_release_rcu)
                                        mnt_ns_release_rcu
                                          mnt_ns_release
                                            kfree
                            [mnt_namespace::user_ns access] **UAF**

Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like
in __prepend_path().
Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE()
for writers that can race with lockless readers.

This bug is unreachable unless one of the following is set:

 - CONFIG_PREEMPTION
 - CONFIG_RCU_STRICT_GRACE_PERIOD

because it requires an RCU grace period to happen during a syscall without
an explicit preemption.

This doesn't seem to have interesting security impact; worst-case, it could
leak the result of an integer comparison to userspace (from the level
check in cap_capable()), cause an endless loop, or crash the kernel by
dereferencing an invalid address.

The Linux kernel CVE team has assigned CVE-2026-53341 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.11 with commit 620c266f394932e5decc4b34683a75dfc59dc2f4 and fixed in 6.18.36 with commit 32138633e51e6db59e474765cf93268c92b42888
	Issue introduced in 6.11 with commit 620c266f394932e5decc4b34683a75dfc59dc2f4 and fixed in 7.0.13 with commit a8ed2c29fcfdac78db96c9da4e659c8a513f2a94
	Issue introduced in 6.11 with commit 620c266f394932e5decc4b34683a75dfc59dc2f4 and fixed in 7.1 with commit 40ab6644b99685755f740b872c00ef40d9aa870e

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-53341
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/fhandle.c
	fs/mount.h
	fs/namespace.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/32138633e51e6db59e474765cf93268c92b42888
	https://git.kernel.org/stable/c/a8ed2c29fcfdac78db96c9da4e659c8a513f2a94
	https://git.kernel.org/stable/c/40ab6644b99685755f740b872c00ef40d9aa870e