{"id":"CVE-2026-98991","kind":"vulnerability","aliases":["CVE-2026-98991"],"related":[],"title":"Linux kernel: mount notification queue use-after-free lets local users crash or escalate","description":"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. 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.","summary":"The Linux kernel can queue the same mount twice for fanotify mount notifications, leaving freed mounts on the list. Later mount operations on the host then read freed memory, which the sources describe as a KASAN use-after-free.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["containers","fanotify","linux-kernel","multi-tenant","runtime","user-namespaces"],"not_affected_if":["no-fanotify-mntns-marks","user-namespaces-disabled"],"how_to_check":"- Run `uname -r` and compare against the fixed kernel build in your distribution's advisory (unknown in the sources)\n- Check whether unprivileged user namespaces are enabled with `sysctl kernel.unprivileged_userns_clone` or `sysctl user.max_user_namespaces` (unknown in the sources)","fix":"- Update the Linux kernel to a release that includes the upstream commit 'namespace: queue a mount only once for mount notifications' (exact version unknown in the sources)\n- Reboot into the patched kernel after the package update","status":"open","published_at":"2026-10-23T13:17:21+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","triaged_at":"2026-10-25T04:56:07+00:00","updated_at":"2026-10-25T04:56:07+00:00","category":"runtime","confidence":0.6,"triage":{"at":"2026-10-25T04:56:07Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel to a release that includes the upstream commit 'namespace: queue a mount only once for mount notifications' (exact version unknown in the sources)\n- Reboot into the patched kernel after the package update","reach":"local","title":"Linux kernel: mount notification queue use-after-free lets local users crash or escalate","impact":"high","summary":"The Linux kernel can queue the same mount twice for fanotify mount notifications, leaving freed mounts on the list. Later mount operations on the host then read freed memory, which the sources describe as a KASAN use-after-free.","category":"runtime","nicknames":[],"who_cares":["linux-kernel","multi-tenant","containers","user-namespaces","fanotify"],"confidence":0.6,"needs_auth":"yes","worst_case":"local user corrupts kernel memory and may run code as root","analyst_note":"Confirm the fixed kernel versions per stable branch and whether the attack needs root or only user namespaces, via the NVD entry and the upstream kernel commit.","how_to_check":"- Run `uname -r` and compare against the fixed kernel build in your distribution's advisory (unknown in the sources)\n- Check whether unprivileged user namespaces are enabled with `sysctl kernel.unprivileged_userns_clone` or `sysctl user.max_user_namespaces` (unknown in the sources)","needs_analyst":true,"not_affected_if":["user-namespaces-disabled","no-fanotify-mntns-marks"],"who_is_affected":"Hosts running a Linux kernel with the flawed mount notification code, where an attacker can bind-mount a MNT_SHRINKABLE mount (such as NFS, AFS, CIFS or tracefs submounts) inside a mount namespace watched by a FAN_MARK_MNTNS fanotify mark. The sources say root in a user namespace can trigger it, so multi-tenant and container hosts with user namespaces enabled are the main concern. Single-user systems without these mounts or namespaces are less exposed.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"unknown"},"cost_usd":0.000761,"input_tokens":3932,"output_tokens":735,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'+0':290C,296C,300C,304C '-2026':17A,20A '-98991':18A,21A '0':299C '8':277C 'add':95C,204C,270C,286C,293C 'addr':279C 'af':325C 'alloc':364C 'alon':370C 'alreadi':113C,374C 'attach_recursive_mnt.isra':298C 'automount':320C 'away':148C 'bind':314C,334C 'bug':261C 'call':161C 'check':105C 'cif':327C 'contain':22B 'crash':13A 'creat':321C 'cut':206C 'cve':16A,19A 'debugf':333C 'describ':66B 'detach':416C 'doesn':103C 'dq/162':284C 'drain':388C 'end':194C 'enough':396C 'entri':392C 'escal':15A 'event':399C 'everi':120C,251C 'exact':181C 'expiri':160C 'fan':344C 'fanotifi':23B,44B 'ffff8881003d57e0':280C 'fine':116C,414C 'finish':319C 'first':185C 'flag':338C 'follow':79C 'free':9A,73B,267C 'freed':48B,61B,239C,259C 'go':147C 'grace':242C 'head':218C 'hold':130C,172C,409C 'host':58B,257C 'inherit':336C 'initi':360C 'isn':132C 'kasan':69B,262C 'kernel':2A,26B,36B,77C 'last':223C 'later':53B,252C 'leav':47B,367C 'let':10A 'linux':1A,25B,35B,76C 'linux-kernel':24B 'list':52B,101C,112C,203C,215C,228C,246C,269C,285C,386C 'local':11A 'long':118C 'look':377C 'lost':411C 'mark':157C,345C,347C 'matter':419C 'memori':62B,260C 'mnt':93C,227C,292C,311C,375C 'mntns':346C 'mount':3A,41B,45B,49B,54B,87C,91C,98C,108C,121C,144C,158C,166C,183C,208C,234C,253C,303C,309C,331C,335C,340C,369C,382C,394C,402C 'move':136C,153C,398C 'multi':28B 'multi-ten':27B 'namespac':33B,84C,128C,170C,341C,356C 'need':307C 'nfs':324C 'notif':4A,46B,92C 'notifi':94C,100C,226C,245C,283C,362C,376C 'ns':295C 'one':186C,233C 'oper':55B,254C 'other':237C 'overmount':139C 'path':302C 'per':127C,393C 'period':243C 'point':220C,248C 'propag':134C 'put':96C 'queu':123C,209C,373C 'queue':5A,38B,85C,150C,196C 'read':60B,274C 'repar':187C,188C 'report':273C,289C 'resolv':83C 'rest':350C 'root':352C 'runtim':30B 'second':175C,199C,202C 'sem':129C,171C 'sever':165C 'shrink':154C 'shrinkabl':312C 'singl':169C,391C 'size':276C 'slab':264C 'slab-use-after-fre':263C 'sourc':65B 'stack':142C 'state':380C 'still':219C,247C 'submount':155C,322C 'surviv':138C 'tail':205C 'take':179C 'task':282C 'tenant':29B 'time':200C 'tracef':330C 'tree':163C,177C 'twice':42B 'umount':135C,162C,176C 'unmount':405C 'use':7A,71B,265C 'use-after-fre':6A,70B 'user':12A,32B,355C 'user-namespac':31B 'valid':271C,287C 'vfsmnt':365C 'visit':231C 'vulner':80C 'walk':258C 'whether':106C 'x139c/0x1d40':305C 'x15c/0x1a0':291C 'x322/0x890':297C 'xf2a/0x1a00':301C","nicknames":[],"mitigations":[],"who_affected":"Hosts running a Linux kernel with the flawed mount notification code, where an attacker can bind-mount a MNT_SHRINKABLE mount (such as NFS, AFS, CIFS or tracefs submounts) inside a mount namespace watched by a FAN_MARK_MNTNS fanotify mark. The sources say root in a user namespace can trigger it, so multi-tenant and container hosts with user namespaces enabled are the main concern. Single-user systems without these mounts or namespaces are less exposed.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-23T13:17:21+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98991","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98991","severity":null,"published_at":"2026-10-23T13:17:21+00:00","modified_at":"2026-10-23T13:17:21+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","fetched_at":"2026-10-23T22:29:03+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}