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: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Apply Update
AI Analysis

Impact

This vulnerability resides in the binfmt_misc subsystem of the Linux kernel. A warning is emitted in bm_fill_super when a user creates a binfmt_misc context in one user namespace and later completes the mount in a different namespace without proper validation. The warning is not once‑only, so a malicious user can trigger it repeatedly, causing kernel taint, excessive log traffic, and on systems configured with panic_on_warn the kernel may panic, effectively denying service.

Affected Systems

The flaw affects all Linux kernel builds that include the binfmt_misc code path described in the CVE. No specific kernel version is listed, so any kernel lacking the upstream fix is potentially vulnerable.

Risk and Exploitability

The CVSS score is 5.5 and the EPSS score is below 1%, indicating a moderate severity and a low probability of widespread exploitation. The issue is not in the CISA KEV catalog. Attackers need only ordinary user privileges and the ability to invoke unshare(1) to create a user and mount namespace, then use fsopen and fsconfig to provoke the warning. The local nature of the vulnerability limits impact to the compromised host, but repeated exploitation can exhaust logging resources, trigger kernel taint, and on certain configurations cause a kernel panic, leading to a denial of service.

Generated by OpenCVE AI on August 25, 2026 at 16:02 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that contains the upstream fix for the binfmt_misc warning handling.
  • If updating is not immediately possible, disable or restrict usage of binfmt_misc in the system configuration to prevent the vulnerable code path from being exercised.
  • Configure the kernel parameter panic_on_warn to 0 to avoid system crashes when the warning occurs.
  • Enforce security controls such as SELinux or AppArmor to limit unshare(1) and user namespace creation by ordinary users.

Generated by OpenCVE AI on August 25, 2026 at 16:02 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6466-1 linux security update
History

Tue, 25 Aug 2026 14:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-639

Tue, 25 Aug 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-617
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


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

Severity : Moderate

Publid Date: 2026-08-22T00:00:00Z

Links: CVE-2026-74618 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-25T16:15:05Z

Weaknesses