From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA4E04D98E6; Tue, 13 Oct 2026 11:53:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791892393; cv=none; b=dBDi0zEYkMFwA3xgo1JzkS6L9pbS1BqqRyLBH3Xdi5VZQ4+/uK+J8ERc67NYIa14Wtz4AvJUp1OIx9wmYxPjpj8GAsfSSSXx69LZgcMcItoXRVQvJBGuOFqhh7KjtCtGEIPMpTIu0f3f/3wjwcYMSFMv4PslZbT18Vfo+Y9O11w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791892393; c=relaxed/simple; bh=YU40bXZk6uULo5bzB9O2Hixl8xvlHtKm5CWr/g/VBCg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=a3j4dIyDJ71Cnu7iN4fFoyfzrAgQEz+C8RlWTEM5ydZIpZt/hxMdedzUfj0qCxlKHmEzZ2ApC24+aL2dvdUwsgATzrM82aPyB9H71gVrESiHXzjM6MIxbUFFFNrTyn22DncfHanW3hTzkf2J4PnGtL+v9UMnrOpPF2r7VBNMGCc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Dny4MBPr; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Dny4MBPr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC3F71F000FF; Tue, 13 Oct 2026 11:53:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1791892392; bh=cBCraFWqaA7tbTFQPVX1MDfed4jeKloTpcRTP0fmYjY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Dny4MBPr5fn0ZTfz8RCKeeSnfgM2UC35uGgvYE9J/O81T99zTolP4U2rr7VFHLgHg gsFEZNLMZPzakZ6E2mj3eYKSA1LgQ7/59cCGPKj1ssejt9jnB8Qjvq+JndjYnvBDw/ tg6UKD1cfQ7RsmOdPr7Oc7QtNfcSKb1xy6uafDLQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Christian Brauner (Amutable)" Subject: [PATCH 7.2 157/281] namespace: check a recursive bind mount for mount namespace loops Date: Tue, 13 Oct 2026 13:37:53 +0200 Message-ID: <20261013112858.974272014@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261013112855.045212108@linuxfoundation.org> References: <20261013112855.045212108@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.2-stable review patch. If anyone has any objections, please let me know. ------------------ From: Christian Brauner commit c640a01a78e42302879006ed7b7d5a9a943ba815 upstream. 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. Fixes: e149ed2b805f ("take the targets of /proc/*/ns/* symlinks to separate fs") Fixes: ef4144ac2dec ("pidfs: allow bind-mounts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930-work-mount-fixes-3-v1-4-be34c83956ae@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman --- fs/namespace.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/fs/namespace.c +++ b/fs/namespace.c @@ -3037,7 +3037,11 @@ static int do_loopback(const struct path if (IS_ERR(mnt)) return PTR_ERR(mnt); - err = graft_tree(mnt, &mp); + /* the copy may carry mount namespace files from below the source */ + if (recurse && !check_for_nsfs_mounts(mnt)) + err = -EINVAL; + else + err = graft_tree(mnt, &mp); if (err) { lock_mount_hash(); umount_tree(mnt, UMOUNT_SYNC);