[syzbot] [exfat?] WARNING in bdev_getblk

[syzbot] [exfat?] WARNING in bdev_getblk

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    26ffb3d6f02c Add linux-next specific files for 20250704
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=127fc28c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=1e4f88512ae53408
dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/fd5569903143/disk-26ffb3d6.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1b0c9505c543/vmlinux-26ffb3d6.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9d864c72bed1/bzImage-26ffb3d6.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com

ERROR: (device loop0): force_metapage: metapage_write_one() failed
------------[ cut here ]------------
WARNING: fs/buffer.c:1125 at __getblk_slow fs/buffer.c:1125 [inline], CPU#0: syz.0.12/6044
WARNING: fs/buffer.c:1125 at bdev_getblk+0x580/0x660 fs/buffer.c:1461, CPU#0: syz.0.12/6044
Modules linked in:
CPU: 0 UID: 0 PID: 6044 Comm: syz.0.12 Not tainted 6.16.0-rc4-next-20250704-syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:__getblk_slow fs/buffer.c:1125 [inline]
RIP: 0010:bdev_getblk+0x580/0x660 fs/buffer.c:1461
Code: 26 fb ff ff e8 31 e3 78 ff 48 c7 c7 a0 fd 99 8b 48 c7 c6 b8 e6 9f 8d 4c 89 fa 4c 89 e9 e8 48 d0 e0 fe eb bd e8 11 e3 78 ff 90 <0f> 0b 90 48 b8 00 00 00 00 00 fc ff df 41 80 3c 07 00 74 08 48 89
RSP: 0018:ffffc90005256f18 EFLAGS: 00010287
RAX: ffffffff8246cd6f RBX: ffff888022ccc518 RCX: 0000000000080000
RDX: ffffc9000d19d000 RSI: 000000000003d82f RDI: 000000000003d830
RBP: 0000000000001000 R08: 0000000000000000 R09: ffffffff8216f9cd
R10: dffffc0000000000 R11: fffff940003e86a7 R12: ffff888022ccce68
R13: ffff888022ccc500 R14: 0000000000001000 R15: 1ffff110045998a3
FS:  00007f72617f66c0(0000) GS:ffff888125be7000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000009000 CR3: 0000000075c0a000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 __bread_gfp+0x89/0x3c0 fs/buffer.c:1515
 sb_bread include/linux/buffer_head.h:346 [inline]
 readSuper+0xdb/0x270 fs/jfs/jfs_mount.c:461
 updateSuper+0x1cf/0x5d0 fs/jfs/jfs_mount.c:423
 jfs_handle_error fs/jfs/super.c:69 [inline]
 jfs_error+0x198/0x2c0 fs/jfs/super.c:98
 force_metapage+0x1e7/0x360 fs/jfs/jfs_metapage.c:839
 txForce fs/jfs/jfs_txnmgr.c:2215 [inline]
 txCommit+0x4c05/0x5430 fs/jfs/jfs_txnmgr.c:1315
 duplicateIXtree+0x292/0x490 fs/jfs/jfs_imap.c:3019
 diNewIAG fs/jfs/jfs_imap.c:2597 [inline]
 diAllocExt fs/jfs/jfs_imap.c:1905 [inline]
 diAllocAG+0x17a7/0x1df0 fs/jfs/jfs_imap.c:1669
 diAlloc+0x1d5/0x1680 fs/jfs/jfs_imap.c:1590
 ialloc+0x8c/0x8f0 fs/jfs/jfs_inode.c:56
 jfs_create+0x18d/0xa80 fs/jfs/namei.c:92
 lookup_open fs/namei.c:3708 [inline]
 open_last_lookups fs/namei.c:3807 [inline]
 path_openat+0x14f1/0x3830 fs/namei.c:4043
 do_filp_open+0x1fa/0x410 fs/namei.c:4073
 do_sys_openat2+0x121/0x1c0 fs/open.c:1434
 do_sys_open fs/open.c:1449 [inline]
 __do_sys_openat fs/open.c:1465 [inline]
 __se_sys_openat fs/open.c:1460 [inline]
 __x64_sys_openat+0x138/0x170 fs/open.c:1460
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f726398e929
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f72617f6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007f7263bb6080 RCX: 00007f726398e929
RDX: 000000000000275a RSI: 0000200000000540 RDI: ffffffffffffff9c
RBP: 00007f7263a10b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000001 R14: 00007f7263bb6080 R15: 00007ffc735ef598
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [ext4?] WARNING in bdev_getblk

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    835244aba90d Add linux-next specific files for 20250709
git tree:       linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=10535a8c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8396fd456733c122
dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=115c40f0580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11856a8c580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e5c5711c47f9/disk-835244ab.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/dd2453f9f672/vmlinux-835244ab.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a81cc03651e7/bzImage-835244ab.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/e3888e058fbc/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=12856a8c580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: fs/buffer.c:1125 at __getblk_slow fs/buffer.c:1125 [inline], CPU#0: syz-executor261/5880
WARNING: fs/buffer.c:1125 at bdev_getblk+0x580/0x660 fs/buffer.c:1461, CPU#0: syz-executor261/5880
Modules linked in:
CPU: 0 UID: 0 PID: 5880 Comm: syz-executor261 Not tainted 6.16.0-rc5-next-20250709-syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:__getblk_slow fs/buffer.c:1125 [inline]
RIP: 0010:bdev_getblk+0x580/0x660 fs/buffer.c:1461
Code: 26 fb ff ff e8 81 ee 78 ff 48 c7 c7 20 08 9a 8b 48 c7 c6 02 1b a0 8d 4c 89 fa 4c 89 e9 e8 38 d7 e0 fe eb bd e8 61 ee 78 ff 90 <0f> 0b 90 48 b8 00 00 00 00 00 fc ff df 41 80 3c 07 00 74 08 48 89
RSP: 0018:ffffc9000403f620 EFLAGS: 00010293
RAX: ffffffff8246c6ff RBX: ffff888022d0b998 RCX: ffff888078b31e00
RDX: 0000000000000000 RSI: 0000000000000400 RDI: 0000000000000000
RBP: 0000000000000400 R08: ffff888078b31e00 R09: 0000000000000003
R10: 0000000000000406 R11: 0000000000000000 R12: dffffc0000000000
R13: ffff888022d0b980 R14: 0000000000000400 R15: 1ffff110045a1733
FS:  000055558d712380(0000) GS:ffff888125bd4000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5b0e5d6000 CR3: 00000000227ea000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 ext4_sb_breadahead_unmovable+0x6f/0xf0 fs/ext4/super.c:270
 __ext4_get_inode_loc+0xcc9/0x1040 fs/ext4/inode.c:4879
 __ext4_get_inode_loc_noinmem fs/ext4/inode.c:4909 [inline]
 __ext4_iget+0x450/0x4260 fs/ext4/inode.c:5168
 __ext4_fill_super fs/ext4/super.c:5500 [inline]
 ext4_fill_super+0x4592/0x6080 fs/ext4/super.c:5724
 get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1681
 vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
 do_new_mount+0x2a2/0x9e0 fs/namespace.c:3805
 do_mount fs/namespace.c:4133 [inline]
 __do_sys_mount fs/namespace.c:4344 [inline]
 __se_sys_mount+0x317/0x410 fs/namespace.c:4321
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f457044b7da
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 5e 04 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd924f6f58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffd924f6f70 RCX: 00007f457044b7da
RDX: 0000200000000040 RSI: 0000200000000000 RDI: 00007ffd924f6f70
RBP: 0000200000000000 R08: 00007ffd924f6fb0 R09: 00007ffd924f6fb0
R10: 000000000000088e R11: 0000000000000246 R12: 0000200000000040
R13: 00007ffd924f6fb0 R14: 0000000000000003 R15: 000000000000088e
 </TASK>


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

Re: [syzbot] [ext4?] WARNING in bdev_getblk

[syzbot]

syzbot has bisected this issue to:

commit 77eb64439ad52d8afb57bb4dae24a2743c68f50d
Author: Pankaj Raghav <p.raghav@samsung.com>
Date:   Thu Jun 26 11:32:23 2025 +0000

    fs/buffer: remove the min and max limit checks in __getblk_slow()

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=127d8d82580000
start commit:   835244aba90d Add linux-next specific files for 20250709
git tree:       linux-next
final oops:     https://syzkaller.appspot.com/x/report.txt?x=117d8d82580000
console output: https://syzkaller.appspot.com/x/log.txt?x=167d8d82580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8396fd456733c122
dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=115c40f0580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11856a8c580000

Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com
Fixes: 77eb64439ad5 ("fs/buffer: remove the min and max limit checks in __getblk_slow()")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [syzbot] [ext4?] WARNING in bdev_getblk

[Jan Kara]

On Fri 11-07-25 05:27:01, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit 77eb64439ad52d8afb57bb4dae24a2743c68f50d
> Author: Pankaj Raghav <p.raghav@samsung.com>
> Date:   Thu Jun 26 11:32:23 2025 +0000
> 
>     fs/buffer: remove the min and max limit checks in __getblk_slow()
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=127d8d82580000
> start commit:   835244aba90d Add linux-next specific files for 20250709
> git tree:       linux-next
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=117d8d82580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=167d8d82580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8396fd456733c122
> dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=115c40f0580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11856a8c580000
> 
> Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com
> Fixes: 77eb64439ad5 ("fs/buffer: remove the min and max limit checks in __getblk_slow()")
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Ah, I see what's going on here. The reproducer mounts ext4 filesystem and
sets block size on loop0 loop device to 32k using LOOP_SET_BLOCK_SIZE. Now
because there are multiple reproducer running using various loop devices it
can happen that we're setting blocksize during mount which obviously
confuses the filesystem (and makes sb mismatch the bdev block size). It is
really not a good idea to allow setting block size (or capacity for that
matter) underneath an exclusive opener. The ioctl should have required
exclusive open from the start but now it's too late to change that so we
need to perform a similar dance with bd_prepare_to_claim() as in
loop_configure() to grab temporary exclusive access... Sigh.

Anyway, the commit 77eb64439ad5 is just a victim that switched KERN_ERR
messages in the log to WARN_ON so syzbot started to notice this breakage.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [syzbot] [ext4?] WARNING in bdev_getblk

[Jan Kara]

On Fri 11-07-25 17:51:40, Jan Kara wrote:
> On Fri 11-07-25 05:27:01, syzbot wrote:
> > syzbot has bisected this issue to:
> > 
> > commit 77eb64439ad52d8afb57bb4dae24a2743c68f50d
> > Author: Pankaj Raghav <p.raghav@samsung.com>
> > Date:   Thu Jun 26 11:32:23 2025 +0000
> > 
> >     fs/buffer: remove the min and max limit checks in __getblk_slow()
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=127d8d82580000
> > start commit:   835244aba90d Add linux-next specific files for 20250709
> > git tree:       linux-next
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=117d8d82580000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=167d8d82580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=8396fd456733c122
> > dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=115c40f0580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11856a8c580000
> > 
> > Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com
> > Fixes: 77eb64439ad5 ("fs/buffer: remove the min and max limit checks in __getblk_slow()")
> > 
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> Ah, I see what's going on here. The reproducer mounts ext4 filesystem and
> sets block size on loop0 loop device to 32k using LOOP_SET_BLOCK_SIZE. Now
> because there are multiple reproducer running using various loop devices it
> can happen that we're setting blocksize during mount which obviously
> confuses the filesystem (and makes sb mismatch the bdev block size). It is
> really not a good idea to allow setting block size (or capacity for that
> matter) underneath an exclusive opener. The ioctl should have required
> exclusive open from the start but now it's too late to change that so we
> need to perform a similar dance with bd_prepare_to_claim() as in
> loop_configure() to grab temporary exclusive access... Sigh.
> 
> Anyway, the commit 77eb64439ad5 is just a victim that switched KERN_ERR
> messages in the log to WARN_ON so syzbot started to notice this breakage.

Sent fix here:
https://lore.kernel.org/all/20250711163202.19623-2-jack@suse.cz

								Honza

#syz test

From 4aa776eb9b3967bff31087b7595ddcc902200056 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Fri, 11 Jul 2025 18:16:44 +0200
Subject: [PATCH] loop: Avoid updating block size under exclusive owner
X-Developer-Signature: v=1; a=openpgp-sha256; l=3277; i=jack@suse.cz;
 h=from:subject; bh=cdZuEh4Dk+/Xi2fTOZRQxovM+RzBRb1FW6MBEN4Icws=;
 b=owGbwMvMwME4Z+4qdvsUh5uMp9WSGDIKbZq0xH0Ml+s1mUn/FXh44vuGfB7/6WemZT/fv/SJRXZ0
 +Oc9nYzGLAyMHAyyYoosqyMval+bZ9S1NVRDBmYQKxPIFAYuTgGYyJE37P+TzLkNtVn5K1Q9Umaq3T
 Vmcb4tyOvXYsYcLfHv9g9F9zVruARylmxL8Gx73a307cwFM9/kww0b8vqYHvX33H2TnVeYsO+NW0RF
 KsOmd0cUjl7aWW4kFO6cOtNdIZ/HrHijk2bAKdYZ1wwucvbN27p4kRvXZfMu06WeZyz/7+FrF/9270
 Ostl1ml45ORWBlp5amyvXZvl33u5tr76znST50+oRf0to8n2afbSZCK3Ris+7MjpqnMo+lK+Sf5s/+
 L65hUjq2EwOyugu3PAk1khb9cHXhXN6anJo32VfsI6N+MsSzMxh+4O86wRg/98EH3obLLcIX2wOjKu
 es+vb1lH1Gx6ctQVE7E7Ok87oA
X-Developer-Key: i=jack@suse.cz; a=openpgp;
 fpr=93C6099A142276A28BBE35D815BC833443038D8C

Syzbot came up with a reproducer where a loop device block size is
changed underneath a mounted filesystem. This causes a mismatch between
the block device block size and the block size stored in the superblock
causing confusion in various places such as fs/buffer.c. The particular
issue triggered by syzbot was a warning in __getblk_slow() due to
requested buffer size not matching block device block size.

Fix the problem by getting exclusive hold of the loop device to change
its block size. This fails if somebody (such as filesystem) has already
an exclusive ownership of the block device and thus prevents modifying
the loop device under some exclusive owner which doesn't expect it.

Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com
Signed-off-by: Jan Kara <jack@suse.cz>
---
 drivers/block/loop.c | 38 ++++++++++++++++++++++++++++++--------
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 500840e4a74e..5cc72770e253 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1432,17 +1432,34 @@ static int loop_set_dio(struct loop_device *lo, unsigned long arg)
 	return 0;
 }
 
-static int loop_set_block_size(struct loop_device *lo, unsigned long arg)
+static int loop_set_block_size(struct loop_device *lo, blk_mode_t mode,
+			       struct block_device *bdev, unsigned long arg)
 {
 	struct queue_limits lim;
 	unsigned int memflags;
 	int err = 0;
 
-	if (lo->lo_state != Lo_bound)
-		return -ENXIO;
+	/*
+	 * If we don't hold exclusive handle for the device, upgrade to it
+	 * here to avoid changing device under exclusive owner.
+	 */
+	if (!(mode & BLK_OPEN_EXCL)) {
+		err = bd_prepare_to_claim(bdev, loop_set_block_size, NULL);
+		if (err)
+			return err;
+	}
+
+	err = mutex_lock_killable(&lo->lo_mutex);
+	if (err)
+		goto abort_claim;
+
+	if (lo->lo_state != Lo_bound) {
+		err = -ENXIO;
+		goto unlock;
+	}
 
 	if (lo->lo_queue->limits.logical_block_size == arg)
-		return 0;
+		goto unlock;
 
 	sync_blockdev(lo->lo_device);
 	invalidate_bdev(lo->lo_device);
@@ -1455,6 +1472,11 @@ static int loop_set_block_size(struct loop_device *lo, unsigned long arg)
 	loop_update_dio(lo);
 	blk_mq_unfreeze_queue(lo->lo_queue, memflags);
 
+unlock:
+	mutex_unlock(&lo->lo_mutex);
+abort_claim:
+	if (!(mode & BLK_OPEN_EXCL))
+		bd_abort_claiming(bdev, loop_set_block_size);
 	return err;
 }
 
@@ -1473,9 +1495,6 @@ static int lo_simple_ioctl(struct loop_device *lo, unsigned int cmd,
 	case LOOP_SET_DIRECT_IO:
 		err = loop_set_dio(lo, arg);
 		break;
-	case LOOP_SET_BLOCK_SIZE:
-		err = loop_set_block_size(lo, arg);
-		break;
 	default:
 		err = -EINVAL;
 	}
@@ -1530,9 +1549,12 @@ static int lo_ioctl(struct block_device *bdev, blk_mode_t mode,
 		break;
 	case LOOP_GET_STATUS64:
 		return loop_get_status64(lo, argp);
+	case LOOP_SET_BLOCK_SIZE:
+		if (!(mode & BLK_OPEN_WRITE) && !capable(CAP_SYS_ADMIN))
+			return -EPERM;
+		return loop_set_block_size(lo, mode, bdev, arg);
 	case LOOP_SET_CAPACITY:
 	case LOOP_SET_DIRECT_IO:
-	case LOOP_SET_BLOCK_SIZE:
 		if (!(mode & BLK_OPEN_WRITE) && !capable(CAP_SYS_ADMIN))
 			return -EPERM;
 		fallthrough;
-- 
2.43.0

Re: [syzbot] [ext4?] WARNING in bdev_getblk

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com
Tested-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com

Tested on:

commit:         a62b7a37 Add linux-next specific files for 20250711
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13b87a8c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=bb4e3ec360fcbd0f
dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
patch:          https://syzkaller.appspot.com/x/patch.diff?x=14c6c68c580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [ext4?] WARNING in bdev_getblk

[Pankaj Raghav (Samsung)]

> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=127d8d82580000
> > start commit:   835244aba90d Add linux-next specific files for 20250709
> > git tree:       linux-next
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=117d8d82580000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=167d8d82580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=8396fd456733c122
> > dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=115c40f0580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11856a8c580000
> > 
> > Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com
> > Fixes: 77eb64439ad5 ("fs/buffer: remove the min and max limit checks in __getblk_slow()")
> > 
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> Ah, I see what's going on here. The reproducer mounts ext4 filesystem and
> sets block size on loop0 loop device to 32k using LOOP_SET_BLOCK_SIZE. Now
> because there are multiple reproducer running using various loop devices it
> can happen that we're setting blocksize during mount which obviously
> confuses the filesystem (and makes sb mismatch the bdev block size). It is
> really not a good idea to allow setting block size (or capacity for that
> matter) underneath an exclusive opener. The ioctl should have required
> exclusive open from the start but now it's too late to change that so we
> need to perform a similar dance with bd_prepare_to_claim() as in
> loop_configure() to grab temporary exclusive access... Sigh.
> 
> Anyway, the commit 77eb64439ad5 is just a victim that switched KERN_ERR
> messages in the log to WARN_ON so syzbot started to notice this breakage.

I was also thinking the change we did from KERN_ERR to WARN_ON was catching
a different bug.

Thanks for taking a look and fixing the issue Jan.

-- 
Pankaj Raghav