Vulnerability-Lookup

GHSA-4QHH-MF87-XRFM

Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31

Details

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.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-98991"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-23T13:17:21Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnamespace: queue a mount only once for mount notifications\n\nmnt_notify_add() puts a mount on notify_list. It doesn\u0027t check whether\nthe mount is on the list already. That\u0027s fine as long as every mount is\nqueued at most once per namespace_sem hold. It isn\u0027t.\n\npropagate_umount() moves a surviving overmount off a stack of mounts\nthat are going away and queues it as moved. shrink_submounts() and\nmark_mounts_for_expiry() call umount_tree() for several mounts under a\nsingle namespace_sem hold. So the second umount_tree() can take down\nexactly the mount the first one reparented, reparent it once more and so\nend up queueing it a second time.\n\nThe second list_add_tail() cuts the mounts queued in between out of the\nlist while the head still points at the last of them. notify_mnt_list()\nthen only visits that one mount and the others are freed after the grace\nperiod with notify_list still pointing at them. Every later mount\noperation on the host walks freed memory:\n\n  BUG: KASAN: slab-use-after-free in __list_add_valid_or_report\n  Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162\n   __list_add_valid_or_report+0x15c/0x1a0\n   mnt_add_to_ns+0x322/0x890\n   attach_recursive_mnt.isra.0+0xf2a/0x1a00\n   path_mount+0x139c/0x1d40\n\nThis needs a mount with MNT_SHRINKABLE to bind from. That\u0027s what\nfinish_automount() creates (submounts of NFS, AFS and CIFS and the\ntracefs mount below debugfs). Bind mounts inherit the flag. A mount\nnamespace with a FAN_MARK_MNTNS mark does the rest and root in a user\nnamespace can have both.\n\nInitialize to_notify in alloc_vfsmnt() and leave a mount alone that is\nqueued already. mnt_notify() looks at the state the mount has when the\nlist is drained so a single entry per mount is enough. The move event\nfor a mount that is unmounted under the same hold is lost. That\u0027s fine.\nThe detach is what matters.",
  "id": "GHSA-4qhh-mf87-xrfm",
  "modified": "2026-10-23T15:31:34Z",
  "published": "2026-10-23T15:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98991"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/702ff3fe499876e09c45558a05366d21a5bc41ab"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/acbe9e4418e2ef7bef1a12e62e0e7d6145a15190"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bd2feb7796b6585938a4241e7b7c4148a6f7b762"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2026-98991 (GCVE-0-2026-98991)

Vulnerability from cvelistv5 – Published: 2026-10-23 12:20 – Updated: 2026-10-23 12:20

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. 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.

Severity

No CVSS data available.

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 7061 records in the last 180 days details

References

3 references

URL	Tags
https://git.kernel.org/stable/c/acbe9e4418e2ef7be…
https://git.kernel.org/stable/c/702ff3fe499876e09…
https://git.kernel.org/stable/c/bd2feb7796b658593…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: bf630c40164162ba1d3933c2f5e3397d083e0948 , < acbe9e4418e2ef7bef1a12e62e0e7d6145a15190 (git) Affected: bf630c40164162ba1d3933c2f5e3397d083e0948 , < 702ff3fe499876e09c45558a05366d21a5bc41ab (git) Affected: bf630c40164162ba1d3933c2f5e3397d083e0948 , < bd2feb7796b6585938a4241e7b7c4148a6f7b762 (git)
Linux	Linux	Affected: 6.15 Unaffected: 0 , < 6.15 (semver) Unaffected: 6.18.57 , ≤ 6.18.* (semver) Unaffected: 7.2.11 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/mount.h",
            "fs/namespace.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "acbe9e4418e2ef7bef1a12e62e0e7d6145a15190",
              "status": "affected",
              "version": "bf630c40164162ba1d3933c2f5e3397d083e0948",
              "versionType": "git"
            },
            {
              "lessThan": "702ff3fe499876e09c45558a05366d21a5bc41ab",
              "status": "affected",
              "version": "bf630c40164162ba1d3933c2f5e3397d083e0948",
              "versionType": "git"
            },
            {
              "lessThan": "bd2feb7796b6585938a4241e7b7c4148a6f7b762",
              "status": "affected",
              "version": "bf630c40164162ba1d3933c2f5e3397d083e0948",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/mount.h",
            "fs/namespace.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.15"
            },
            {
              "lessThan": "6.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.57",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.11",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.57",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.11",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnamespace: queue a mount only once for mount notifications\n\nmnt_notify_add() puts a mount on notify_list. It doesn\u0027t check whether\nthe mount is on the list already. That\u0027s fine as long as every mount is\nqueued at most once per namespace_sem hold. It isn\u0027t.\n\npropagate_umount() moves a surviving overmount off a stack of mounts\nthat are going away and queues it as moved. shrink_submounts() and\nmark_mounts_for_expiry() call umount_tree() for several mounts under a\nsingle namespace_sem hold. So the second umount_tree() can take down\nexactly the mount the first one reparented, reparent it once more and so\nend up queueing it a second time.\n\nThe second list_add_tail() cuts the mounts queued in between out of the\nlist while the head still points at the last of them. notify_mnt_list()\nthen only visits that one mount and the others are freed after the grace\nperiod with notify_list still pointing at them. Every later mount\noperation on the host walks freed memory:\n\n  BUG: KASAN: slab-use-after-free in __list_add_valid_or_report\n  Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162\n   __list_add_valid_or_report+0x15c/0x1a0\n   mnt_add_to_ns+0x322/0x890\n   attach_recursive_mnt.isra.0+0xf2a/0x1a00\n   path_mount+0x139c/0x1d40\n\nThis needs a mount with MNT_SHRINKABLE to bind from. That\u0027s what\nfinish_automount() creates (submounts of NFS, AFS and CIFS and the\ntracefs mount below debugfs). Bind mounts inherit the flag. A mount\nnamespace with a FAN_MARK_MNTNS mark does the rest and root in a user\nnamespace can have both.\n\nInitialize to_notify in alloc_vfsmnt() and leave a mount alone that is\nqueued already. mnt_notify() looks at the state the mount has when the\nlist is drained so a single entry per mount is enough. The move event\nfor a mount that is unmounted under the same hold is lost. That\u0027s fine.\nThe detach is what matters."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-23T12:20:10.289Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "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"
        }
      ],
      "title": "namespace: queue a mount only once for mount notifications",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-98991",
    "datePublished": "2026-10-23T12:20:10.289Z",
    "dateReserved": "2026-09-25T10:25:14.384Z",
    "dateUpdated": "2026-10-23T12:20:10.289Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted