Re: [PATCH] fhandle: reject detached mounts in capable_wrt_mount()

Jeff Layton <[email protected]>
Newsgroups gmane.linux.kernel.stable,gmane.linux.file-systems,gmane.linux.nfs,gmane.linux.kernel
Message-ID <[email protected]>
On Wed, 2026-07-01 at 11:44 +0000, David Lee wrote:
> The recent fhandle RCU fix moved the mount namespace capability check
> into capable_wrt_mount(), so a non-NULL mnt_namespace survives the
> ns_capable() dereference. The helper still assumes the later
> READ_ONCE(mount->mnt_ns) must be non-NULL because may_decode_fh()
> checked is_mounted() first.
> 
> That assumption is not stable. A detached mount from
> open_tree(..., OPEN_TREE_CLONE) can be dissolved on fput while
> open_by_handle_at() is between those checks, and umount_tree() can
> clear mount->mnt_ns. If the helper observes NULL, it dereferences
> mnt_ns->user_ns and panics.
> 
> Return false when the RCU read observes a detached mount. This keeps
> the relaxed permission path conservative: a mount no longer attached
> to a namespace cannot authorize open_by_handle_at() access.
> 
> Fixes: 620c266f3949 ("fhandle: relax open_by_handle_at() permission checks")
> Cc: [email protected]
> Signed-off-by: David Lee <[email protected]>
> Assisted-by: Codex:gpt-5
> ---
> Bug found and triaged by David Lee from Trail of Bits.
> 
> Trail of Bits has a minimal PoC that triggers this crash on a custom
> kernel build, which can be shared further if needed.
> 
>  fs/fhandle.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/fhandle.c b/fs/fhandle.c
> index 1ca7eb3a6cb5..f8829231e3d7 100644
> --- a/fs/fhandle.c
> +++ b/fs/fhandle.c
> @@ -295,7 +295,7 @@ static bool capable_wrt_mount(struct mount *mount)
>  	 */
>  	guard(rcu)();
>  	mnt_ns = READ_ONCE(mount->mnt_ns);
> -	return ns_capable(mnt_ns->user_ns, CAP_SYS_ADMIN);
> +	return mnt_ns && ns_capable(mnt_ns->user_ns, CAP_SYS_ADMIN);
>  }
>  
>  static inline int may_decode_fh(struct handle_to_path_ctx *ctx,

Seems sane.

Reviewed-by: Jeff Layton <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.