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=1793802973; b=XDf17prq4wr3bxCaID7Jb+vPJSAAjS/Hn8So3t7WIl9qnkG9EWKkdvUpeg6oQvwYihdg 4Tm0VhfnIkI0AuC2mkDyHbtGJIK5aqisKBByPj2Tjce7Km9pRFhWrMgQY+dJdBgSRxHPk /jo+PHAZCz/zoNLadmOwgpEXbt2hxsana6wVoh0yCUobopyq++575iHKzFr0Y8YSIsgom f6zi1+Ajz0Vc8kdiLyhe/s27UYw4rLeuClhBvD6Qp+e3pY8tQCL208mJ8sY/R5LCMYIef eRBv92Ly3YI6F7hVLl4CGKjsDlVMAZeY5G8cgLaSC1/e9IJLSQB13QkTcn0zpKxX7Og== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793802973; h=Received:DKIM-Signature:Subject:To:Cc:From:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=lO9MC0mrb9RJhjRwWn4SP7yY9Fwa46K2TPvyDoDVm/I=; b=ottBlygAE4W4R48toHx1V04EKJHgFgesI8ghRxdjCtDJJ1+vGO1tWjikcp/THghILMWJ tom8quPJXWLx28uxqs8V/03stpF+S2YUdAqgEHLqHrzNi8CcGo88Fq5A+6FquNMBIL3uv TGxWiEJ7OvtGX6HC7sygRF8xx0bq+iqAfb8x2FcEBi745fLwsKvpIBg3NmBj2aaIbIAJ8 Jgnj7FM2gKLjrLsaZ8W2L0JCFP527WklcMXbmqjRxEShlVufFOcrtPpX+xn9+U2iaw//y xJaxp7HpZSp1OIZpAzRj4+axkgGrsz3+WTxuezOYY2V17yuDdFT8tTNtnPVn6uPbA/g== 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=eRqeWHiL; 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 E587D606A31B for ; Wed, 4 Nov 2026 14:36:12 +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=eRqeWHiL Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6485A1F00A02; Wed, 4 Nov 2026 14:36:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793802972; bh=lO9MC0mrb9RJhjRwWn4SP7yY9Fwa46K2TPvyDoDVm/I=; h=Subject:To:Cc:From:Date; b=eRqeWHiLDfWLPKA7bNnPciVTeW/biOUxy2E4lKqmFg7MS3UhV6w/ohNBDbzht5Qfd 9qQjXbp3j9n7O8V0QDF8zugNpTaKiuAJBWXbijq/KlEvY0xTLSN1sDH9OiCkJ1A3pW XYhzPuTGnaz4jvs2GyBUIULoLVCVBR1uRuvvvC8U= Subject: FAILED: patch "[PATCH] ovl: do not copy up a dentry that was removed" failed to apply to 6.12-stable tree To: mason@kernel.org,amir73il@gmail.com,josef@toxicpanda.com Cc: From: Date: Wed, 04 Nov 2026 15:36:07 +0100 Message-ID: <2026110407-elevation-shale-f903@gregkh> X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x f635192ad223d2009ee640b63adf5ce3198aa338 # git commit -s git send-email --to '' --in-reply-to '2026110407-elevation-shale-f903@gregkh' --subject-prefix 'PATCH 6.12.y' 'HEAD^..' Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From f635192ad223d2009ee640b63adf5ce3198aa338 Mon Sep 17 00:00:00 2001 From: Chris Mason Date: Wed, 7 Oct 2026 11:00:06 +0000 Subject: [PATCH] ovl: do not copy up a dentry that was removed A change to a removed file through an open descriptor replaces whatever has its old name in the upper layer. Copy up must only create a name in the upper directory, never replace one. After an unlink, an rmdir or a rename over a lower dentry, a dentry that an open file keeps alive still has its old parent and name, but in the upper directory that name is now a whiteout or a new object. ovl_copy_up_workdir() renames the copy over it, which brings back the removed object and destroys whatever took its name. An unprivileged user opened a lower FIFO and unlinked it, root created a file at that name, and fchmod on the old descriptor replaced the file of root with the FIFO. Fix this by looking up the target name of the rename in ovl_copy_up_workdir() with LOOKUP_EXCL, so that copy up fails with -EEXIST if the name is taken, as copy up with O_TMPFILE already does when it links the copy to the name. Fixes: e9be9d5e76e3 ("overlay filesystem") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Signed-off-by: Josef Bacik [amir: use LOOKUP_EXCL instead of relying on d_unhashed()] Signed-off-by: Amir Goldstein diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c index 12000e45fefc..286978d47ef7 100644 --- a/fs/overlayfs/copy_up.c +++ b/fs/overlayfs/copy_up.c @@ -793,9 +793,10 @@ static int ovl_copy_up_workdir(struct ovl_copy_up_ctx *c) rd.old_parent = c->workdir; rd.new_parent = c->destdir; rd.flags = 0; - err = start_renaming_dentry(&rd, 0, temp, + /* The name may have been taken since lookup, never replace it */ + err = start_renaming_dentry(&rd, LOOKUP_EXCL, temp, &QSTR_LEN(c->destname.name, c->destname.len)); - if (err) { + if (err && err != -EEXIST) { /* temp or workdir moved underneath us? map to -EIO */ err = -EIO; }