{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98989 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2026-98989 is a vulnerability in Linux, published on 23 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-98989 and fix it if it is affected.\n\nWhat it is: CVE-2026-98989 is a vulnerability in Linux, published on 23 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-98989 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-98989/ (Markdown: https://insights.sbomify.com/CVE-2026-98989/index.md)","id":"CVE-2026-98989","markdown":"https://insights.sbomify.com/CVE-2026-98989/index.md","name":"CVE-2026-98989","record":{"aliases":["AZL-110825","BELL-CVE-2026-98989","DEBIAN-CVE-2026-98989","GHSA-88xj-3p4j-2c73","UBUNTU-CVE-2026-98989"],"analysis":null,"analysis_generated_by":null,"assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnamespace: check a recursive bind mount for mount namespace loops\n\ndo_loopback() refuses to bind mount the file of a mount namespace that\nis as old as the caller's or older because a mount namespace that holds\na mount of its own file, or of an ancestor's, would cause a cycle. But\nit only checks the dentry the bind mount starts from. With MS_REC\neverything below it is copied and do_loopback() passes\nCL_COPY_MNT_NS_FILE so mount namespace files below the source are\ncopied.\n\nThat's fine for a source in the caller's own mount namespace. Every\nmount namespace file in there passed the same check when it was\nbind-mounted. It isn't fine for a source in another mount namespace.\nmay_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter\nwhat mount namespace it lives in so that /proc/\u003cpid\u003e/ns/\u003cns\u003e and pidfds\ncan be bind mounted. If we create a bind-mount stack of mount namespaces\nfile descriptors the kernel will copy them irrespective of their\nancestoral relationship to the mount namespace in question:\n\n  151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw\n  152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw\n\nMount 152 is a mount of the mount namespace file of mount namespace\n4026532293 inside mount namespace 4026532293. That namespace and every\nmount in it are leaked... All it takes is a process in an older mount\nnamespace that stacks the file and repeating it leaks without limit:\n\n  after control: Shmem:               380 kB\n  child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok\n  after cycle: Shmem:             65916 kB\n\ndo_move_mount() runs check_for_nsfs_mounts() over a detached tree for\nexactly that reason. Do the same for the copy before it is grafted.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"namespace: check a recursive bind mount for mount namespace loops","id":"CVE-2026-98989","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"namespace: check a submount for references right before unmounting it","id":"CVE-2026-98990"},"packages":[],"prev":{"headline":"namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE","id":"CVE-2026-98988"},"products":["Linux"],"published":"2026-10-23","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-23","vendors":["Linux"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-98989/"}