{"id":"CVE-2026-98989","summary":"namespace: check a recursive bind mount for mount namespace loops","details":"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.","modified":"2026-11-12T01:48:57.910812230Z","published":"2026-10-23T12:20:08.366Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98989.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/37a82f400efa4d263542a5fa41755b21057f1e5d"},{"type":"WEB","url":"https://git.kernel.org/stable/c/a0ba48256f5dff6f75a45f8ce39fe57f21df1022"},{"type":"WEB","url":"https://git.kernel.org/stable/c/b82f3c1131456537a514595c3991b62652507c9d"},{"type":"WEB","url":"https://git.kernel.org/stable/c/c640a01a78e42302879006ed7b7d5a9a943ba815"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98989.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98989"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"e149ed2b805fefdccf7ccdfc19eca22fdd4514ac"},{"fixed":"b82f3c1131456537a514595c3991b62652507c9d"},{"fixed":"a0ba48256f5dff6f75a45f8ce39fe57f21df1022"},{"fixed":"37a82f400efa4d263542a5fa41755b21057f1e5d"},{"fixed":"c640a01a78e42302879006ed7b7d5a9a943ba815"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-98989.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.19.0"},{"fixed":"6.12.117"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.57"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.2.11"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-98989.json"}}],"schema_version":"1.9.2"}