{"api_version":"1","generated_at":"2026-10-25T03:40:05+00:00","cve":"CVE-2026-98989","urls":{"html":"https://cve.report/CVE-2026-98989","api":"https://cve.report/api/cve/CVE-2026-98989.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-98989","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-98989"},"summary":{"title":"namespace: check a recursive bind mount for mount namespace loops","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/<pid>/ns/<ns> 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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-10-23 13:17:20","updated_at":"2026-10-23 13:17:20"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/c640a01a78e42302879006ed7b7d5a9a943ba815","name":"https://git.kernel.org/stable/c/c640a01a78e42302879006ed7b7d5a9a943ba815","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/a0ba48256f5dff6f75a45f8ce39fe57f21df1022","name":"https://git.kernel.org/stable/c/a0ba48256f5dff6f75a45f8ce39fe57f21df1022","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/37a82f400efa4d263542a5fa41755b21057f1e5d","name":"https://git.kernel.org/stable/c/37a82f400efa4d263542a5fa41755b21057f1e5d","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-98989","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98989","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected e149ed2b805fefdccf7ccdfc19eca22fdd4514ac a0ba48256f5dff6f75a45f8ce39fe57f21df1022 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected e149ed2b805fefdccf7ccdfc19eca22fdd4514ac 37a82f400efa4d263542a5fa41755b21057f1e5d git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected e149ed2b805fefdccf7ccdfc19eca22fdd4514ac c640a01a78e42302879006ed7b7d5a9a943ba815 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 3.19","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 3.19 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.57 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.11 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/namespace.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"a0ba48256f5dff6f75a45f8ce39fe57f21df1022","status":"affected","version":"e149ed2b805fefdccf7ccdfc19eca22fdd4514ac","versionType":"git"},{"lessThan":"37a82f400efa4d263542a5fa41755b21057f1e5d","status":"affected","version":"e149ed2b805fefdccf7ccdfc19eca22fdd4514ac","versionType":"git"},{"lessThan":"c640a01a78e42302879006ed7b7d5a9a943ba815","status":"affected","version":"e149ed2b805fefdccf7ccdfc19eca22fdd4514ac","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/namespace.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"3.19"},{"lessThan":"3.19","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.57","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.11","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.57","versionStartIncluding":"3.19","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.11","versionStartIncluding":"3.19","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3","versionStartIncluding":"3.19","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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/<pid>/ns/<ns> 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."}],"providerMetadata":{"dateUpdated":"2026-10-23T12:20:08.366Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/a0ba48256f5dff6f75a45f8ce39fe57f21df1022"},{"url":"https://git.kernel.org/stable/c/37a82f400efa4d263542a5fa41755b21057f1e5d"},{"url":"https://git.kernel.org/stable/c/c640a01a78e42302879006ed7b7d5a9a943ba815"}],"title":"namespace: check a recursive bind mount for mount namespace loops","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-98989","datePublished":"2026-10-23T12:20:08.366Z","dateReserved":"2026-09-25T10:25:14.384Z","dateUpdated":"2026-10-23T12:20:08.366Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-23 13:17:20","lastModifiedDate":"2026-10-23 13:17:20","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"98989","Ordinal":"1","Title":"namespace: check a recursive bind mount for mount namespace loop","CVE":"CVE-2026-98989","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"98989","Ordinal":"1","NoteData":"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/<pid>/ns/<ns> 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.","Type":"Description","Title":"namespace: check a recursive bind mount for mount namespace loop"}]}}}