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

CVE-2026-74619

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 /> ovl: 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 ovl_fill_super():<br /> create a user and a mount namespace in a child, call fsopen("overlay")<br /> there, send the fscontext fd to the parent and let the parent issue<br /> FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no<br /> capability is needed anywhere:<br /> <br /> WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]<br /> CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn<br /> Call Trace:<br /> get_tree_nodev+0x71/0xa0<br /> ovl_get_tree+0x15/0x20 [overlay]<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. ovl_parse_param()<br /> already spells a user namespace check this way for Opt_override_creds.

Impacto