CVE-2026-74619 - Vulnerability Details

- 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.

Published: 2026-08-22

Score: n/a

EPSS: n/a

KEV: No

Impact:

Action:

Analysis

Impact

An unprivileged user can create an overlay filesystem mount that triggers a WARN_ON in the kernel’s overlayfs code. Because the warning occurs in a loopable context and the kernel can be set to panic on every warning, this flaw permits a local user to cause a kernel crash or to flood the system log and taint the kernel. The vulnerability is a result of missing privilege checks on the user namespace used during fsconfig, effectively bypassing capability enforcement. The weakness maps to improper privilege management and failure to enforce access control, classified as CWE‑269 and CWE‑357.

Affected Systems

All supported Linux kernel releases that include overlayfs are affected; no specific version range is provided. The vulnerability applies to any system running a standard Linux kernel where overlayfs is enabled. It is independent of distribution or patch level unless the vendor has applied the upstream fix.

Risk and Exploitability

The flaw is exploitable locally from a normal user account: the user can create a new mount namespace with unshare(1), use fsopen to obtain a file descriptor for overlayfs, pass that descriptor to the parent process, and then issue fsconfig to finalize the mount. No extra privileges or capabilities are required. The EPSS score is not available, and the vulnerability is not listed in the CISA KEV catalog, but the potential to force a kernel crash or log flood makes it a high‑risk local denial of service. Attackers can repeat the operation to saturate log space, and on systems with panic_on_warn turned on the kernel will reboot, effectively pausing service. The lack of a mandatory access control check permits the exploit to be performed from user space without special permissions.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`1784fbc2ed9c888ea4e895f30a53207ed7ee8208`	affected	< 513478092966dc9818d96dd2b3ed613fd2f6e30e
`1784fbc2ed9c888ea4e895f30a53207ed7ee8208`	affected	< 494346f2aab2489d379d43ff614aea447cf4e94d
`1784fbc2ed9c888ea4e895f30a53207ed7ee8208`	affected	< be161fa31e3e9cc828a3c1bd935edca461e8a7a1
`1784fbc2ed9c888ea4e895f30a53207ed7ee8208`	affected	< 42d99fcd8006007e2f708bede6789f37f3910b30
`1784fbc2ed9c888ea4e895f30a53207ed7ee8208`	affected	< 63981fc786daaa626cb14d9be1406f674d79f98f

Linux

affected

Version	Status	Constraints
`6.5`	affected	—
`0`	unaffected	< 6.5
`6.6.152`	unaffected	≤ 6.6.*
`6.12.104`	unaffected	≤ 6.12.*
`6.18.45`	unaffected	≤ 6.18.*
`7.1.9`	unaffected	≤ 7.1.*
`7.2`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[1784fbc2ed9c888ea4e895f30a53207ed7ee8208,513478092966dc9818d96dd2b3ed613fd2f6e30e)`	affected	code_commit	—
`[1784fbc2ed9c888ea4e895f30a53207ed7ee8208,494346f2aab2489d379d43ff614aea447cf4e94d)`	affected	code_commit	—
`[1784fbc2ed9c888ea4e895f30a53207ed7ee8208,be161fa31e3e9cc828a3c1bd935edca461e8a7a1)`	affected	code_commit	—
`[1784fbc2ed9c888ea4e895f30a53207ed7ee8208,42d99fcd8006007e2f708bede6789f37f3910b30)`	affected	code_commit	—
`[1784fbc2ed9c888ea4e895f30a53207ed7ee8208,63981fc786daaa626cb14d9be1406f674d79f98f)`	affected	code_commit	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`6.5`	affected	semver	—
`[0,6.5)`	unaffected	semver	—
`[6.6.152,7.0.0)`	unaffected	semver	—
`[6.12.104,7.0.0)`	unaffected	semver	—
`[6.18.45,7.0.0)`	unaffected	semver	—
`[7.1.9,8.0.0)`	unaffected	semver	—
`[7.2,*]`	unaffected	semver	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

Apply a kernel update that incorporates the upstream fix for the overlayfs WARN_ON issue
If an update is not immediately available, temporarily set the kernel parameter panic_on_warn to 0 to prevent kernel crashes from occurring when the warning is triggered
Use privilege controls (e.g., SELinux, AppArmor, or container isolation) to restrict the use of unshare(1) and overlayfs mounting to privileged processes only

Generated by OpenCVE AI on August 22, 2026 at 16:42 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

No EPSS score available.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/42d99fcd8006007e2f708bede6789f37f3910b30
https://git.kernel.org/stable/c/494346f2aab2489d379d43ff614aea447cf4e94d
https://git.kernel.org/stable/c/513478092966dc9818d96dd2b3ed613fd2f6e30e
https://git.kernel.org/stable/c/63981fc786daaa626cb14d9be1406f674d79f98f
https://git.kernel.org/stable/c/be161fa31e3e9cc828a3c1bd935edca461e8a7a1

History

Sat, 22 Aug 2026 17:00:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-269 CWE-357

Sat, 22 Aug 2026 15:45:00 +0000

Type	Values Removed	Values 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.
Title		ovl: don't warn when the mount is completed from another user namespace
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/42d99fcd8006007e2f708bede6789f37f3910b30 https://git.kernel.org/stable/c/494346f2aab2489d379d43ff614aea447cf4e94d https://git.kernel.org/stable/c/513478092966dc9818d96dd2b3ed613fd2f6e30e https://git.kernel.org/stable/c/63981fc786daaa626cb14d9be1406f674d79f98f https://git.kernel.org/stable/c/be161fa31e3e9cc828a3c1bd935edca461e8a7a1

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-08-22T15:32:03.511Z

Updated: 2026-08-22T15:32:03.511Z

Reserved: 2026-08-15T05:44:03.921Z

Link: CVE-2026-74619

Vulnrichment

No data.

NVD

Status : Received

Published: 2026-08-22T16:16:34.623

Modified: 2026-08-22T16:16:34.623

Link: CVE-2026-74619

Redhat

No data.

OpenCVE Enrichment

Updated: 2026-08-22T18:15:03Z

Weaknesses

CWE-269
Improper Privilege Management
CWE-357
Insufficient UI Warning of Dangerous Operations

Impact

Affected Systems

Risk and Exploitability

Tracking

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object