Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2026-74618

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
22/08/2026
Última modificación:
22/08/2026

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: don&amp;#39;t warn when the mount is completed from another user namespace<br /> <br /> fsopen() records the caller&amp;#39;s user namespace in fc-&gt;user_ns and hands<br /> back an ordinary file descriptor. Nothing ties the task that calls<br /> fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The<br /> fd is inherited across fork() and exec() and it can be passed over a<br /> unix socket.<br /> <br /> Completing a context from another user namespace is allowed on purpose.<br /> vfs_cmd_create() authorizes the create with mount_capable(), which for<br /> FS_USERNS_MOUNT checks ns_capable(fc-&gt;user_ns, CAP_SYS_ADMIN), and that<br /> succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-&gt;user_ns.<br /> So an unprivileged task can reach the WARN_ON() in bm_fill_super():<br /> create a user and a mount namespace in a child, call<br /> fsopen("binfmt_misc") there, send the fscontext fd to the parent and let<br /> the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain<br /> unshare(1) and no capability is needed anywhere:<br /> <br /> WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc]<br /> CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn<br /> Call Trace:<br /> get_tree_keyed+0x7d/0xb0<br /> bm_get_tree+0x34/0x90 [binfmt_misc]<br /> vfs_get_tree+0x2a/0x100<br /> vfs_cmd_create+0x60/0xf0<br /> __do_sys_fsconfig+0x4b2/0x500<br /> <br /> The child needs the mount namespace because fsopen() itself gates on<br /> may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning<br /> the caller&amp;#39;s mount namespace. fsconfig() doesn&amp;#39;t repeat that check.<br /> <br /> It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be<br /> raised in a loop to taint the kernel and flood the log, and it panics a<br /> kernel booted with panic_on_warn.<br /> <br /> Keep refusing the mount and stop warning about it. Nothing in<br /> bm_fill_super() depends on the two namespaces matching, it derives<br /> everything from sb-&gt;s_user_ns.

Impacto