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.
Published: 2026-08-22
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

This vulnerability involves the Linux kernel’s binfmt_misc subsystem. The flaw arises from a WARN_ON in bm_fill_super that is not tied to the same user namespace that created the binfmt_misc context. An attacker can create a context inside a user namespace, pass the context file descriptor to another process in a different namespace, and then trigger fsconfig to generate the warning. Because the warning is not once‑only, a malicious process can produce it repeatedly, tainting the kernel, flooding system logs, and on systems that have panic_on_warn enabled causing the kernel to panic. The vulnerability does not allow code execution, but it can disrupt system availability and integrity.

Affected Systems

The affected product is the Linux kernel’s binfmt_misc subsystem. No specific kernel version information is provided in the CVE data, so the flaw applies to any kernel build that implements the stated code paths.

Risk and Exploitability

The CVSS score is not available, and EPSS is not reported. The flaw is local; an attacker needs only ordinary user privileges and the ability to execute unshare(1) and socket operations. Because the warning can be triggered in a loop, a determined attacker can cause sustained log flooding, kernel taint, and a possible panic on systems configured with panic_on_warn, leading to a denial of service. Since the issue is not in CISA KEV and lacks an official fix, the exploitation likelihood is moderate to high for environments that enable the vulnerable feature.

Generated by OpenCVE AI on August 22, 2026 at 16:43 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Disable binfmt_misc if it is not required for your environment.
  • Configure the kernel with panic_on_warn set to 0 to avoid boot failure when the warning is triggered.
  • Apply any kernel updates that contain a patch for this issue once a vendor releases one; check the upstream commit logs for the fix.
  • Restrict the use of unshare(1) and creation of user namespaces via mandatory access controls such as SELinux or AppArmor to prevent unprivileged users from creating the required contexts.

Generated by OpenCVE AI on August 22, 2026 at 16:43 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 22 Aug 2026 17:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-639

Sat, 22 Aug 2026 15:45:00 +0000

Type Values Removed Values Added
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.
Title binfmt_misc: don't warn when the mount is completed from another user namespace
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-22T15:32:02.778Z

Reserved: 2026-08-15T05:44:03.921Z

Link: CVE-2026-74618

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-22T16:16:34.507

Modified: 2026-08-22T16:16:34.507

Link: CVE-2026-74618

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-22T16:45:03Z

Weaknesses
  • CWE-639

    Authorization Bypass Through User-Controlled Key