{"id":"CVE-2026-98986","kind":"vulnerability","aliases":["CVE-2026-98986"],"related":[],"title":"Linux kernel: fanotify mount-namespace marks removed in unsafe context","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnamespace: remove the fsnotify marks of a mount namespace in process context\n\nmnt_ns_release() drops the last passive reference of a mount namespace\nand removes its fanotify marks via fsnotify_mntns_delete(). That takes\nthe mutex of every group with a mark on the namespace and the spinlock\nof the connector. Fine from process context. But mnt_ns_tree_remove()\nhands the reference the namespace was allocated with to call_rcu() and\nso the marks are removed from the RCU softirq:\n\n  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:623\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/3\n   __mutex_lock+0x113/0x24b0\n   fsnotify_destroy_marks+0x11b/0x3d0\n   mnt_ns_release_rcu+0x57/0xa0\n   rcu_core+0x6b6/0x1e40\n\nand lockdep complains about the connector lock being taken from softirq\ncontext. A fanotify group with a FAN_MARK_MNTNS mark on the mount\nnamespace of another task is all that's needed. Root in a user\nnamespace can do that for a mount namespace it owns. The task exits and\nthe namespace is freed with the mark still on it.\n\nRemove the marks in free_mnt_ns() before the namespace is handed to RCU.\nThat runs in process context once the last active reference is gone. A\nmark is added through a file descriptor to the namespace which holds an\nactive reference so no mark can show up after that.","summary":"When a mount namespace is freed, the kernel removes fanotify marks from it inside an RCU softirq, where sleeping locks are not allowed, which triggers a sleeping-in-atomic-context bug and lockdep warnings. A local user who can create a user namespace and a fanotify group with a FAN_MARK_MNTNS mark can trigger the bug, and the sources do not describe the full impact beyond that.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["containers","linux-kernel","runtime","self-hosted"],"not_affected_if":["unknown"],"how_to_check":null,"fix":null,"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:10+00:00","updated_at":"2026-10-25T04:56:10+00:00","category":"runtime","confidence":0.5,"triage":{"at":"2026-10-25T04:56:10Z","model":"claude-haiku-5-5","output":{"fix":"unknown","reach":"local","title":"Linux kernel: fanotify mount-namespace marks removed in unsafe context","impact":"low","summary":"When a mount namespace is freed, the kernel removes fanotify marks from it inside an RCU softirq, where sleeping locks are not allowed, which triggers a sleeping-in-atomic-context bug and lockdep warnings. A local user who can create a user namespace and a fanotify group with a FAN_MARK_MNTNS mark can trigger the bug, and the sources do not describe the full impact beyond that.","category":"runtime","nicknames":[],"who_cares":["linux-kernel","self-hosted","containers"],"confidence":0.5,"needs_auth":"yes","worst_case":"kernel crash or lockdep splat from a local user","analyst_note":"Find the fixed kernel stable release and the affected version range from the NVD or kernel.org stable commit for this fix.","how_to_check":"unknown","needs_analyst":true,"not_affected_if":["unknown"],"who_is_affected":"Systems running a Linux kernel with this fix not yet applied; the sources do not name affected kernel versions or a patched version. Root in a user namespace it owns is needed to set up the mark, so multi-tenant hosts and container hosts allowing unprivileged user namespaces are the systems to look at first.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"unknown"},"cost_usd":0.000626,"input_tokens":3758,"output_tokens":500,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'+0':211C,216C,222C,226C '-2026':13A,16A '-98986':14A,17A '0':201C,204C,206C '1':198C '623':195C 'activ':311C,329C 'add':318C 'alloc':171C 'allow':48B 'anoth':254C 'atom':55B,197C 'beyond':93B 'block':203C 'bug':57B,83B,186C 'call':174C,189C 'complain':230C 'connector':155C,233C 'contain':18B 'context':11A,56B,115C,159C,192C,239C,307C 'core':225C 'creat':66B 'cve':12A,15A 'delet':136C 'describ':89B 'descriptor':322C 'destroy':214C 'disabl':200C 'drop':119C 'everi':142C 'exit':277C 'fan':76B,245C 'fanotifi':3A,35B,72B,131C,241C 'file':321C 'fine':156C 'follow':99C 'free':293C 'freed':31B,282C 'fsnotifi':107C,134C,213C 'full':91B 'function':188C 'gone':314C 'group':73B,143C,242C 'hand':165C,300C 'hold':327C 'host':25B 'impact':92B 'insid':39B 'invalid':191C 'irq':199C 'kernel':2A,21B,33B,97C 'kernel/locking/mutex.c':194C 'last':121C,310C 'linux':1A,20B,96C 'linux-kernel':19B 'local':62B 'lock':45B,210C,234C 'lockdep':59B,229C 'mark':7A,36B,77B,79B,108C,132C,146C,179C,215C,246C,248C,285C,291C,316C,333C 'mnt':116C,161C,218C,294C 'mntns':78B,135C,247C 'mount':5A,28B,111C,126C,251C,271C 'mount-namespac':4A 'mutex':140C,209C 'name':207C 'namespac':6A,29B,69B,104C,112C,127C,149C,169C,252C,265C,272C,280C,298C,325C 'need':260C 'non':202C 'ns':117C,162C,219C,295C 'own':274C 'passiv':122C 'pid':205C 'process':114C,158C,306C 'rcu':41B,175C,184C,221C,224C,302C 'refer':123C,167C,312C,330C 'releas':118C,220C 'remov':8A,34B,105C,129C,164C,181C,289C 'resolv':103C 'root':261C 'run':304C 'runtim':22B 'self':24B 'self-host':23B 'show':335C 'sleep':44B,53B,187C 'sleeping-in-atomic-context':52B 'softirq':42B,185C,238C 'sourc':86B 'spinlock':152C 'still':286C 'swapper/3':208C 'take':138C 'taken':236C 'task':255C,276C 'tree':163C 'trigger':50B,81B 'unsaf':10A 'user':63B,68B,264C 'via':133C 'vulner':100C 'warn':60B 'x113/0x24b0':212C 'x11b/0x3d0':217C 'x57/0xa0':223C 'x6b6/0x1e40':227C","nicknames":[],"mitigations":[],"who_affected":"Systems running a Linux kernel with this fix not yet applied; the sources do not name affected kernel versions or a patched version. Root in a user namespace it owns is needed to set up the mark, so multi-tenant hosts and container hosts allowing unprivileged user namespaces are the systems to look at first.","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-98986","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98986","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}],"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"}