# CVE-2026-98989: namespace: check a recursive bind mount for mount namespace loops - **Severity:** Not scored - **Exploited in the wild:** Not known - **Fix available:** Yes - **Published:** 23 Oct 2026 - **Updated:** 23 Oct 2026 - **Also known as:** AZL-110825, BELL-CVE-2026-98989, DEBIAN-CVE-2026-98989, GHSA-88xj-3p4j-2c73, UBUNTU-CVE-2026-98989 ## What is CVE-2026-98989? CVE-2026-98989 is a vulnerability in Linux, published on 23 Oct 2026. ### Official description In the Linux kernel, the following vulnerability has been resolved: namespace: check a recursive bind mount for mount namespace loops do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed the same check when it was bind-mounted. It isn't fine for a source in another mount namespace. may_copy_tree() accepts a bind mount of any nsfs or pidfs file no matter what mount namespace it lives in so that /proc//ns/ and pidfds can be bind mounted. If we create a bind-mount stack of mount namespaces file descriptors the kernel will copy them irrespective of their ancestoral relationship to the mount namespace in question: 151 146 0:7 net:[4026531833] /tmp/nrc/y rw - nsfs nsfs rw 152 151 0:7 mnt:[4026532293] /tmp/nrc/y rw - nsfs nsfs rw Mount 152 is a mount of the mount namespace file of mount namespace 4026532293 inside mount namespace 4026532293. That namespace and every mount in it are leaked... All it takes is a process in an older mount namespace that stacks the file and repeating it leaks without limit: after control: Shmem: 380 kB child: mount(/proc/self/fd/6, MS_BIND|MS_REC): ok after cycle: Shmem: 65916 kB do_move_mount() runs check_for_nsfs_mounts() over a detached tree for exactly that reason. Do the same for the copy before it is grafted. ## Which versions are affected by CVE-2026-98989? ## How do I fix CVE-2026-98989? Upgrade to a fixed version. ## Is CVE-2026-98989 being exploited? There is no known exploitation of CVE-2026-98989 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2026-98989 and fix it if it is affected. What it is: CVE-2026-98989 is a vulnerability in Linux, published on 23 Oct 2026. Exploitation: There is no known exploitation of CVE-2026-98989 in the wild and no public exploit code. Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page. Task: 1. 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. 2. 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. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2026-98989/ (Markdown: https://insights.sbomify.com/CVE-2026-98989/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2026-98989 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-98989 - OSV: https://osv.dev/vulnerability/CVE-2026-98989 --- From sbomify Insights: https://insights.sbomify.com/CVE-2026-98989/ Summaries are generated and may contain mistakes; the official description above is the record.