From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792758619; b=NWlowem8jxTLAE5K1MuVJoK0LPlJt4xP+mywKEz3NHT6RRTLVYbw9WAhgc6U8bZFG3ie 9j2wEWlKgB1SPdWNwZrF3t289p+JK6M/OkmZ/wrCk4R+JsyHQl45fLYGAsKWkii9hD11w IobLL0stU0Rm6eQSt6T/1BXBx/1zuayi1LCHscqr9n1vwxNVYZNSVNVqAyNuQfTElBtWW XOqYi8oagjwSaemJsJZTaUtXD8OhUjUyQkdMX+5L2QoHoxGAQzWeH5c7JZhYYJQlGlHvu MmuSSov+c/kxZo5MFzGBVDW4N/Ojcxtx8hSV9avnwVqnaeqs9JCTAb3WpqeulVrESMw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792758619; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: Reply-To:MIME-Version:Lines:X-Developer-Signature:X-Developer-Key: Content-Transfer-Encoding; bh=cX45rJ6uNdX7IpeJuYfqH3jn+1d/2neif2GgcPLiVb0=; b=cbLj56edR5S2q2+LAsYn8kKJuPAHKfSpDNEafht5Cf7j9k+laagThQ2Z1SlRbLOtoOnN naVOP8TCEfuef2u3mFCkuv2mMuY6GHVXBKI9DQX3w1u0iN2cksVDGbCoWWqplRhSjsId5 ABLYCo6ISAIEEdza9U3D9VYe3TmE+AwBpH0GfyCSHq+taaNkHSPiPpzjBnYB/tTZI37u3 lztUpfHE7xSCTUPYZXISv0fnr9aN4xNtRaObfc3Eh24b026SDVF1WSzMcO7jF4oeNBxfT 03MUyxMwSeL9RCyC6jktABn41rDe4mUkpIpJiJEVdSVS3nrbEUtbD8g8K9LH28wgyng== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b="wv/5trA5"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8DFFE606A31B for ; Fri, 23 Oct 2026 12:30:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=wv/5trA5 Received: by smtp.kernel.org (Postfix) with ESMTPSA id B96111F01825; Fri, 23 Oct 2026 12:30:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1792758619; bh=cX45rJ6uNdX7IpeJuYfqH3jn+1d/2neif2GgcPLiVb0=; h=From:To:Cc:Subject:Date:Reply-To; b=wv/5trA5v7oDx8RZwiut2jlMWZYrDeOWe+MFg9Q4v5YW6bIgp1jHA63wys8MB1lXD rePLiyUa68qikKaSl/iOKTjTlfOfp093He9zS9Ghnh+14VklrasdcHJ99t2rN8PoF2 xcXIG34BXIblm/GYDczblNDnzu/Qn/xc+rlTgsNs= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-98987: namespace: look at the topmost mount for a mount namespace file Date: Fri, 23 Oct 2026 14:19:49 +0200 Message-ID: <2026102314-CVE-2026-98987-dfd9@gregkh> X-Mailer: git-send-email 2.56.0 Reply-To: , X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3371; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=bHFt2u+tkGiX7w9SgsK5xSQcFkSrfLKVGIictL3SRzE=; b=owGbwMvMwCRo6H6F97bub03G02pJDFm3Aw63WW6ZWKG+ctcu7wudU26z5jyTnGbEoLHuspeY4 cEFkhy6HbEsDIJMDLJiiixftvEc3V9xSNHL0PY0zBxWJpAhDFycAjARdg+G+Vkxx/r/agp87Jlp UNy495pXkroPC8Mczl2vTZh5Qx4GJsz9YXBL+UjXkTtrAA== X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: namespace: look at the topmost mount for a mount namespace file attach_recursive_mnt() preallocates a mountpoint for the root of the topmost mount of the source so that a mount that already sits at the destination can be put on top of the source or on top of one of its propagated copies. The copies are made without CL_COPY_MNT_NS_FILE so their chain of overmounts is shorter than the source's. It ends below the first bind mount of a mount namespace file. So while the loop walks up the chain of the source it remembers the mountpoint of that mount in "shorter" and the existing mount is put there for the copies. But the loop ends at the topmost mount without ever looking at it. If the topmost mount is the only mount namespace file in the chain "shorter" stays NULL and mnt_change_mountpoint() attaches the existing mount of the copy below the root of the mount namespace file. That's a dentry of nsfs. No path walk in the copy's mount namespace ever gets there. The mount is gone until its parent goes and the copy that took its place can't be unmounted synchronously because it has a child: S bind mount of a file N bind mount of a mount namespace file on top of S A shared mount, B a slave of A, Q mounted on B/file move_mount(S, A/file) cat B/file -> the content of S instead of Q umount B/file -> EBUSY Look at every mount of the chain including the topmost one. The Linux kernel CVE team has assigned CVE-2026-98987 to this issue. Affected and fixed versions =========================== Issue introduced in 6.17 with commit 96f5d2e051653f2cfe9137c5d3c7794c358ffb03 and fixed in 6.18.57 with commit b9c40553f6ceba50042281eef6f701e5fb719726 Issue introduced in 6.17 with commit 96f5d2e051653f2cfe9137c5d3c7794c358ffb03 and fixed in 7.2.11 with commit 87ecd4c6da146363384a603bd9e90c90e7275536 Issue introduced in 6.17 with commit 96f5d2e051653f2cfe9137c5d3c7794c358ffb03 and fixed in 7.3 with commit 8714b44adac7b10506e1db3ef1710689751f0f10 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-98987 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: fs/namespace.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/b9c40553f6ceba50042281eef6f701e5fb719726 https://git.kernel.org/stable/c/87ecd4c6da146363384a603bd9e90c90e7275536 https://git.kernel.org/stable/c/8714b44adac7b10506e1db3ef1710689751f0f10