From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84091606A327 for ; Sat, 14 Nov 2026 13:57:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=qK5ahUPk; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=efVM9o/h DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Cc:To:In-Reply-To:References :Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date: From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Unsubscribe-Post: List-Owner; bh=UFO9l/21W/p57UQi3nxXvGylhBlGyaXo8dkkR6Kzl3g=; b=qK5ahUPk2E5BoM fQA6EPhAJIg5CcOefcW+Kn9sZhqga6LUoy6w8bZc5hMrZz+rA+f4iCTnKAwkVoclxezvs6h4APbhu Tc0A6lVxsdVRaOi+s58g/1DYOIVL3EQsjPzSOeOXTrhkJGJn4xbMbQ6VtvKpWmPyQGSrbMkY41xWm RgY75nf5yBXhcUeOZfCnbJB7pRTVxstu9tGXj9NK0dkV/7roeHKDbIIA+Guvnq6EiAFk11KAh0h7/ NiksRrPSnDelzF7WhE30PtngxdsTjRN81JXjDilb2sYv3/4OpkILYMr5FwXAZUn6YmKovK12xIw8W nwpanY3JYm/k1lvubJCg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xSEFG-0000000GBDX-312M; Sat, 14 Nov 2026 13:56:42 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xSDRx-0000000G3ZJ-0Wyn for linux-nvme@lists.infradead.org; Sat, 14 Nov 2026 13:05:45 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 8E79A6234A; Sat, 14 Nov 2026 13:05:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F1041F000C5; Sat, 14 Nov 2026 13:05:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794661544; bh=UFO9l/21W/p57UQi3nxXvGylhBlGyaXo8dkkR6Kzl3g=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=efVM9o/ht18LNBayF3D7oOTcXQ+zQCvKSlyCayqwAYKv8bDYhkCN28KsHSlR6cMw8 4vF4PVm13UDKS8+oQ2cZQEBkjysVe3A6Nrl6NtQAxof/K3X7FCHiReyLELP5MDb8hQ d2gL2CxDePyruIvRh5R3YjiY7iLYLYQu27gg+QG4usERJo01RD8CffYKDn4Arsbfb0 kqmBhVnVPQD8zke3AZtVSBf8thbVIXaf/i5ZGVCckkNQ1RDwJaoqZxxDbFNlrAQ2pS KE4SKdC5qQmh16hHjDsNJDaG6MSH9S9GaVw+gzEFRuyMQOhbFY55PU1Zxdk60HYVRk 7XRSI9AN43uWw== From: Christian Brauner Date: Sat, 14 Nov 2026 14:01:42 +0100 Subject: [PATCH RFC v2 01/42] loop: refuse backing files that aren't open for reading X-Archived-By: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261114-work-loop-pseudo-v2-1-98639a2286fb@kernel.org> References: <20261114-work-loop-pseudo-v2-0-98639a2286fb@kernel.org> In-Reply-To: <20261114-work-loop-pseudo-v2-0-98639a2286fb@kernel.org> To: linux-fsdevel@vger.kernel.org Cc: Jann Horn , Chris Mason , Josef Bacik , Christoph Hellwig , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Alexander Viro , Jan Kara , linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, driver-core@lists.linux.dev, linux-mm@kvack.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, apparmor@lists.ubuntu.com, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, fuse-devel@lists.linux.dev, linux-efi@vger.kernel.org, xen-devel@lists.xenproject.org, ocfs2-devel@lists.linux.dev, linux-s390@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-usb@vger.kernel.org, Amir Goldstein , linux-erofs@lists.ozlabs.org, linux-kselftest@vger.kernel.org, "Christian Brauner (Amutable)" , stable@vger.kernel.org, Alexander Mikhalitsyn X-Mailer: b4 0.17-dev-ce4c1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1829; i=brauner@kernel.org; h=from:subject:message-id; bh=RNS20EKOa1D5gB/WqkZbolMxn0bhv9TmaIu0BLZLG3o=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWT9iEk7N/1b6Zufav+udO25utxD3izgpkPn8SDLhSpbn xXzJ6mEd5SyMIhxMciKKbI4tJuEyy3nqdhslKkBM4eVCWQIAxenAEyEfwEjwzfdzxP2LSu3zMqd fkThvaV5jphdtEzbnRkiz6M9DdgE2Bn+B03SrPulVrXhk4t5hOLZRXPS3k0t/7U6s9oxvnojx4J dXAA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 X-Mailman-Approved-At: Sat, 14 Nov 2026 05:56:41 -0800 X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-nvme" X-Spam-Status: No, score=-18.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 loop_configure() takes any file as long as it implements ->read_iter(). Loop itself never checked whether the file was actually opened for reading. Buffered I/O went through vfs_iter_read() which refuses files without FMODE_READ. Direct I/O has called ->read_iter() of the backing file directly ever since loop grew support for it. Since commit f2fed441c69b ("loop: stop using vfs_iter_{read,write} for buffered I/O") buffered I/O calls ->read_iter() directly as well. That commit was about O_DIRECT handling and the FMODE_READ check went away as a side effect. So whoever can set up a loop device can read a file it was only allowed to open for writing. Open the file O_WRONLY, configure a loop device with it and read the contents through the loop device. Refuse backing files that aren't open for reading. Loop always reads from its backing file so a write-only backing file never made sense in the first place. Fixes: bc07c10a3603 ("block: loop: support DIO & AIO") Fixes: f2fed441c69b ("loop: stop using vfs_iter_{read,write} for buffered I/O") Cc: stable@vger.kernel.org Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Reviewed-by: Alexander Mikhalitsyn Signed-off-by: Christian Brauner (Amutable) --- drivers/block/loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index a3325ceab484a..c96e35c3ef423 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -528,6 +528,9 @@ static void loop_assign_backing_file(struct loop_device *lo, struct file *file) static int loop_check_backing_file(struct file *file) { + if (!(file->f_mode & FMODE_READ)) + return -EBADF; + if (!file->f_op->read_iter) return -EINVAL; -- 2.53.0