GHSA-J34R-65F7-8J2Q
Vulnerability from github – Published: 2026-08-22 18:30 – Updated: 2026-08-22 18:30In 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.
{
"affected": [],
"aliases": [
"CVE-2026-74619"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-22T16:16:34Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\novl: don\u0027t warn when the mount is completed from another user namespace\n\nfsopen() records the caller\u0027s user namespace in fc-\u003euser_ns and hands\nback an ordinary file descriptor. Nothing ties the task that calls\nfsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The\nfd is inherited across fork() and exec() and it can be passed over a\nunix socket.\n\nCompleting a context from another user namespace is allowed on purpose.\nvfs_cmd_create() authorizes the create with mount_capable(), which for\nFS_USERNS_MOUNT checks ns_capable(fc-\u003euser_ns, CAP_SYS_ADMIN), and that\nsucceeds for a task holding CAP_SYS_ADMIN in an ancestor of fc-\u003euser_ns.\nSo an unprivileged task can reach the WARN_ON() in ovl_fill_super():\ncreate a user and a mount namespace in a child, call fsopen(\"overlay\")\nthere, send the fscontext fd to the parent and let the parent issue\nFSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no\ncapability is needed anywhere:\n\n WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay]\n CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn\n Call Trace:\n get_tree_nodev+0x71/0xa0\n ovl_get_tree+0x15/0x20 [overlay]\n vfs_get_tree+0x2a/0x100\n vfs_cmd_create+0x60/0xf0\n __do_sys_fsconfig+0x4b2/0x500\n\nThe child needs the mount namespace because fsopen() itself gates on\nmay_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning\nthe caller\u0027s mount namespace. fsconfig() doesn\u0027t repeat that check.\n\nIt is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be\nraised in a loop to taint the kernel and flood the log, and it panics a\nkernel booted with panic_on_warn.\n\nKeep refusing the mount and stop warning about it. ovl_parse_param()\nalready spells a user namespace check this way for Opt_override_creds.",
"id": "GHSA-j34r-65f7-8j2q",
"modified": "2026-08-22T18:30:27Z",
"published": "2026-08-22T18:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74619"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/42d99fcd8006007e2f708bede6789f37f3910b30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/494346f2aab2489d379d43ff614aea447cf4e94d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/513478092966dc9818d96dd2b3ed613fd2f6e30e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63981fc786daaa626cb14d9be1406f674d79f98f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be161fa31e3e9cc828a3c1bd935edca461e8a7a1"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.