Linux Security Modules development
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: linux-fsdevel@vger.kernel.org
Cc: Jann Horn <jannh@google.com>, Chris Mason <mason@kernel.org>,
	 Josef Bacik <josef@toxicpanda.com>,
	Christoph Hellwig <hch@lst.de>,
	 linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-nvme@lists.infradead.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 Jan Kara <jack@suse.cz>,
	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 <amir73il@gmail.com>,
	linux-erofs@lists.ozlabs.org,  linux-kselftest@vger.kernel.org,
	 "Christian Brauner (Amutable)" <brauner@kernel.org>
Subject: [PATCH RFC v2 34/42] loop: refuse files on pseudo filesystems as backing files
Date: Sat, 14 Nov 2026 14:02:15 +0100	[thread overview]
Message-ID: <20261114-work-loop-pseudo-v2-34-98639a2286fb@kernel.org> (raw)
In-Reply-To: <20261114-work-loop-pseudo-v2-0-98639a2286fb@kernel.org>

Currently loop accepts any regular file that implements ->read_iter() as
a backing file and any that also implements ->write_iter() as a writable
one. That includes files on procfs, sysfs and other pseudo filesystems.
For example, /proc/kcore attaches read-only as a loop device the size of
the kernel's virtual address space, 64 PiB with 5-level paging. sysfs
attributes attach read-write as 4096 byte loop devices. Writing a block
to the loop device of /sys/kernel/mm/transparent_hugepage/enabled
changes the THP setting.

That's not just nonsensical, it can be abused. Loop calls ->read_iter()
and ->write_iter() of the backing file directly from its worker which
runs with kernel credentials. But pseudo files enforce part of their
access rules at read and write time against current. Dozens of sysfs
->show() and ->store() methods call capable(). Behind a loop device all
of these checks are done against the loop worker instead of the task
that opened the file. And setting up a loop device requires no
capabilities, only access to the device nodes. So on v7.4-rc1:

- uid 0 without any capabilities can't write to /sys/kernel/reboot/mode
  as mode_store() requires CAP_SYS_BOOT. Writing "warm" through a loop
  device works.

- uid 0 without any capabilities can't read the files in
  /sys/firmware/dmi/entries/*/ as dmi_sysfs_attr_show() requires
  CAP_SYS_ADMIN. Reading them through a loop device works.

- An unprivileged container that was handed a loop device can't change
  gro_flush_timeout of its own network devices as
  gro_flush_timeout_store() requires CAP_NET_ADMIN in the initial user
  namespace. Writing it through a loop device works.

The same goes for hard_offline_page, the md and sd attributes, rfkill
and others.

Refuse files on pseudo filesystems as loop backing files by switching to
file_check_backing(). Note that it looks through overlayfs so stacking
overlayfs on top of sysfs doesn't get around this.

The helper also does the file type, open mode and method checks that
loop did itself so far. The check for a regular file or a block device
now happens before the loop device is locked and it looks at the inode
of the file instead of the host of ->f_mapping. For regular files and
block devices both have the same type.

Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---
 drivers/block/loop.c | 17 ++++-------------
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index c96e35c3ef423..776bd063f900c 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -492,7 +492,6 @@ static inline int is_loop_device(struct file *file)
 
 static int loop_validate_file(struct file *file, struct block_device *bdev)
 {
-	struct inode	*inode = file->f_mapping->host;
 	struct file	*f = file;
 
 	/* Avoid recursion */
@@ -510,8 +509,6 @@ static int loop_validate_file(struct file *file, struct block_device *bdev)
 		rmb();
 		f = l->lo_backing_file;
 	}
-	if (!S_ISREG(inode->i_mode) && !S_ISBLK(inode->i_mode))
-		return -EINVAL;
 	return 0;
 }
 
@@ -528,16 +525,10 @@ 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;
-
-	if ((file->f_mode & FMODE_WRITE) && !file->f_op->write_iter)
-		return -EINVAL;
-
-	return 0;
+	/* A backing file that isn't open for writing gives a read-only device. */
+	return file_check_backing(file,
+				  FMODE_READ | (file->f_mode & FMODE_WRITE),
+				  S_IFBLK);
 }
 
 /* loop sysfs attributes */

-- 
2.53.0


  parent reply	other threads:[~2026-11-14 13:09 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 13:01 [PATCH RFC v2 00/42] fs: don't use pseudo filesystem files as storage Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 01/42] loop: refuse backing files that aren't open for reading Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 02/42] nvmet: check that the file backend supports ->{read,write}_iter Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 03/42] target: fileio: check that the backing file " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 04/42] fs: add SB_I_PSEUDO Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 05/42] kernfs: use fc_init_pseudo() Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 06/42] proc: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 07/42] binfmt_misc: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 08/42] mqueue: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 09/42] bpf: use fc_init_pseudo() for bpffs Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 10/42] nullfs: use fc_init_pseudo() Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 11/42] failfs: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 12/42] rust_binderfs: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 13/42] devpts: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 14/42] debugfs: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 15/42] tracefs: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 16/42] configfs: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 17/42] securityfs: " Christian Brauner
2026-11-14 13:01 ` [PATCH RFC v2 18/42] selinux: use fc_init_pseudo() for selinuxfs Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 19/42] smack: use fc_init_pseudo() for smackfs Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 20/42] apparmor: use fc_init_pseudo() for apparmorfs Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 21/42] nfsd: use fc_init_pseudo() Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 22/42] sunrpc: use fc_init_pseudo() for rpc_pipefs Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 23/42] fuse: use fc_init_pseudo() for fusectl Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 24/42] efivarfs: use fc_init_pseudo() Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 25/42] pstore: " Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 26/42] xenfs: " Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 27/42] openpromfs: " Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 28/42] ocfs2: use fc_init_pseudo() for dlmfs Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 29/42] s390/hypfs: use fc_init_pseudo() Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 30/42] powerpc/spufs: " Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 31/42] usb: gadget: f_fs: " Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 32/42] usb: gadget: gadgetfs: " Christian Brauner
2026-11-14 13:02 ` [PATCH RFC v2 33/42] fs: add file_check_backing() Christian Brauner
2026-11-14 13:02 ` Christian Brauner [this message]
2026-11-14 13:02 ` [PATCH RFC v2 35/42] zloop: refuse zone files on pseudo filesystems Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261114-work-loop-pseudo-v2-34-98639a2286fb@kernel.org \
    --to=brauner@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=apparmor@lists.ubuntu.com \
    --cc=bpf@vger.kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=fuse-devel@lists.linux.dev \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mason@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ocfs2-devel@lists.linux.dev \
    --cc=selinux@vger.kernel.org \
    --cc=target-devel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox