{"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:\n\nnamespace: queue a mount only once for mount notifications\n\nmnt_notify_add() puts a mount on notify_list. It doesn't check whether\nthe 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","slug":"CVE-2026-98991","body":"## Overview\n\nIn 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't check whether\nthe mount is on the list already. That's fine as long as every mount is\nqueued at most once per namespace_sem hold. It isn't.\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's 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's fine.\nThe detach is what matters.\n\n## Affected\n\n- `Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 < acbe9e4418e2ef7bef1a12e62e0e7d6145a15190`\n- `Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 < 702ff3fe499876e09c45558a05366d21a5bc41ab`\n- `Linux >= bf630c40164162ba1d3933c2f5e3397d083e0948 < bd2feb7796b6585938a4241e7b7c4148a6f7b762`\n- `Linux 6.15`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"twilight","depthScore":43,"depthScoreParts":{"impact":42.9,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[{"seq":228874,"id":"CVE-2026-98991","ts":1792854097393,"field":"cvss","old":null,"new":"7.8"},{"seq":228873,"id":"CVE-2026-98991","ts":1792854097393,"field":"severity","old":"none","new":"high"}]}