---
id: CVE-2026-98989
title: 'namespace: check a recursive bind mount for mount namespace loops'
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  namespace: check a recursive bind mount for mount namespace loops

  do_loopback() refuses to bind mount the file of a mount namespace that
  is as old as the caller's or o…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac <
    a0ba48256f5dff6f75a45f8ce39fe57f21df1022
  - >-
    Linux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac <
    37a82f400efa4d263542a5fa41755b21057f1e5d
  - >-
    Linux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac <
    c640a01a78e42302879006ed7b7d5a9a943ba815
  - Linux 3.19
published: '2026-10-23'
updated: '2026-10-23'
sourceUpdated: '2026-10-23T12:20:08.366Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-98989'
references:
  - url: 'https://git.kernel.org/stable/c/a0ba48256f5dff6f75a45f8ce39fe57f21df1022'
  - url: 'https://git.kernel.org/stable/c/37a82f400efa4d263542a5fa41755b21057f1e5d'
  - url: 'https://git.kernel.org/stable/c/c640a01a78e42302879006ed7b7d5a9a943ba815'
tags:
  - cve.org
ingestedAt: '2026-10-23T13:24:55.546Z'
---

## Overview

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

namespace: check a recursive bind mount for mount namespace loops

do_loopback() refuses to bind mount the file of a mount namespace that
is as old as the caller's or older because a mount namespace that holds
a mount of its own file, or of an ancestor's, would cause a cycle. But
it only checks the dentry the bind mount starts from. With MS_REC
everything below it is copied and do_loopback() passes
CL_COPY_MNT_NS_FILE so mount namespace files below the source are
copied.

That's fine for a source in the caller's own mount namespace. Every
mount namespace file in there passed the same check when it was
bind-mounted. It isn't fine for a source in another mount namespace.
may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter
what mount namespace it lives in so that /proc/<pid>/ns/<ns> and pidfds
can be bind mounted. If we create a bind-mount stack of mount namespaces
file descriptors the kernel will copy them irrespective of their
ancestoral relationship to the mount namespace in question:

  151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw
  152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw

Mount 152 is a mount of the mount namespace file of mount namespace
4026532293 inside mount namespace 4026532293. That namespace and every
mount in it are leaked... All it takes is a process in an older mount
namespace that stacks the file and repeating it leaks without limit:

  after control: Shmem:               380 kB
  child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok
  after cycle: Shmem:             65916 kB

do_move_mount() runs check_for_nsfs_mounts() over a detached tree for
exactly that reason. Do the same for the copy before it is grafted.

## Affected

- `Linux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac < a0ba48256f5dff6f75a45f8ce39fe57f21df1022`
- `Linux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac < 37a82f400efa4d263542a5fa41755b21057f1e5d`
- `Linux >= e149ed2b805fefdccf7ccdfc19eca22fdd4514ac < c640a01a78e42302879006ed7b7d5a9a943ba815`
- `Linux 3.19`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.