---
id: CVE-2026-98991
title: 'namespace: queue a mount only once for mount notifications'
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  namespace: queue a mount only once for mount notifications

  mnt_notify_add() puts a mount on notify_list. It doesn't check whether
  the mount is on the list already. Tha…
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
cvssSource: cna
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 <
    acbe9e4418e2ef7bef1a12e62e0e7d6145a15190
  - >-
    Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 <
    702ff3fe499876e09c45558a05366d21a5bc41ab
  - >-
    Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 <
    bd2feb7796b6585938a4241e7b7c4148a6f7b762
  - Linux 6.15
published: '2026-10-23'
updated: '2026-10-24'
sourceUpdated: '2026-10-24T14:09:52.901Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-98991'
references:
  - url: 'https://git.kernel.org/stable/c/acbe9e4418e2ef7bef1a12e62e0e7d6145a15190'
  - url: 'https://git.kernel.org/stable/c/702ff3fe499876e09c45558a05366d21a5bc41ab'
  - url: 'https://git.kernel.org/stable/c/bd2feb7796b6585938a4241e7b7c4148a6f7b762'
tags:
  - cve.org
epss: 0.00206
epssPercentile: 0.10151
ingestedAt: '2026-10-23T13:24:55.545Z'
---

## Overview

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

namespace: queue a mount only once for mount notifications

mnt_notify_add() puts a mount on notify_list. It doesn't check whether
the mount is on the list already. That's fine as long as every mount is
queued at most once per namespace_sem hold. It isn't.

propagate_umount() moves a surviving overmount off a stack of mounts
that are going away and queues it as moved. shrink_submounts() and
mark_mounts_for_expiry() call umount_tree() for several mounts under a
single namespace_sem hold. So the second umount_tree() can take down
exactly the mount the first one reparented, reparent it once more and so
end up queueing it a second time.

The second list_add_tail() cuts the mounts queued in between out of the
list while the head still points at the last of them. notify_mnt_list()
then only visits that one mount and the others are freed after the grace
period with notify_list still pointing at them. Every later mount
operation on the host walks freed memory:

  BUG: KASAN: slab-use-after-free in __list_add_valid_or_report
  Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162
   __list_add_valid_or_report+0x15c/0x1a0
   mnt_add_to_ns+0x322/0x890
   attach_recursive_mnt.isra.0+0xf2a/0x1a00
   path_mount+0x139c/0x1d40

This needs a mount with MNT_SHRINKABLE to bind from. That's what
finish_automount() creates (submounts of NFS, AFS and CIFS and the
tracefs mount below debugfs). Bind mounts inherit the flag. A mount
namespace with a FAN_MARK_MNTNS mark does the rest and root in a user
namespace can have both.

Initialize to_notify in alloc_vfsmnt() and leave a mount alone that is
queued already. mnt_notify() looks at the state the mount has when the
list is drained so a single entry per mount is enough. The move event
for a mount that is unmounted under the same hold is lost. That's fine.
The detach is what matters.

## Affected

- `Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 < acbe9e4418e2ef7bef1a12e62e0e7d6145a15190`
- `Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 < 702ff3fe499876e09c45558a05366d21a5bc41ab`
- `Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 < bd2feb7796b6585938a4241e7b7c4148a6f7b762`
- `Linux 6.15`

## Remediation

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