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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox