FKIE_CVE-2026-74619
Vulnerability from fkie_nvd - Published: 2026-08-22 16:16 - Updated: 2026-10-14 13:10
Severity
Summary
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/overlayfs/super.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "513478092966dc9818d96dd2b3ed613fd2f6e30e",
"status": "affected",
"version": "1784fbc2ed9c888ea4e895f30a53207ed7ee8208",
"versionType": "git"
},
{
"lessThan": "494346f2aab2489d379d43ff614aea447cf4e94d",
"status": "affected",
"version": "1784fbc2ed9c888ea4e895f30a53207ed7ee8208",
"versionType": "git"
},
{
"lessThan": "be161fa31e3e9cc828a3c1bd935edca461e8a7a1",
"status": "affected",
"version": "1784fbc2ed9c888ea4e895f30a53207ed7ee8208",
"versionType": "git"
},
{
"lessThan": "42d99fcd8006007e2f708bede6789f37f3910b30",
"status": "affected",
"version": "1784fbc2ed9c888ea4e895f30a53207ed7ee8208",
"versionType": "git"
},
{
"lessThan": "63981fc786daaa626cb14d9be1406f674d79f98f",
"status": "affected",
"version": "1784fbc2ed9c888ea4e895f30a53207ed7ee8208",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/overlayfs/super.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.5"
},
{
"lessThan": "6.5",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.152",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.104",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.45",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.1.*",
"status": "unaffected",
"version": "7.1.9",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.2",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\novl: no advertir cuando el montaje se completa desde otro espacio de nombres de usuario\n\nfsopen() registra el espacio de nombres de usuario del llamador en fc -\u003e user_ns y devuelve un descriptor de archivo ordinario. Nada vincula la tarea que llama a fsconfig(FSCONFIG_CMD_CREATE) con la tarea que cre\u00f3 el contexto. El fd se hereda a trav\u00e9s de fork() y exec() y puede pasarse a trav\u00e9s de un socket unix.\n\nCompletar un contexto desde otro espacio de nombres de usuario est\u00e1 permitido a prop\u00f3sito. vfs_cmd_create() autoriza la creaci\u00f3n con mount_capable(), que para FS_USERNS_MOUNT comprueba ns_capable(fc -\u003e user_ns, CAP_SYS_ADMIN), y eso tiene \u00e9xito para una tarea que posee CAP_SYS_ADMIN en un ancestro de fc -\u003e user_ns. As\u00ed, una tarea sin privilegios puede alcanzar el WARN_ON() en ovl_fill_super(): crear un espacio de nombres de usuario y de montaje en un hijo, llamar a fsopen(\u0027overlay\u0027) all\u00ed, enviar el fd del fscontext al padre y dejar que el padre emita FSCONFIG_CMD_CREATE. Ambos espacios de nombres provienen de un simple unshare(1) y no se necesita ninguna capacidad en ning\u00fan lugar:\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\nEl hijo necesita el espacio de nombres de montaje porque fsopen() mismo se basa en may_mount(), que solicita CAP_SYS_ADMIN en el espacio de nombres de usuario propietario del espacio de nombres de montaje del llamador. fsconfig() no repite esa comprobaci\u00f3n.\n\nEs un WARN_ON() y no un WARN_ON_ONCE(), por lo que la condici\u00f3n puede ser elevada en un bucle para corromper el kernel e inundar el registro, y provoca un p\u00e1nico en un kernel arrancado con panic_on_warn.\n\nSeguir rechazando el montaje y dejar de advertir al respecto. ovl_parse_param() ya especifica una comprobaci\u00f3n del espacio de nombres de usuario de esta manera para Opt_override_creds."
}
],
"id": "CVE-2026-74619",
"lastModified": "2026-10-14T13:10:00.187",
"metrics": {},
"published": "2026-08-22T16:16:34.623",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/42d99fcd8006007e2f708bede6789f37f3910b30"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/494346f2aab2489d379d43ff614aea447cf4e94d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/513478092966dc9818d96dd2b3ed613fd2f6e30e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/63981fc786daaa626cb14d9be1406f674d79f98f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/be161fa31e3e9cc828a3c1bd935edca461e8a7a1"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
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.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.