CVE-2026-74619: ovl: don't warn when the mount is completed from another user namespace
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->userns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIGCMDCREATE) 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. vfscmdcreate() authorizes the create with mountcapable(), which for FSUSERNSMOUNT checks nscapable(fc->userns, CAPSYSADMIN), and that succeeds for a task holding CAPSYSADMIN in an ancestor of fc->userns. So an unprivileged task can reach the WARNON() in ovlfillsuper(): 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 FSCONFIGCMDCREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere:
WARNING: fs/overlayfs/super.c:1551 at ovlfillsuper+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: gettreenodev+0x71/0xa0 ovlgettree+0x15/0x20 [overlay] vfsgettree+0x2a/0x100 vfscmdcreate+0x60/0xf0 dosysfsconfig+0x4b2/0x500
The child needs the mount namespace because fsopen() itself gates on maymount(), which asks for CAPSYSADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check.
It is a WARNON() and not a WARNONONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with paniconwarn.
Keep refusing the mount and stop warning about it. ovlparseparam() already spells a user namespace check this way for Optoverridecreds.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
Who can trigger the warning condition?
An unprivileged local task can trigger it. The described path uses only user and mount namespaces created with plain unshare(1), with no capabilities required.
What access or setup is needed to reproduce it?
An attacker needs local code execution and the ability to create user and mount namespaces. They create an overlay fscontext in a child user namespace, pass the fscontext file descriptor to a parent, and have the parent issue FSCONFIG_CMD_CREATE.
Is completing an fscontext from a different user namespace itself prohibited?
No. The kernel intentionally permits a context to be completed by a task in another user namespace, including when the fscontext file descriptor is inherited through fork or exec or passed over a Unix socket.
What observable sign indicates the issue was triggered?
The kernel emits a WARNING from ovl_fill_super() in fs/overlayfs/super.c, with a call trace involving get_tree_nodev and ovl_get_tree.