From: syzbot <syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] loop: block changing lo_offset/lo_sizelimit on mounted device
Date: Mon, 30 Mar 2026 18:04:34 -0700 [thread overview]
Message-ID: <69cb1da2.a70a0220.97f31.0229.GAE@google.com> (raw)
In-Reply-To: <699b9b6f.a70a0220.2c38d7.0189.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] loop: block changing lo_offset/lo_sizelimit on mounted device
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
LOOP_SET_STATUS{64} allows changing lo_offset and shrinking
lo_sizelimit while a filesystem is mounted on the loop device.
This effectively mutates the data visible to the mounted filesystem,
which is equivalent to writing directly to the block device.
When CONFIG_BLK_DEV_WRITE_MOUNTED is disabled, direct writes to a
mounted block device are blocked. However, LOOP_SET_STATUS{64}
bypasses this protection because it modifies the loop configuration
through an ioctl rather than opening the block device for writing.
Fix this by checking bdev_writes_blocked() before allowing changes
to lo_offset or shrinking lo_sizelimit. If the loop device has
writes blocked, return -EBUSY. Increasing lo_sizelimit is still
allowed since growing the device is harmless and has legitimate
use cases such as online resize.
Move bdev_writes_blocked() from block/bdev.c to
include/linux/blk_types.h as a static inline function so it can
be used from the loop driver without exporting a symbol.
Reported-by: syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
v2:
- Use #ifndef CONFIG_BLK_DEV_WRITE_MOUNTED instead of exporting
bdev_writes_blocked(), as suggested by Ted Ts'o
- Move bdev_writes_blocked() to include/linux/blk_types.h as
static inline instead of exporting from block/bdev.c, as
suggested by Christoph Hellwig
- Allow increasing lo_sizelimit since growing the device is
harmless, as pointed out by Christoph Hellwig
- Remove spurious empty line
---
block/bdev.c | 5 -----
drivers/block/loop.c | 16 ++++++++++++++++
include/linux/blk_types.h | 5 +++++
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/block/bdev.c b/block/bdev.c
index ed022f8c48c7..e0bace1a6c27 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -860,11 +860,6 @@ void blkdev_put_no_open(struct block_device *bdev)
put_device(&bdev->bd_device);
}
-static bool bdev_writes_blocked(struct block_device *bdev)
-{
- return bdev->bd_writers < 0;
-}
-
static void bdev_block_writes(struct block_device *bdev)
{
bdev->bd_writers--;
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0000913f7efc..34bbbf3bcb36 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1239,6 +1239,22 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
goto out_unlock;
}
+#ifndef CONFIG_BLK_DEV_WRITE_MOUNTED
+ /*
+ * Changing lo_offset or shrinking lo_sizelimit on a mounted
+ * device is equivalent to modifying the block device contents.
+ * Block this if writes to the device are blocked.
+ */
+ if ((lo->lo_offset != info->lo_offset ||
+ (info->lo_sizelimit &&
+ (lo->lo_sizelimit == 0 ||
+ info->lo_sizelimit < lo->lo_sizelimit))) &&
+ bdev_writes_blocked(lo->lo_device)) {
+ err = -EBUSY;
+ goto out_unlock;
+ }
+#endif
+
if (lo->lo_offset != info->lo_offset ||
lo->lo_sizelimit != info->lo_sizelimit) {
size_changed = true;
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 8808ee76e73c..82ece8737b85 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -84,6 +84,11 @@ struct block_device {
#define bdev_whole(_bdev) \
((_bdev)->bd_disk->part0)
+static inline bool bdev_writes_blocked(struct block_device *bdev)
+{
+ return bdev->bd_writers < 0;
+}
+
#define dev_to_bdev(device) \
container_of((device), struct block_device, bd_device)
--
2.43.0
prev parent reply other threads:[~2026-03-31 1:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 0:12 [syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2) syzbot
2026-02-24 8:36 ` Forwarded: [PATCH] ext4: add bounds check in xattr_find_entry() to prevent use-after-free syzbot
2026-02-24 8:52 ` syzbot
2026-03-26 14:50 ` Forwarded: [PATCH] ext4: fix bounds check in check_xattrs() to account for IS_LAST_ENTRY() read syzbot
2026-03-27 13:28 ` Forwarded: [PATCH] ext4: add debug printk to trace xattr validation path syzbot
2026-03-30 1:43 ` Forwarded: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device syzbot
2026-03-31 1:04 ` syzbot [this message]
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=69cb1da2.a70a0220.97f31.0229.GAE@google.com \
--to=syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.