From: Zheng Qixing zhengqixing@huawei.com
From: Jan Kara jack@suse.cz
[ Upstream commit 7e49538288e523427beedd26993d446afef1a6fb ]
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 Tested-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20250711163202.19623-2-jack@suse.cz Signed-off-by: Zheng Qixing zhengqixing@huawei.com --- drivers/block/loop.c | 40 +++++++++++++++++++++++++++++++--------- 1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 455e2a2b149f..6fe9180aafb3 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1472,19 +1472,36 @@ static int loop_set_dio(struct loop_device *lo, unsigned long arg) return error; }
-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) { 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; + }
err = blk_validate_block_size(arg); if (err) - return err; + 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); @@ -1496,6 +1513,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);
+unlock: + mutex_unlock(&lo->lo_mutex); +abort_claim: + if (!(mode & BLK_OPEN_EXCL)) + bd_abort_claiming(bdev, loop_set_block_size); return err; }
@@ -1514,9 +1536,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; } @@ -1571,9 +1590,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;
On Tue, Sep 30, 2025 at 02:49:33PM +0800, Zheng Qixing wrote:
From: Zheng Qixing zhengqixing@huawei.com
From: Jan Kara jack@suse.cz
[ Upstream commit 7e49538288e523427beedd26993d446afef1a6fb ]
This is already in the 6.6.103 release, so how can we apply it again?
thanks,
greg k-h
在 2025/9/30 15:34, Greg KH 写道:
On Tue, Sep 30, 2025 at 02:49:33PM +0800, Zheng Qixing wrote:
From: Zheng Qixing zhengqixing@huawei.com
From: Jan Kara jack@suse.cz
[ Upstream commit 7e49538288e523427beedd26993d446afef1a6fb ]
This is already in the 6.6.103 release, so how can we apply it again?
147338df3487 (tag: v6.6.108, origin/linux-6.6.y) Linux 6.6.108 42a6aeb4b238 Revert "loop: Avoid updating block size under exclusive owner"
We revert this in 6.6.108 since this incorrect adaptation will introduce some hungtask bug. And patch from Qixing is correct.
Thanks, Erkun.
thanks,
greg k-h
Hi,
The patch applied in the 6.6.103 release encountered issues when adapted to the 6.6.y branch and was reverted in 6.6.108 (commit 42a6aeb4b238, “Revert ‘loop: Avoid updating block size under exclusive owner’”).
We have reworked the backport to address the adaptation problems. Could you please review and re-apply the updated patch?
Please let me know if you need anything else.
Thanks,
Qixing
在 2025/9/30 15:34, Greg KH 写道:
On Tue, Sep 30, 2025 at 02:49:33PM +0800, Zheng Qixing wrote:
From: Zheng Qixing zhengqixing@huawei.com
From: Jan Kara jack@suse.cz
[ Upstream commit 7e49538288e523427beedd26993d446afef1a6fb ]
This is already in the 6.6.103 release, so how can we apply it again?
thanks,
greg k-h
On Tue, Sep 30, 2025 at 03:51:39PM +0800, Zheng Qixing wrote:
Hi,
The patch applied in the 6.6.103 release encountered issues when adapted to the 6.6.y branch and was reverted in 6.6.108 (commit 42a6aeb4b238, “Revert ‘loop: Avoid updating block size under exclusive owner’”).
We have reworked the backport to address the adaptation problems. Could you please review and re-apply the updated patch?
Ah, I had missed that we reverted it, sorry for the noise.
Now queued up, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org