Skip to main content

Linux EUVDEUVD-2026-108790

| CVE-2026-98996
2026-10-23 Linux GHSA-5j2w-v2xc-m3r3
View
Monitor Track and reassess. Why: No CVSS yet + weak signal (CWE or non-zero EPSS).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisCVE.org

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.

Affected VersionsENISA

Linux 99b19d16471e9c3faa85cad38abc9cbbe04c6d55 <a210ac218c307513d43e98a08f23c2dfbeeebc2f
Linux bb4fbf094b440a9209ed88c8681960d4b26eec0f
Linux 4.4.78 <4.5
Linux 99b19d16471e9c3faa85cad38abc9cbbe04c6d55 <bf2c8dec26fb792876b5e9bde7030c45d8be3908
Linux 81311d1698c0c87c972ba71d3ce44a617b52ea21
Linux dc5ce95b0252d143497283f7f659840d4f8a79d0
Linux patch: 7.3
Linux 4.9.39 <4.10
Linux 4.12.3 <4.13
Linux b43f81ef0babcc07db1eaaece37c989204e4ff00
Linux 4.1.43 <4.2
Linux 4.11.12 <4.12
Linux 99b19d16471e9c3faa85cad38abc9cbbe04c6d55 <6857e209015f95be7a8f19a9cd5dac345b9b9859
Linux patch: 6.18.57
Linux patch: 0
Linux patch: 7.2.11
Linux fdb8f10499924d96b8eb60cc1354b278f6fcf0e9
Linux 4.13

Affected Packages

euvd linux fix: 4.2, 4.5, 4.10, 4.12, 4.13

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Lifecycle Timeline

2
Patch available
Oct 23, 2026 - 13:17 EUVD
CVE Published
Oct 23, 2026 - 12:20 cve.org
UNKNOWN (no severity yet)

Threat Intelligence Overview

EPSS Score
0.2%
Top 90% exploitable
Data Quality
3 sources
Confidence: Low

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity Not scored yet
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
No CVSS yet + weak signal (CWE or non-zero EPSS)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy