[PATCH 6.6.y] loop: Avoid updating block size under exclusive owner

[PATCH 6.6.y] loop: Avoid updating block size under exclusive owner

[Zheng Qixing]

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;
-- 
2.39.2

Re: [PATCH 6.6.y] loop: Avoid updating block size under exclusive owner

[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

Re: [PATCH 6.6.y] loop: Avoid updating block size under exclusive owner

[yangerkun]

在 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
> 

Re: [PATCH 6.6.y] loop: Avoid updating block size under exclusive owner

[Zheng Qixing]

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

Re: [PATCH 6.6.y] loop: Avoid updating block size under exclusive owner

[Greg KH]

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