CVE-2026-74618: binfmt_misc: don't warn when the mount is completed from another user namespace

From: Greg Kroah-Hartman <[email protected]>

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

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

binfmt_misc: don't warn when the mount is completed from another user namespace

fsopen() records the caller's user namespace in fc->user_ns and hands
back an ordinary file descriptor. Nothing ties the task that calls
fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The
fd is inherited across fork() and exec() and it can be passed over a
unix socket.

Completing a context from another user namespace is allowed on purpose.
vfs_cmd_create() authorizes the create with mount_capable(), which for
FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that
succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns.
So an unprivileged task can reach the WARN_ON() in bm_fill_super():
create a user and a mount namespace in a child, call
fsopen("binfmt_misc") there, send the fscontext fd to the parent and let
the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain
unshare(1) and no capability is needed anywhere:

  WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc]
  CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn
  Call Trace:
   get_tree_keyed+0x7d/0xb0
   bm_get_tree+0x34/0x90 [binfmt_misc]
   vfs_get_tree+0x2a/0x100
   vfs_cmd_create+0x60/0xf0
   __do_sys_fsconfig+0x4b2/0x500

The child needs the mount namespace because fsopen() itself gates on
may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning
the caller's mount namespace. fsconfig() doesn't repeat that check.

It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be
raised in a loop to taint the kernel and flood the log, and it panics a
kernel booted with panic_on_warn.

Keep refusing the mount and stop warning about it. Nothing in
bm_fill_super() depends on the two namespaces matching, it derives
everything from sb->s_user_ns.

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


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

	Issue introduced in 6.7 with commit 21ca59b365c091d583f36ac753eaa8baf947be6f and fixed in 6.12.104 with commit 37cf5cf1320a84a17225a1690547b8a0812ca94e
	Issue introduced in 6.7 with commit 21ca59b365c091d583f36ac753eaa8baf947be6f and fixed in 6.18.45 with commit 24e95a24f151ce40d5fc1b3a6cefbcda8ded736c
	Issue introduced in 6.7 with commit 21ca59b365c091d583f36ac753eaa8baf947be6f and fixed in 7.1.9 with commit 047f927f54c6c17593e93aafe82dcb7acdda2a71
	Issue introduced in 6.7 with commit 21ca59b365c091d583f36ac753eaa8baf947be6f and fixed in 7.2 with commit 79fdf39f1a31f88cb3833b6f8091fbf6acdca2c6

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-74618
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/binfmt_misc.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/37cf5cf1320a84a17225a1690547b8a0812ca94e
	https://git.kernel.org/stable/c/24e95a24f151ce40d5fc1b3a6cefbcda8ded736c
	https://git.kernel.org/stable/c/047f927f54c6c17593e93aafe82dcb7acdda2a71
	https://git.kernel.org/stable/c/79fdf39f1a31f88cb3833b6f8091fbf6acdca2c6