# CVE-2026-98985: namespace: check the mounts before reading their parents in pivot_root()


- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Fix available:** Yes
- **Published:** 23 Oct 2026
- **Updated:** 23 Oct 2026
- **Also known as:** AZL-110822, BELL-CVE-2026-98985, DEBIAN-CVE-2026-98985, GHSA-gfp5-4w3q-vwjx, UBUNTU-CVE-2026-98985

## What is CVE-2026-98985?

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

### Official description

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

namespace: check the mounts before reading their parents in pivot_root()

path_pivot_root() reads the parents of new_root and of the caller's root
and checks whether they are shared before it checks that either mount is
in the caller's mount namespace. Only namespace_sem is held. That's fine
for a mount that is in the caller's mount namespace.

But new_root can be a file descriptor to a mount that has been unmounted
and that only the file descriptor keeps alive. If that mount stayed
attached to its parent when it was unmounted nothing pins the parent for
it. The final mntput() of the parent unhooks the children under
mount_lock alone and frees the parent afterwards:

  pivot_root()                     close(fd), last ref on the parent
  ------------                     ---------------------------------
  ex_parent = new_mnt->mnt_parent
                                   mntput_no_expire_slowpath()
                                     __umount_mnt(new_mnt)
                                   cleanup_mnt()
                                     call_rcu()
  IS_MNT_SHARED(ex_parent)

  BUG: KASAN: slab-use-after-free in path_pivot_root+0xf1a/0x1840
  Read of size 4 at addr ffff8881047382f8 by task pivot_widen/157
   path_pivot_root+0xf1a/0x1840
   __x64_sys_pivot_root+0x165/0x190

The same goes for the caller's root via chroot(). Both outcomes of the
check end in EINVAL so nothing but the read itself goes wrong. It's the
same thing commit bb4609405752 ("statmount: read the parent of an
unmounted mount under mount_lock") fixed for statmount().

Check that both mounts are in the caller's namespace before their
parents are read. Every path returns EINVAL either way.

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


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

Upgrade to a fixed version.

## Is CVE-2026-98985 being exploited?

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

## Fix prompt for AI coding agents

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

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

## Sources

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

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