namespace: handle mount locking for automounts correctly
Severity and exploitation
KEV coverage does not rule out exploitation.
Severity
unknownCVSS measures technical severity, not the likelihood of an attack.
Known exploitation
Not listed in the checked CISA KEV catalog
Absence from CISA KEV does not rule out attacks.
Public exploit
Not established by this record
Missing evidence does not mean no public exploit exists.
Remediation
Fix status not established
No structured fix or guidance is available here. Check the latest publisher advisory.
What this means
In the Linux kernel, the following vulnerability has been resolved:
Source excerpt · LinuxAttack conditions
No attack-condition excerpt has been identified here. Review the full source description and references for authentication, network access, and configuration requirements.
Review supporting sources →Affected versions
Check the exact model, release, and any platform requirements against your installation.
Linux · Linux
Linux
10 ranges
Linux · Linux
Linux
Compare with this publisher’s ranges. This does not inspect your installation.
affected
132c94e31b8bca8ea921f9f96a57d684fa4ae0a9 → before f9b488641cfa63f9b41321530c543688b2e34f03
git versions
132c94e31b8bca8ea921f9f96a57d684fa4ae0a9 → before 91676705756af6a59a515087b8b854c8a28d12eb
git versions
132c94e31b8bca8ea921f9f96a57d684fa4ae0a9 → before 587d25c4b13d49c8fd05df2f71240f73bb2a058c
git versions
132c94e31b8bca8ea921f9f96a57d684fa4ae0a9 → before 5e8f3ac8fa3d411b422ad32b9168c46a4824cc79
git versions
132c94e31b8bca8ea921f9f96a57d684fa4ae0a9 → before b3ccde78f1608836e62320428abc0e8aa9cf2329
git versions
132c94e31b8bca8ea921f9f96a57d684fa4ae0a9 → before e01c79761c7b3373e80094c5eadb21cb864fa8bc
git versions
132c94e31b8bca8ea921f9f96a57d684fa4ae0a9 → before 6ab37fae14196ba2262b152a7d9222c50356d278
git versions
132c94e31b8bca8ea921f9f96a57d684fa4ae0a9 → before 33aadc7c72055fca93cb5a3691d836ebf8b31c9b
git versions
9c773201d61272db49f8f33a83a3cb2a3fe4b14f
git versions
3.8.6 → before 3.9
semver versions
Other versions: unaffected
Linux · Linux
Linux
10 ranges
Linux · Linux
Linux
Compare with this publisher’s ranges. This does not inspect your installation.
affected
3.9
unaffected
0 → before 3.9
semver versions
5.10.273 → through 5.10.*
semver versions
5.15.224 → through 5.15.*
semver versions
6.1.191 → through 6.1.*
semver versions
6.6.160 → through 6.6.*
semver versions
6.12.114 → through 6.12.*
semver versions
6.18.57 → through 6.18.*
semver versions
7.2.11 → through 7.2.*
semver versions
7.3 → through *
original_commit_for_fix versions
Other versions: affected
What to do
Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.
No structured fix or remediation guidance is available here. Check the full source description and vendor’s latest advisory for a patch or workaround; do not assume another version is safe.
cve.new guidance unless attributed to a publisher. This page does not inspect your installation.
Public exploit evidence
No public exploit reference is identified in the imported evidence. This is not a claim that no exploit exists.
Original source description
Read the full publisher description
In the Linux kernel, the following vulnerability has been resolved:
namespace: handle mount locking for automounts correctly
If mounts are propagated across user namespaces, attach_recursive_mnt() locks every copy of the source mount to protect overmounts from vanishing and revealing the underlying files or directories.
The user namespace is taken from the caller's mount namespaces since this is where the mounts end up. Except, that's not always true. Automounts may legitimately get popped in by tasks located in a different mount and user namespace during path lookup.
Then check doesn't make sense at that point. The copy in the namespace of the parent - which may be the host's - is now locked and the host cannot change the flags of its own mounts anymore.
Here's the reproducer:
-
host has debugfs mounted nosuid,nodev,noexec and shared
-
tracefs automount below it is not yet active
-
hand a child process a directory descriptor on that mount
-
child process enters auser and mount namespace
-
child process' namespace now holds a locked copy of the host's debugfs mount that receives propagation from it
-
child process stats "tracing/." through the descriptor
-
lookup runs on the host's mount so the automount lands below the host's mount
-
propagation puts a copy below the child's copy
-
both try to clear the flags on the mount they got, with a bind remount:
host, on its own automount: MS_REMOUNT|MS_BIND = EPERM child, on the copy in its namespace: MS_REMOUNT|MS_BIND = 0
So the lock landed on the host's mount instead of the child's copy. Congrats. So we need to compare with the owner of the namespace the mount actually gets mounted on. For all regular cases that is the caller's mount namespace and so nothing changes.
Detached trees in anonymous mount namespaces by be handed over via SCM_RIGHTS or inherited in other ways on purpose so the attaching task's mount namespace is authoritative, not the creator of the detached tree.
References
8 sourcesInside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-98977View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Environment requirements
These conditions apply together as specified by the publisher. A matching product name alone does not establish exposure.
Linux · platform conditions
Any condition may hold
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.9
Before: 5.10.273
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.9
Before: 5.15.224
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.9
Before: 6.1.191
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.9
Before: 6.6.160
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.9
Before: 6.12.114
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.9
Before: 6.18.57
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.9
Before: 7.2.11
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.9
Before: 7.3
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 3.8.6
Applicability preview
[
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.9",
"versionEndExcluding": "5.10.273"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.9",
"versionEndExcluding": "5.15.224"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.9",
"versionEndExcluding": "6.1.191"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.9",
"versionEndExcluding": "6.6.160"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.9",
"versionEndExcluding": "6.12.114"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.9",
"versionEndExcluding": "6.18.57"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.9",
"versionEndExcluding": "7.2.11"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.9",
"versionEndExcluding": "7.3"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.8.6"
}
]
}
]
}
]Contributing organizations · 1
Assigning organization
Timeline
All times UTCAdvisory published
Publication date supplied by the source.
Source updated
Latest modification date supplied by the source.
Last imported by cve.new
Latest catalog import, not the date we first saw this advisory.
What changed
Follow changesLarge field values are marked as truncated previews. Original source snapshots remain retained.