# CVE-2026-98992: namespace: don't copy an unmounted mount tree


- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Fix available:** Yes
- **Published:** 23 Oct 2026
- **Updated:** 23 Oct 2026
- **Also known as:** AZL-110831, BELL-CVE-2026-98992, DEBIAN-CVE-2026-98992, GHSA-p9pg-23xc-8cjw, UBUNTU-CVE-2026-98992

## What is CVE-2026-98992?

CVE-2026-98992 is a vulnerability in Linux, published on 23 Oct 2026. 

### Official description

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

namespace: don't copy an unmounted mount tree

may_copy_tree() accepts a mount whose root is an nsfs or pidfs file
before it checks whether that mount is mounted. This exception exists
for nsfs and pidfs mounts. They are part of no mount namespace so
neither check_mnt() nor is_mounted() would let them through and
bind-mounting a nsfsfd or a pidfd wouldn't work.

Problem is that exception also admits a bind mount of such a file when
it was lazily unmounted and is only kept alive by a file descriptor:

  mount --bind /proc/self/ns/net /tmp/x
  exec 3< /tmp/x
  umount -l /tmp/x
  mount --rbind /proc/self/fd/3 /tmp/y

With MS_REC or AT_RECURSIVE copy_tree() doesn't stop at the unmounted
mount. It copies every mount that stayed attached to it as well. So if
you have a bunch of overmounts over the nsfsfd or the pidfd the whole
unmounted stack is copied. That's a bug.

So refuse to walk an unmounted tree. Copying its root alone stays
possible. So a bind mount of a namespace that is gone can still be
recreated from a file descriptor on the old one. The file descriptor
pins that mount and its root and __has_locked_children() only reads the
direct children which don't leave the parent's list without
namespace_sem. The internal mounts carry MNT_NS_INTERNAL instead of NULL
and are still walked. Copying an unmounted tree recursively fails with
EINVAL.

## Which versions are affected by CVE-2026-98992?


## How do I fix CVE-2026-98992?

Upgrade to a fixed version.

## Is CVE-2026-98992 being exploited?

There is no known exploitation of CVE-2026-98992 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-98992 and fix it if it is affected.

What it is: CVE-2026-98992 is a vulnerability in Linux, published on 23 Oct 2026. 
Exploitation: There is no known exploitation of CVE-2026-98992 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-98992/ (Markdown: https://insights.sbomify.com/CVE-2026-98992/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-98992
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-98992
- OSV: https://osv.dev/vulnerability/CVE-2026-98992

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-98992/
Summaries are generated and may contain mistakes; the official description above is the record.