CVE-2026-74619 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
ovl: 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 ovl_fill_super(): create a user and a mount namespace in a child, call fsopen("overlay") 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/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]
CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay]
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. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel's overlay filesystem implementation contained a logic flaw related to how file descriptors are handled across different user namespaces during the mounting process. The vulnerability stems from the behavior of the fsopen system call, which records the caller's current user namespace in the file context and returns an ordinary file descriptor. This design allows the file descriptor representing the mount context to be inherited through fork or exec calls, or passed between processes via Unix domain sockets. Consequently, a task that did not originally create the filesystem context can attempt to complete the mounting operation by issuing the FSCONFIG_CMD_CREATE command. While the virtual file system layer correctly authorizes this action using mount_capable with ns_capable checks for CAP_SYS_ADMIN in the original user namespace, the overlay filesystem code itself contained an overly restrictive check that did not account for legitimate cross-namespace usage patterns.
This discrepancy resulted in a false positive warning being triggered within the ovl_fill_super function when a mount was completed from a different user namespace than the one used to open the context. The issue is particularly exploitable because it can be triggered by unprivileged users under specific conditions. An attacker or misconfigured application could create separate user and mount namespaces in a child process, invoke fsopen for an overlay filesystem within that restricted environment, pass the resulting file descriptor back to a parent process, and have the parent complete the mount operation. Since both namespaces are derived from standard unshare operations without requiring elevated capabilities at each step, this flow is valid according to kernel security policies but incorrectly flagged as anomalous by the overlayfs driver code.
The operational impact of this vulnerability includes significant denial-of-service potential through log flooding and system instability. Because the flaw triggers a WARN_ON macro rather than a WARN_ON_ONCE variant, repeated attempts can generate continuous warning messages that taint the kernel state and fill up system logs rapidly. In environments where the kernel is configured with panic_on_warn enabled, these false positives will cause immediate kernel panics and system reboots. This behavior disrupts service availability and degrades system reliability without requiring any actual privilege escalation or data exfiltration capabilities from the attacker.
To mitigate this issue, the overlay filesystem code was updated to explicitly allow mounting contexts that were created in a different user namespace than where they are being finalized, provided the necessary capability checks pass at the virtual file system level. The fix aligns the behavior of ovl_fill_super with other parts of the overlayfs parameter parsing logic, such as Opt_override_creds, which already correctly handle cross-namespace scenarios. This change ensures that legitimate administrative workflows involving namespace isolation and delegation are not interrupted by spurious warnings or crashes.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding the failure to properly validate input parameters in relation to their context of origin. The incorrect assumption about user namespace consistency represents a logic error in security boundary enforcement. In terms of attack vectors, this relates to ATT&CK technique T1496 Resource Hijacking via denial-of-service conditions caused by kernel-level instability. By resolving the false positive warning and preventing unnecessary kernel tainting or panics, the patch restores stability for systems relying on complex namespace-based containerization strategies while maintaining strict security controls over mount operations.