From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 04E27824A1 for ; Mon, 8 Jul 2024 12:52:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720443122; cv=none; b=UB2DvOfbMGkXdL9slKYv+DDam8IKmvYcMSrkl+BQeqIe35yZrK79kwwheS3jwHLMGVuThGZGxJHAoDAS1g7dE1+b73i9NMUhOQrXBYCz0KDynDqYzjHtwzO4M+OTISAydy7ZKPrePa+t2+AKQxD+WZeiGLdEkTDBS1FfAf6pbAI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720443122; c=relaxed/simple; bh=yrUoK9s98tFxWsLnG0pYgiJMA5TMCSGe6SJvsRKYFng=; h=Subject:To:Cc:From:Date:Message-ID:MIME-Version:Content-Type; b=qdYQPR0+1jLSUyhPFVFXq3qH44bZCBU5pT8SLczXkRWNCEG8yk2QiSKwlepK8Wm2oVwBIZ2jQzYDYa/wSqCw+sda1W9qx5UMW1DO3sIrjp4VRBL9Q3nUxRpHrr0pBCqcVm1daMXSv4RBObt7eqTuAoaP7RpdsSMMbsdPJ5mvMcw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ek4jbJt/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ek4jbJt/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22D3AC116B1; Mon, 8 Jul 2024 12:52:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1720443121; bh=yrUoK9s98tFxWsLnG0pYgiJMA5TMCSGe6SJvsRKYFng=; h=Subject:To:Cc:From:Date:From; b=ek4jbJt/NAW+MPudRLCGqFe9BTuOORywGvpjqYM7fqH/pEnbImlQzRtGMOK42vNIC S0u0sTpRd4KxStEiimKNawvUtZir+Pjvf6AOLO+PUtSTJa6953Xst5SBD/gLhqbW6J SG+jYuqnY4Wp0e6e8585YIBOoDiU+8Vcy9ubPkUE= Subject: FAILED: patch "[PATCH] filelock: Remove locks reliably when fcntl/close race is" failed to apply to 6.6-stable tree To: jannh@google.com,brauner@kernel.org,jlayton@kernel.org Cc: From: Date: Mon, 08 Jul 2024 14:51:58 +0200 Message-ID: <2024070858-anew-deuce-98ab@gregkh> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x 3cad1bc010416c6dd780643476bc59ed742436b9 # git commit -s git send-email --to '' --in-reply-to '2024070858-anew-deuce-98ab@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected") 4ca52f539865 ("filelock: have fs/locks.c deal with file_lock_core directly") a69ce85ec9af ("filelock: split common fields into struct file_lock_core") 3d40f78169a0 ("filelock: drop the IS_* macros") 75cabec0111b ("filelock: add some new helper functions") 587a67b6830b ("filelock: rename some fields in tracepoints") 0e9876d8e88d ("filelock: fl_pid field should be signed int") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 3cad1bc010416c6dd780643476bc59ed742436b9 Mon Sep 17 00:00:00 2001 From: Jann Horn Date: Tue, 2 Jul 2024 18:26:52 +0200 Subject: [PATCH] filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. In theory (but AFAIK not in practice), posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in enforcing mode and only works from some security contexts. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable@kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn Link: https://lore.kernel.org/r/20240702-fs-lock-recover-2-v1-1-edd456f63789@google.com Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner diff --git a/fs/locks.c b/fs/locks.c index 90c8746874de..c360d1992d21 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2448,8 +2448,9 @@ int fcntl_setlk(unsigned int fd, struct file *filp, unsigned int cmd, error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by releasing the - * lock that was just acquired. There is no need to do that when we're + * Detect close/fcntl races and recover by zapping all POSIX locks + * associated with this file and our files_struct, just like on + * filp_flush(). There is no need to do that when we're * unlocking though, or for OFD locks. */ if (!error && file_lock->c.flc_type != F_UNLCK && @@ -2464,9 +2465,7 @@ int fcntl_setlk(unsigned int fd, struct file *filp, unsigned int cmd, f = files_lookup_fd_locked(files, fd); spin_unlock(&files->file_lock); if (f != filp) { - file_lock->c.flc_type = F_UNLCK; - error = do_lock_file_wait(filp, cmd, file_lock); - WARN_ON_ONCE(error); + locks_remove_posix(filp, files); error = -EBADF; } }