AZL-97122

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(FSCONFIGCMD_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. 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 FSCONFIGCMD_CREATE. 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 CAPSYS_ADMIN 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 panicon_warn.

Keep refusing the mount and stop warning about it. ovlparseparam() already spells a user namespace check this way for Optoverridecreds.