[PATCH AUTOSEL 5.1 29/70] io_uring: Fix __io_uring_register() false success

[PATCH AUTOSEL 5.1 29/70] io_uring: Fix __io_uring_register() false success

[Sasha Levin]

From: Pavel Begunkov <asml.silence@gmail.com>

[ Upstream commit a278682dad37fd2f8d2f30d8e84e376a856ab472 ]

If io_copy_iov() fails, it will break the loop and report success,
albeit partially completed operation.

Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 fs/io_uring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 30a5687a17b6..69ff94558758 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2505,7 +2505,7 @@ static int io_sqe_buffer_register(struct io_ring_ctx *ctx, void __user *arg,
 
 		ret = io_copy_iov(ctx, &iov, arg, i);
 		if (ret)
-			break;
+			goto err;
 
 		/*
 		 * Don't impose further limits on the size and buffer
-- 
2.20.1

[PATCH AUTOSEL 5.1 35/70] loop: Don't change loop device under exclusive opener

[Sasha Levin]

From: Jan Kara <jack@suse.cz>

[ Upstream commit 33ec3e53e7b1869d7851e59e126bdb0fe0bd1982 ]

Loop module allows calling LOOP_SET_FD while there are other openers of
the loop device. Even exclusive ones. This can lead to weird
consequences such as kernel deadlocks like:

mount_bdev()				lo_ioctl()
  udf_fill_super()
    udf_load_vrs()
      sb_set_blocksize() - sets desired block size B
      udf_tread()
        sb_bread()
          __bread_gfp(bdev, block, B)
					  loop_set_fd()
					    set_blocksize()
            - now __getblk_slow() indefinitely loops because B != bdev
              block size

Fix the problem by disallowing LOOP_SET_FD ioctl when there are
exclusive openers of a loop device.

[Deliberately chosen not to CC stable as a user with priviledges to
trigger this race has other means of taking the system down and this
has a potential of breaking some weird userspace setup]

Reported-and-tested-by: syzbot+10007d66ca02b08f0e60@syzkaller.appspotmail.com
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/block/loop.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index bf1c61cab8eb..21349a17f7f5 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -919,9 +919,20 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
 	if (!file)
 		goto out;
 
+	/*
+	 * If we don't hold exclusive handle for the device, upgrade to it
+	 * here to avoid changing device under exclusive owner.
+	 */
+	if (!(mode & FMODE_EXCL)) {
+		bdgrab(bdev);
+		error = blkdev_get(bdev, mode | FMODE_EXCL, loop_set_fd);
+		if (error)
+			goto out_putf;
+	}
+
 	error = mutex_lock_killable(&loop_ctl_mutex);
 	if (error)
-		goto out_putf;
+		goto out_bdev;
 
 	error = -EBUSY;
 	if (lo->lo_state != Lo_unbound)
@@ -985,10 +996,15 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
 	mutex_unlock(&loop_ctl_mutex);
 	if (partscan)
 		loop_reread_partitions(lo, bdev);
+	if (!(mode & FMODE_EXCL))
+		blkdev_put(bdev, mode | FMODE_EXCL);
 	return 0;
 
 out_unlock:
 	mutex_unlock(&loop_ctl_mutex);
+out_bdev:
+	if (!(mode & FMODE_EXCL))
+		blkdev_put(bdev, mode | FMODE_EXCL);
 out_putf:
 	fput(file);
 out:
-- 
2.20.1

[PATCH AUTOSEL 5.1 60/70] blk-mq: Fix memory leak in error handling

[Sasha Levin]

From: Jes Sorensen <jsorensen@fb.com>

[ Upstream commit 41de54c64811bf087c8464fdeb43c6ad8be2686b ]

If blk_mq_init_allocated_queue() fails, make sure to free the poll
stat callback struct allocated.

Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 block/blk-mq.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 8a41cc5974fe..95e8005982cd 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2844,7 +2844,7 @@ struct request_queue *blk_mq_init_allocated_queue(struct blk_mq_tag_set *set,
 		goto err_exit;
 
 	if (blk_mq_alloc_ctxs(q))
-		goto err_exit;
+		goto err_poll;
 
 	/* init q->mq_kobj and sw queues' kobjects */
 	blk_mq_sysfs_init(q);
@@ -2905,6 +2905,9 @@ err_hctxs:
 	kfree(q->queue_hw_ctx);
 err_sys_init:
 	blk_mq_sysfs_deinit(q);
+err_poll:
+	blk_stat_free_callback(q->poll_cb);
+	q->poll_cb = NULL;
 err_exit:
 	q->mq_ops = NULL;
 	return ERR_PTR(-ENOMEM);
-- 
2.20.1

Re: [PATCH AUTOSEL 5.1 35/70] loop: Don't change loop device under exclusive opener

[Jan Kara]

On Sat 08-06-19 07:39:14, Sasha Levin wrote:
> From: Jan Kara <jack@suse.cz>
> 
> [ Upstream commit 33ec3e53e7b1869d7851e59e126bdb0fe0bd1982 ]

Please don't push this to stable kernels because...

> [Deliberately chosen not to CC stable as a user with priviledges to
> trigger this race has other means of taking the system down and this
> has a potential of breaking some weird userspace setup]

... of this. Thanks!

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

Re: [PATCH AUTOSEL 5.1 35/70] loop: Don't change loop device under exclusive opener

[Sasha Levin]

On Mon, Jun 10, 2019 at 11:00:13AM +0200, Jan Kara wrote:
>On Sat 08-06-19 07:39:14, Sasha Levin wrote:
>> From: Jan Kara <jack@suse.cz>
>>
>> [ Upstream commit 33ec3e53e7b1869d7851e59e126bdb0fe0bd1982 ]
>
>Please don't push this to stable kernels because...

I've dropped this, but...

>> [Deliberately chosen not to CC stable as a user with priviledges to
>> trigger this race has other means of taking the system down and this
>> has a potential of breaking some weird userspace setup]
>
>... of this. Thanks!

Can't this be triggered by an "innocent" user, rather as part of an
attack? Why can't this race happen during regular usage?

--
Thanks,
Sasha

Re: [PATCH AUTOSEL 5.1 35/70] loop: Don't change loop device under exclusive opener

[Jan Kara]

On Wed 19-06-19 16:11:36, Sasha Levin wrote:
> On Mon, Jun 10, 2019 at 11:00:13AM +0200, Jan Kara wrote:
> > On Sat 08-06-19 07:39:14, Sasha Levin wrote:
> > > From: Jan Kara <jack@suse.cz>
> > > 
> > > [ Upstream commit 33ec3e53e7b1869d7851e59e126bdb0fe0bd1982 ]
> > 
> > Please don't push this to stable kernels because...
> 
> I've dropped this, but...

OK, thanks.

> > > [Deliberately chosen not to CC stable as a user with priviledges to
> > > trigger this race has other means of taking the system down and this
> > > has a potential of breaking some weird userspace setup]
> > 
> > ... of this. Thanks!
> 
> Can't this be triggered by an "innocent" user, rather as part of an
> attack? Why can't this race happen during regular usage?

Well, the problem happens when mount happens on loop device when someone
modifies the backing file of the loop device. So for this to be
triggerable, you have to have control over assignment of backing files to
loop devices (you have to be owner of these loop devices to be able to do
this - pretty much means root in most setups) and be able to trigger mount
on this device. If you have these capabilities, there are much more
efficient ways to gain full administrator priviledges on the system,
deadlocking the kernel is thus the least of your worries.

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