{"id":"CVE-2026-98987","kind":"vulnerability","aliases":["CVE-2026-98987"],"related":[],"title":"Linux kernel: mount namespace handling can hide a propagated mount","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnamespace: look at the topmost mount for a mount namespace file\n\nattach_recursive_mnt() preallocates a mountpoint for the root of the\ntopmost mount of the source so that a mount that already sits at the\ndestination can be put on top of the source or on top of one of its\npropagated copies.\n\nThe copies are made without CL_COPY_MNT_NS_FILE so their chain of\novermounts is shorter than the source's. It ends below the first bind\nmount of a mount namespace file. So while the loop walks up the chain of\nthe source it remembers the mountpoint of that mount in \"shorter\" and\nthe existing mount is put there for the copies.\n\nBut the loop ends at the topmost mount without ever looking at it. If\nthe topmost mount is the only mount namespace file in the chain\n\"shorter\" stays NULL and mnt_change_mountpoint() attaches the existing\nmount of the copy below the root of the mount namespace file. That's a\ndentry of nsfs. No path walk in the copy's mount namespace ever gets\nthere. The mount is gone until its parent goes and the copy that took\nits place can't be unmounted synchronously because it has a child:\n\n  S      bind mount of a file\n  N      bind mount of a mount namespace file on top of S\n  A      shared mount, B a slave of A, Q mounted on B/file\n\n  move_mount(S, A/file)\n  cat B/file          -> the content of S instead of Q\n  umount B/file       -> EBUSY\n\nLook at every mount of the chain including the topmost one.","summary":"When a mount namespace file is the topmost mount during move_mount with shared or slave propagation, the kernel can attach an existing mount below the nsfs root instead of where it belongs. The result is that a mount is hidden or stuck and cannot be unmounted synchronously, which the sources describe as a correctness flaw rather than a confirmed privilege escalation.","severity":"unknown","cvss":null,"epss":0.00206,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["containers","infrastructure","kernel","linux","self-hosted"],"not_affected_if":["default-config","no-shared-mount-propagation"],"how_to_check":"- `uname -r` and compare against the kernel version that carries the upstream fix (unknown from the sources)\n- Check whether the host uses shared or slave bind mounts together with bind mounts of mount namespace files (`findmnt -o TARGET,PROPAGATION,FSTYPE`)","fix":"- Update the Linux kernel to a release that includes the upstream commit 'namespace: look at the topmost mount for a mount namespace file' (version unknown from the sources)\n- Until patched, avoid move_mount of mounts that sit on shared or slave propagation trees in untrusted workloads","status":"open","published_at":"2026-10-23T13:17:20+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","triaged_at":"2026-10-25T04:56:11+00:00","updated_at":"2026-10-25T12:38:50+00:00","category":"infrastructure","confidence":0.5,"triage":{"at":"2026-10-25T04:56:11Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel to a release that includes the upstream commit 'namespace: look at the topmost mount for a mount namespace file' (version unknown from the sources)\n- Until patched, avoid move_mount of mounts that sit on shared or slave propagation trees in untrusted workloads","reach":"local","title":"Linux kernel: mount namespace handling can hide a propagated mount","impact":"medium","summary":"When a mount namespace file is the topmost mount during move_mount with shared or slave propagation, the kernel can attach an existing mount below the nsfs root instead of where it belongs. The result is that a mount is hidden or stuck and cannot be unmounted synchronously, which the sources describe as a correctness flaw rather than a confirmed privilege escalation.","category":"infrastructure","nicknames":[],"who_cares":["linux","kernel","containers","self-hosted"],"confidence":0.5,"needs_auth":"unknown","worst_case":"mounts are hidden or stuck, causing data exposure or unmount failures","analyst_note":"Find the fixed kernel version and the upstream commit for this change, and whether any privilege escalation is shown beyond the mount misbehaviour.","how_to_check":"- `uname -r` and compare against the kernel version that carries the upstream fix (unknown from the sources)\n- Check whether the host uses shared or slave bind mounts together with bind mounts of mount namespace files (`findmnt -o TARGET,PROPAGATION,FSTYPE`)","needs_analyst":true,"not_affected_if":["default-config","no-shared-mount-propagation"],"who_is_affected":"Systems running a Linux kernel without this fix that use shared or slave mount propagation together with bind mounts of mount namespace files, such as container runtimes or namespace-heavy sandboxes. Hosts that do not use mount namespace file bind mounts or propagated mount trees are unlikely to be affected.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"unknown"},"cost_usd":0.000722,"input_tokens":3724,"output_tokens":699,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':12A,15A '-98987':13A,16A 'a/file':337C 'alreadi':128C 'attach':44B,107C,246C 'b':325C 'b/file':333C,339C,348C 'belong':56B 'bind':176C,305C,311C 'cannot':68B 'cat':338C 'chain':162C,190C,238C,356C 'chang':244C 'child':303C 'cl':155C 'confirm':83B 'contain':17B 'content':341C 'copi':149C,151C,156C,212C,252C,272C,289C 'correct':78B 'cve':11A,14A 'dentri':264C 'describ':75B 'destin':132C 'ebusi':349C 'end':172C,216C 'escal':85B 'ever':222C,276C 'everi':352C 'exist':46B,205C,248C 'file':28B,106C,159C,182C,235C,260C,309C,317C 'first':175C 'flaw':79B 'follow':91C 'get':277C 'goe':286C 'gone':282C 'handl':5A 'hidden':64B 'hide':7A 'host':23B 'includ':357C 'infrastructur':18B 'instead':52B,344C 'kernel':2A,19B,42B,89C 'linux':1A,20B,88C 'look':97C,223C,350C 'loop':186C,215C 'made':153C 'mnt':109C,157C,243C 'mount':3A,10A,26B,32B,35B,47B,62B,101C,104C,119C,126C,177C,180C,200C,206C,220C,229C,233C,249C,258C,274C,280C,306C,312C,315C,324C,331C,335C,353C 'mountpoint':112C,197C,245C 'move':34B,334C 'n':310C 'namespac':4A,27B,96C,105C,181C,234C,259C,275C,316C 'ns':158C 'nsfs':50B,266C 'null':241C 'one':145C,360C 'overmount':164C 'parent':285C 'path':268C 'place':293C 'prealloc':110C 'privileg':84B 'propag':9A,40B,148C 'put':135C,208C 'q':330C,346C 'rather':80B 'recurs':108C 'rememb':195C 'resolv':95C 'result':58B 'root':51B,115C,255C 'self':22B 'self-host':21B 'share':37B,323C 'shorter':166C,202C,239C 'sit':129C 'slave':39B,327C 'sourc':74B,122C,140C,169C,193C 'stay':240C 'stuck':66B 'synchron':71B,298C 'took':291C 'top':137C,143C,319C 'topmost':31B,100C,118C,219C,228C,359C 'umount':347C 'unmount':70B,297C 'vulner':92C 'walk':187C,269C 'without':154C,221C","nicknames":[],"mitigations":[],"who_affected":"Systems running a Linux kernel without this fix that use shared or slave mount propagation together with bind mounts of mount namespace files, such as container runtimes or namespace-heavy sandboxes. Hosts that do not use mount namespace file bind mounts or propagated mount trees are unlikely to be affected.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-23T13:17:20+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98987","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98987","severity":null,"published_at":"2026-10-23T13:17:20+00:00","modified_at":"2026-10-23T13:17:20+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","fetched_at":"2026-10-23T22:29:03+00:00","note":null},{"source":"epss","external_id":"CVE-2026-98987","url":"https://api.first.org/data/v1/epss?cve=CVE-2026-98987","severity":null,"published_at":null,"modified_at":null,"first_seen_at":"2026-10-25T12:38:50+00:00","fetched_at":"2026-10-25T12:38:50+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"}