Skip to main content

Linux Kernel CVE-2026-98978

| EUVDEUVD-2026-108772 HIGH
2026-10-23 Linux GHSA-73pw-3qvg-vxhf
8.4
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Gain local unprivileged shell
  2. Delivery
    Create user namespace
  3. Exploit
    MOVE_MOUNT_BENEATH shrinkable mount under locked mount
  4. Execution
    umount2() unlocked ancestor to expire bottom mount
  5. Impact
    Read revealed protected directory contents

Vulnerability Assessment

Exploitation Conditions

Requires local access plus the ability to create an unprivileged user namespace (CONFIG_USER_NS with unprivileged user-ns creation permitted, as on default Debian/Ubuntu) and a kernel supporting the MOVE_MOUNT_BENEATH mount flag. The concrete prerequisite chain is: own a user namespace, place a shrinkable mount beneath a locked mount via MOVE_MOUNT_BENEATH so the locked property migrates to the bottom mount, then umount/expire the unlocked ancestor so shrink_submounts()/mark_mounts_for_expiry() unmaps the locked bottom mount and uncovers the hidden directory. LIMITING FACTORS: no remote vector (AV:L) and no path for unauthenticated use (PR:L authenticated local user); hosts that disable unprivileged user namespaces (sysctl kernel.unprivileged_userns_clone=0 or seccomp/container policy) remove the primary entry point; only kernels implementing MOVE_MOUNT_BENEATH are affected. Per the advisory the complete fix is the vendor patch that refuses to expire locked mounts (a plain umount of an unlocked mount with a locked child now returns EBUSY).

Impact

The signals point to a real but bounded local privilege/isolation issue rather than a mass-exploitation emergency. The CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 8.4) describes a local, low-complexity, low-privilege attack with a scope change, which is consistent with a container/namespace boundary escape: an unprivileged local user who can create a user namespace abuses MOVE_MOUNT_BENEATH to relocate a locked mount and then expire it, revealing files the lock was meant to hide. EPSS is low (0.21%, 10th percentile) and the vuln is NOT in CISA KEV, with no public exploit identified, so there is no evidence of widespread or active exploitation - the vuln.today 'this_week' decision label reflects a fix-promptly priority, not act_now/emergency. The high base score is driven almost entirely by the scope change and confidentiality/integrity impact on protected files, but exploitation is gated by local access and unprivileged-user-namespace availability. Note a tension in the input: the vector lists I:H, yet the described effect is disclosure of covered/protected directory content (an information-disclosure/isolation-bypass primitive), so the integrity rating is debatable - verify impact with the upstream commit messages. Overall: a legitimate security-boundary bug worth patching on a normal cadence, not a high-CVSS-but-no-real-risk item and not an internet-facing emergency.

Exploit ScenarioDerived

A local unprivileged user on a multi-tenant or container host creates a user namespace, uses MOVE_MOUNT_BENEATH to slide a shrinkable mount beneath a locked mount, and then triggers umount/expiry of the unlocked ancestor; the locked mount dies and the previously hidden directory is exposed, letting the attacker read protected content (e.g. files masked by the lock). No public exploit code is identified at time of analysis, but the reproduction steps are spelled out in the advisory description. The CVSS AV:L/AC:L indicates reliable local triggering once unprivileged user namespaces are available.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

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

Alert me

AnalysisAIv1 – Oct 24, 2026

Locked mount expiry in the Linux kernel can be abused by an authenticated local user to unmount a mount that was supposed to stay locked, revealing the files and directories it was hiding. The attacker must first own an unprivileged user namespace, use MOVE_MOUNT_BENEATH to migrate the locked property onto a bottom mount, and then unmount or expire the now-unlocked ancestor so shrink_submounts() tears down the hidden bottom mount. The result is a confidentiality-only exposure of otherwise covered paths (assessed C:H/I:N/A:N); EPSS is low (0.21%, 10th percentile) and no public exploit code was identified at time of analysis, but vendor fixes are available and the issue is prioritized as this_week.

RemediationAI

Vendor-released patch: Linux 6.18.57, 7.2.11 and 7.3 - the upstream advisory states the complete fix is that patch, which makes mark_mounts_for_expiry() never see a locked mount and causes a plain umount() of an unlocked mount with a locked child to return EBUSY, so upgrading to the fixed release for your branch is the only complete remediation. Confirm the stable commit for your branch against git.kernel.org/stable/c/6b8dc3713a76346d212abab46cbfc8d7070f534c, git.kernel.org/stable/c/d23265a12e4991ce7aedce670c0b6b598cadb644 and git.kernel.org/stable/c/f78ddcc872248c7aa1d7e904928441a0be4c6d5d before backporting; the EUVD/NVD records (EUVD-2026-108772, nvd.nist.gov/vuln/detail/CVE-2026-98978) can be used to track branch coverage. As a compensating control for hosts that cannot be patched promptly, disabling unprivileged user namespaces (for example sysctl kernel.unprivileged_userns_clone=0 on Debian/Ubuntu, or SELinux/seccomp/container policy denying CLONE_NEWUSER) removes the primary entry point because the attack requires owning a user namespace to reach MOVE_MOUNT_BENEATH; the trade-off is that this breaks rootless containers, container runtimes relying on userns remapping, and sandboxing tools such as bubblewrap/Flatpak. Be aware of the intended behavioral side effect after patching: on fixed kernels an ordinary umount() of an unlocked mount that has a locked mount below it now fails with EBUSY instead of succeeding, so tooling that previously unmounted such trees must switch to a lazy umount, which still takes the whole tree.

Affected VersionsENISA

Linux patch: 0
Linux patch: 7.2.11
Linux patch: 7.3
Linux 5ff9d8a65ce80efb509ce4e8051394e9ed2cd942 <d23265a12e4991ce7aedce670c0b6b598cadb644
Linux patch: 6.18.57
Linux 5ff9d8a65ce80efb509ce4e8051394e9ed2cd942 <6b8dc3713a76346d212abab46cbfc8d7070f534c
Linux 3.12
Linux 5ff9d8a65ce80efb509ce4e8051394e9ed2cd942 <f78ddcc872248c7aa1d7e904928441a0be4c6d5d

Affected Packages

euvd linux no fix

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.

Technical ContextAI · show details

This is a mount-namespace logic flaw in the kernel's VFS mount lifecycle, where two code paths disagree about the 'locked mount' invariant. do_umount() has always refused to unmount a locked mount because locked mounts protect underlying files and directories from being revealed, but shrink_submounts() and mark_mounts_for_expiry() perform expiry-based teardown without applying the same check. A mount that is still shrinkable can become locked when the owner of a user namespace places it beneath a locked mount using the MOVE_MOUNT_BENEATH move_mount() flag; the locked property then migrates to the bottom mount, leaving the top mount ordinary and removable, so umount() of the unlocked ancestor expires the bottom mount first and exposes the covered directory. No CWE class was assigned, but the root cause is an inconsistency in invariant enforcement across the unmount and expiry code paths rather than a memory-safety defect: the fix makes mark_mounts_for_expiry() never observe a locked mount, has lock_mnt_tree() leave an already-expired-listed mount alone, adds an assertion that nothing else places a locked mount on an expiry list, and makes a plain umount() of an unlocked mount that has a locked child return EBUSY (lazy umount still takes the whole tree, and a locked mount now dies only with its parent). Reachability depends on the kernel implementing MOVE_MOUNT_BENEATH and on the host permitting unprivileged user namespace creation.

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

Severity by source

Vendor (Linux) PRIMARY 8.4 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
vuln.today AI 6.5 MEDIUM

Local unprivileged user abusing user namespaces (AV:L/PR:L/AC:L); crosses the mount-lock security boundary to reveal protected files (S:C/C:H), with no modification or availability loss, so I:N/A:N.

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

4
CVSS changed
Oct 24, 2026 - 14:22 NVD
8.4 (HIGH)
Patch available
Oct 23, 2026 - 13:17 EUVD
CVE Published
Oct 23, 2026 - 12:19 cve.org
HIGH 8.4
CVE Published
Oct 23, 2026 - 12:19 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

namespace: never expire a locked mount

Locked mounts are special. They protect the underlying files and directories from being revealed. do_umount() refuses to unmount locked mounts but shrink_submounts() doesn't.

A shrinkable mount can become locked once the owner of a user namespace puts it beneath a locked mount with MOVE_MOUNT_BENEATH. The locked property now moves to the mount at the bottom making it possible to unmount the top mount.

So umount() of an unlocked ancestor now expires the bottom mount first and the covered directory is revealed:

move_mount(c -> x/hidden, MOVE_MOUNT_BENEATH) = 0 the cover after the lock moved: umount2(x/hidden) = 0 the holder of the lock: umount2(x/hidden) = EINVAL the root of the copy, busy: umount2(x) = EBUSY reads x/hidden/secret: "covered-by-root"

So leave a locked mount alone as it dies together with its parent. A plain umount() of an unlocked mount with a locked one below it is EBUSY from now on. It's the same for any other locked child. A lazy umount still takes the whole tree.

mark_mounts_for_expiry() never sees a locked mount. lock_mnt_tree() leaves a mount on an expiry list alone and nothing else puts a locked one on such a list. Add an assert for this.

Executive ViewAI

Why It Matters

CVE-2026-98978 is a high-severity Linux kernel vulnerability that allows a local authenticated user with an unprivileged user namespace to unmount a locked mount, exposing hidden files and directories. This could lead to unauthorized access to sensitive data within containerized or multi-tenant environments. Although no active exploitation has been observed, the availability of a vendor patch and the potential for confidentiality breaches warrant immediate remediation action.

Business Impact: Medium
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 90% exploitable
Prevalence
Ubiquitous
Linux kernel mount/namespace code present in nearly all Linux deployments
Data Quality
4 sources
Confidence: Medium

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 HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
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.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
Medium

Priority Score

42
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +42
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

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