CVE-2026-74618
Received Received - Intake

binfmt_misc User Namespace Mount Warning Fix

Publication date: 2026-08-22

Last updated on: 2026-08-22

Assigner: kernel.org

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-22
Last Modified
2026-08-22
Generated
2026-08-22
AI Q&A
2026-08-22
EPSS Evaluated
N/A
NVD
CVE-2026-74618
EUVD
EUVD-2026-64555

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves a warning triggered when a mount operation for binfmt_misc is completed from a different user namespace than the one that initiated it. The issue arises because fsopen() allows the file descriptor to be passed between processes, including across user namespaces, without proper authorization checks. This can lead to repeated warnings flooding the kernel log or causing a kernel panic if panic_on_warn is enabled.

Detection Guidance

This vulnerability is a kernel warning triggered by specific filesystem operations in binfmt_misc. Detection involves checking kernel logs for WARN_ON messages related to binfmt_misc or fs/binfmt_misc.c. Use commands like 'dmesg | grep binfmt_misc' or 'journalctl -k | grep binfmt_misc' to search for warnings.

Impact Analysis

An unprivileged user could exploit this to trigger repeated warnings or kernel panics by manipulating user and mount namespaces. This may disrupt system stability, fill logs with unnecessary warnings, or crash the system if panic_on_warn is active. However, it does not grant elevated privileges or direct access to sensitive data.

Compliance Impact

This vulnerability does not directly impact compliance with GDPR, HIPAA, or similar regulations as it does not involve data breaches or unauthorized access. However, system instability or crashes caused by repeated warnings could indirectly affect compliance by disrupting operations or logging mechanisms required for audit purposes.

Mitigation Strategies

Apply the latest kernel patches to resolve this issue. Monitor kernel logs for the WARN_ON message and avoid operations that trigger it. If the warning appears, update the kernel immediately to prevent potential log flooding or kernel panic in systems configured with panic_on_warn.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-74618. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart