---
id: "CVE-2026-98985"
kind: "vulnerability"
aliases: ["CVE-2026-98985"]
title: "Linux kernel: pivot_root reads a freed mount parent, crashing or corrupting memory"
severity: "unknown"
cvss: null
epss: 0.00209
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["containers", "linux-kernel", "runtime", "self-hosted"]
not_affected_if: []
published_at: "2026-10-23T13:17:20+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98985", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98985", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: pivot_root reads a freed mount parent, crashing or corrupting memory

In the Linux kernel's pivot_root() and chroot() path, the kernel reads the parent of a mount that may already be freed after its last reference was dropped via a file descriptor. The sources describe a KASAN use-after-free read; the reported impact is a crash or memory corruption in kernel context, and the sources do not state a confirmed privilege escalation.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Update to a Linux kernel release that includes the upstream fix "namespace: check the mounts before reading their parents in pivot_root()" (the version is unknown from the sources)

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98985
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98985

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_