CVE-2026-74619
ovl: don't warn when the mount is completed from another user namespace
Description
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.
INFO
Published Date :
Aug. 22, 2026, 4:16 p.m.
Last Modified :
Aug. 22, 2026, 4:16 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products
The following products are affected by CVE-2026-74619
vulnerability.
Even if cvefeed.io is aware of the exact versions of the
products
that
are
affected, the information is not represented in the table below.
No affected product recoded yet
Solution
- Apply kernel patches to update overlayfs behavior.
- Ensure proper user namespace handling in mount operations.
- Avoid completing mounts from different user namespaces.
- Test system stability after applying updates.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-74619.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-74619 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-74619
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-74619 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-74619 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 22, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '1784fbc2ed9c888ea4e895f30a53207ed7ee8208', 'lessThan': '513478092966dc9818d96dd2b3ed613fd2f6e30e', 'versionType': 'git'}, {'status': 'affected', 'version': '1784fbc2ed9c888ea4e895f30a53207ed7ee8208', 'lessThan': '494346f2aab2489d379d43ff614aea447cf4e94d', 'versionType': 'git'}, {'status': 'affected', 'version': '1784fbc2ed9c888ea4e895f30a53207ed7ee8208', 'lessThan': 'be161fa31e3e9cc828a3c1bd935edca461e8a7a1', 'versionType': 'git'}, {'status': 'affected', 'version': '1784fbc2ed9c888ea4e895f30a53207ed7ee8208', 'lessThan': '42d99fcd8006007e2f708bede6789f37f3910b30', 'versionType': 'git'}, {'status': 'affected', 'version': '1784fbc2ed9c888ea4e895f30a53207ed7ee8208', 'lessThan': '63981fc786daaa626cb14d9be1406f674d79f98f', 'versionType': 'git'}], 'programFiles': ['fs/overlayfs/super.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '6.5'}, {'status': 'unaffected', 'version': '0', 'lessThan': '6.5', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '6.6.152', 'versionType': 'semver', 'lessThanOrEqual': '6.6.*'}, {'status': 'unaffected', 'version': '6.12.104', 'versionType': 'semver', 'lessThanOrEqual': '6.12.*'}, {'status': 'unaffected', 'version': '6.18.45', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '7.1.9', 'versionType': 'semver', 'lessThanOrEqual': '7.1.*'}, {'status': 'unaffected', 'version': '7.2', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['fs/overlayfs/super.c'], 'defaultStatus': 'affected'}] Added Description 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. Added Reference https://git.kernel.org/stable/c/42d99fcd8006007e2f708bede6789f37f3910b30 Added Reference https://git.kernel.org/stable/c/494346f2aab2489d379d43ff614aea447cf4e94d Added Reference https://git.kernel.org/stable/c/513478092966dc9818d96dd2b3ed613fd2f6e30e Added Reference https://git.kernel.org/stable/c/63981fc786daaa626cb14d9be1406f674d79f98f Added Reference https://git.kernel.org/stable/c/be161fa31e3e9cc828a3c1bd935edca461e8a7a1