# CVE-2026-98995: namespace: reset the old parent's ->overmount in mnt_change_mountpoint()


- **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Fix available:** Yes
- **Published:** 23 Oct 2026
- **Updated:** 24 Oct 2026
- **Also known as:** BELL-CVE-2026-98995, DEBIAN-CVE-2026-98995, GHSA-h4q9-qcg7-rj48, UBUNTU-CVE-2026-98995

## What is CVE-2026-98995?

CVE-2026-98995 is a high-severity vulnerability in Linux, published on 23 Oct 2026. 

### Official description

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

namespace: reset the old parent's ->overmount in mnt_change_mountpoint()

__umount_mnt() resets ->overmount of the parent when it unmounts the
mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the
mount to its new parent and leaves the old one pointing at it.

For a mount that is moved beneath in attach_recursive_mnt() that doesn't
matter. The new mount has already reset ->overmount of the old parent by
the time the old top mount is moved onto it.

It matters for reparent() though. propagate_umount() moves a surviving
overmount onto the first ancestor that isn't going to be unmounted. The
mount it was taken from is unmounted immediately afterwards. If a file
descriptor keeps that unmounted mount alive ->overmount points at the
moved mount. That's a dangling pointer and UAF as the moved mount is
unmounted and freed.

do_lock_mount() follows ->overmount from the target path under
mount_lock. With a file descriptor on such a mount as the target of a
mount beneath topmost_overmount() walks into the freed mount and
do_lock_mount() takes references on whatever it finds there.

So reset ->overmount of the old parent in mnt_change_mountpoint() the
same way __umount_mnt() does. A mount's ->overmount is then always a
mount that is attached to it.

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


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

Upgrade to a fixed version.

## Is CVE-2026-98995 being exploited?

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

## Fix prompt for AI coding agents

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

What it is: CVE-2026-98995 is a high-severity vulnerability in Linux, published on 23 Oct 2026. 
Exploitation: There is no known exploitation of CVE-2026-98995 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-98995/ (Markdown: https://insights.sbomify.com/CVE-2026-98995/index.md)
```

## Sources

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

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