fs: don't silently unmount busy mounts
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
14 ranges
Linux · Linux
Linux
Compare with this publisher’s ranges. This does not inspect your installation.
affected
99b19d16471e9c3faa85cad38abc9cbbe04c6d55 → before 97c9ca40b67eafbe61a253e28cd51dddb7c6bec4
git versions
99b19d16471e9c3faa85cad38abc9cbbe04c6d55 → before bf2c8dec26fb792876b5e9bde7030c45d8be3908
git versions
99b19d16471e9c3faa85cad38abc9cbbe04c6d55 → before a210ac218c307513d43e98a08f23c2dfbeeebc2f
git versions
99b19d16471e9c3faa85cad38abc9cbbe04c6d55 → before 6857e209015f95be7a8f19a9cd5dac345b9b9859
git versions
dc5ce95b0252d143497283f7f659840d4f8a79d0
git versions
fdb8f10499924d96b8eb60cc1354b278f6fcf0e9
git versions
bb4fbf094b440a9209ed88c8681960d4b26eec0f
git versions
b43f81ef0babcc07db1eaaece37c989204e4ff00
git versions
81311d1698c0c87c972ba71d3ce44a617b52ea21
git versions
4.1.43 → before 4.2
semver versions
4.4.78 → before 4.5
semver versions
4.9.39 → before 4.10
semver versions
4.11.12 → before 4.12
semver versions
4.12.3 → before 4.13
semver versions
Other versions: unaffected
Linux · Linux
Linux
6 ranges
Linux · Linux
Linux
Compare with this publisher’s ranges. This does not inspect your installation.
affected
4.13
unaffected
0 → before 4.13
semver versions
6.12.117 → 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:
fs: don't silently unmount busy mounts
The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell.
It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore.
Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.") ended up adding covered mounts to both sides in one go.
Along came 99b19d16471e ("mnt: In propgate_umount handle visiting mounts in any order") and that started to unmount more than before:
[1]: A copy of a mount is unmounted when each of its children is either its overmount or a copy of the victim itself. In the former case the overmount gets reparented. In the latter case the copy of the victim will end up being unmounted.
So propagate_umount() ended up being rewritten without adjusting propagate_mount_busy(). And currently propagate_mount_busy() doesn't look at copies of the victim that have two or more children nor a single child that is not the overmount.
So any such copy in [1] is not checked for references. The result is that a synchronous unmount succeeds, pulling out a mount that is still in use.
A container can run into this with its own mounts. The host shares a tree with the container and the host has a mount in that tree:
mount -t tmpfs none /mnt mount --make-shared /mnt mount -t tmpfs none /mnt/a
The container's /mnt is a slave copy of the host mount. The container now takes a detached copy of the tree and mounts that copy beneath its propagated copy of /mnt/a and keeps the file descriptor to the tree open:
unshare -m --propagation unchanged mount --make-rslave / fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE) move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH)
grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 777 775 ... /mnt/a ... master:646 776 777 ... /mnt/a ... master:647 778 777 ... /mnt/a/a ... master:647
The now attached tree (777) is now mounted beneath the container's copy of /mnt/a. That's also where the host mount sits (as seen from the host mount namespace). So the propagated copy (776) of the host's mount is on top of its root and the copy of that (778) is inside it. Now the host runs:
umount /mnt/a
and it succeeds. The moved tree tree and the copy inside of it are gone from the container. Now only the propagated copy is left and it got reparented to where it was before:
grep /mnt /proc/self/mountinfo 775 355 ... /mnt ... master:646 776 775 ... /mnt/a ...
But the file descriptor still refers to the moved tree. So a synchronous umount detached a mount that is still in use.
Teach propagate_mount_busy() the same checks that propagate_umount() does. It now checks for a single victim mount without children for which it can assume that MNT_LOCKED is cleared on every copy like propagate_umount() does. The copies form chains. IOW, when a copy itself receives propagation from the victim's parent then the mount at the same mountpoint inside that copy is a copy as well. Whether a mount receives propagation from the victim's can simply be checked by walking its masters. Walk each chain once from its top so we are sure that nested copies stay linear. Check every reference once of every copy that gets unmounted.
References
4 sourcesInside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-98996View 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): 4.13
Before: 6.12.117
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 4.13
Before: 6.18.57
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 4.13
Before: 7.2.11
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 4.13
Before: 7.3
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 4.1.43
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 4.4.78
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 4.9.39
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 4.11.12
Vulnerable product
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*From (inclusive): 4.12.3
Applicability preview
[
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.13",
"versionEndExcluding": "6.12.117"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.13",
"versionEndExcluding": "6.18.57"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.13",
"versionEndExcluding": "7.2.11"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.13",
"versionEndExcluding": "7.3"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.1.43"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.4.78"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.9.39"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.11.12"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.12.3"
}
]
}
]
}
]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.