linux-stable.git/drivers/block/loop.c, branch linux-5.4.y Linux kernel stable tree loop: loop_set_status_from_info() check before assignment 2024-04-13T10:51:30+00:00 Zhong Jinghua zhongjinghua@huawei.com 2024-03-07T04:14:11+00:00 861021710bba9dfa0749a3c209a6c1773208b1f1 [ Upstream commit 9f6ad5d533d1c71e51bdd06a5712c4fbc8768dfa ] In loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit should be checked before reassignment, because if an overflow error occurs, the original correct value will be changed to the wrong value, and it will not be changed back. More, the original patch did not solve the problem, the value was set and ioctl returned an error, but the subsequent io used the value in the loop driver, which still caused an alarm: loop_handle_cmd do_req_filebacked loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset; lo_rw_aio cmd->iocb.ki_pos = pos Fixes: c490a0b5a4f3 ("loop: Check for overflow while configuring loop") Signed-off-by: Zhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20230221095027.3656193-1-zhongjinghua@huaweicloud.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 9f6ad5d533d1c71e51bdd06a5712c4fbc8768dfa ]

In loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit should
be checked before reassignment, because if an overflow error occurs, the
original correct value will be changed to the wrong value, and it will not
be changed back.

More, the original patch did not solve the problem, the value was set and
ioctl returned an error, but the subsequent io used the value in the loop
driver, which still caused an alarm:

loop_handle_cmd
 do_req_filebacked
  loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset;
  lo_rw_aio
   cmd->iocb.ki_pos = pos

Fixes: c490a0b5a4f3 ("loop: Check for overflow while configuring loop")
Signed-off-by: Zhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Link: https://lore.kernel.org/r/20230221095027.3656193-1-zhongjinghua@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
loop: Check for overflow while configuring loop 2024-04-13T10:51:30+00:00 Siddh Raman Pant code@siddh.me 2024-03-07T04:14:10+00:00 b40877b8562c5720d0a7fce20729f56b75a3dede [ Upstream commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 ] The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset. loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h). The function directly copies offset from info to the device as follows (See line 980 of loop.c): lo->lo_offset = info->lo_offset; This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Thus, check for negative value during loop_set_status_from_info(). Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e Reported-and-tested-by: syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Siddh Raman Pant <code@siddh.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220823160810.181275-1-code@siddh.me Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 ]

The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &config->info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.

loop_device has lo_offset of type loff_t (see line 52 of loop.c),
which is typdef-chained to long long, whereas loop_info64 has
lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).

The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
	lo->lo_offset = info->lo_offset;

This results in an overflow, which triggers a warning in iomap_iter()
due to a call to iomap_iter_done() which has:
	WARN_ON_ONCE(iter->iomap.offset > iter->pos);

Thus, check for negative value during loop_set_status_from_info().

Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e

Reported-and-tested-by: syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Siddh Raman Pant <code@siddh.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20220823160810.181275-1-code@siddh.me
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
loop: Factor out configuring loop from status 2024-04-13T10:51:30+00:00 Martijn Coenen maco@android.com 2024-03-07T04:14:09+00:00 f4476da8eabd91df9da42896b6ba1026109b4cb1 [ Upstream commit 0c3796c244598122a5d59d56f30d19390096817f ] Factor out this code into a separate function, so it can be reused by other code more easily. Signed-off-by: Martijn Coenen <maco@android.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 0c3796c244598122a5d59d56f30d19390096817f ]

Factor out this code into a separate function, so it can be reused by
other code more easily.

Signed-off-by: Martijn Coenen <maco@android.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
loop: Refactor loop_set_status() size calculation 2024-04-13T10:51:30+00:00 Martijn Coenen maco@android.com 2024-03-07T04:14:08+00:00 7423a124fa625bdc960edc08ff0ec00721cf41b1 [ Upstream commit b0bd158dd630bd47640e0e418c062cda1e0da5ad ] figure_loop_size() calculates the loop size based on the passed in parameters, but at the same time it updates the offset and sizelimit parameters in the loop device configuration. That is a somewhat unexpected side effect of a function with this name, and it is only only needed by one of the two callers of this function - loop_set_status(). Move the lo_offset and lo_sizelimit assignment back into loop_set_status(), and use the newly factored out functions to validate and apply the newly calculated size. This allows us to get rid of figure_loop_size() in a follow-up commit. Signed-off-by: Martijn Coenen <maco@android.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit b0bd158dd630bd47640e0e418c062cda1e0da5ad ]

figure_loop_size() calculates the loop size based on the passed in
parameters, but at the same time it updates the offset and sizelimit
parameters in the loop device configuration. That is a somewhat
unexpected side effect of a function with this name, and it is only only
needed by one of the two callers of this function - loop_set_status().

Move the lo_offset and lo_sizelimit assignment back into loop_set_status(),
and use the newly factored out functions to validate and apply the newly
calculated size. This allows us to get rid of figure_loop_size() in a
follow-up commit.

Signed-off-by: Martijn Coenen <maco@android.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
loop: Factor out setting loop device size 2024-04-13T10:51:30+00:00 Martijn Coenen maco@android.com 2024-03-07T04:14:07+00:00 3c9e7e8cb69c27478c931d9fff7b80c32cc4f68a [ Upstream commit 5795b6f5607f7e4db62ddea144727780cb351a9b ] This code is used repeatedly. Signed-off-by: Martijn Coenen <maco@android.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 5795b6f5607f7e4db62ddea144727780cb351a9b ]

This code is used repeatedly.

Signed-off-by: Martijn Coenen <maco@android.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
loop: Remove sector_t truncation checks 2024-04-13T10:51:30+00:00 Martijn Coenen maco@android.com 2024-03-07T04:14:06+00:00 e08b2e4176f77af901d0b6d964441023099dd416 [ Upstream commit 083a6a50783ef54256eec3499e6575237e0e3d53 ] sector_t is now always u64, so we don't need to check for truncation. Signed-off-by: Martijn Coenen <maco@android.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 083a6a50783ef54256eec3499e6575237e0e3d53 ]

sector_t is now always u64, so we don't need to check for truncation.

Signed-off-by: Martijn Coenen <maco@android.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
loop: Call loop_config_discard() only after new config is applied 2024-04-13T10:51:30+00:00 Martijn Coenen maco@android.com 2024-03-07T04:14:05+00:00 ea3bec644a031f18791c154e7be4f2a528035216 [ Upstream commit 7c5014b0987a30e4989c90633c198aced454c0ec ] loop_set_status() calls loop_config_discard() to configure discard for the loop device; however, the discard configuration depends on whether the loop device uses encryption, and when we call it the encryption configuration has not been updated yet. Move the call down so we apply the correct discard configuration based on the new configuration. Signed-off-by: Martijn Coenen <maco@android.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bob Liu <bob.liu@oracle.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 7c5014b0987a30e4989c90633c198aced454c0ec ]

loop_set_status() calls loop_config_discard() to configure discard for
the loop device; however, the discard configuration depends on whether
the loop device uses encryption, and when we call it the encryption
configuration has not been updated yet. Move the call down so we apply
the correct discard configuration based on the new configuration.

Signed-off-by: Martijn Coenen <maco@android.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bob Liu <bob.liu@oracle.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "loop: Check for overflow while configuring loop" 2024-04-13T10:51:30+00:00 Genjian Zhang zhanggenjian@kylinos.cn 2024-03-07T04:14:04+00:00 2ea7077748e5d7cc64f1c31342c802fe66ea7426 This reverts commit 13b2856037a651ba3ab4a8b25ecab3e791926da3. This patch lost a unlock loop_ctl_mutex in loop_get_status(...), which caused syzbot to report a UAF issue.The upstream patch does not have this issue. Therefore, we revert this patch and directly apply the upstream patch later on. Risk use-after-free as reported by syzbot： [ 84.669496] ================================================================== [ 84.670021] BUG: KASAN: use-after-free in __mutex_lock.isra.9+0xc13/0xcb0 [ 84.670433] Read of size 4 at addr ffff88808dba43b8 by task syz-executor.22/14230 [ 84.670885] [ 84.670987] CPU: 1 PID: 14230 Comm: syz-executor.22 Not tainted 5.4.270 #4 [ 84.671397] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 84.671927] Call Trace: [ 84.672085] dump_stack+0x94/0xc7 [ 84.672293] ? __mutex_lock.isra.9+0xc13/0xcb0 [ 84.672569] print_address_description.constprop.6+0x16/0x220 [ 84.672915] ? __mutex_lock.isra.9+0xc13/0xcb0 [ 84.673187] ? __mutex_lock.isra.9+0xc13/0xcb0 [ 84.673462] __kasan_report.cold.9+0x1a/0x32 [ 84.673723] ? __mutex_lock.isra.9+0xc13/0xcb0 [ 84.673993] kasan_report+0x10/0x20 [ 84.674208] __mutex_lock.isra.9+0xc13/0xcb0 [ 84.674468] ? __mutex_lock.isra.9+0x617/0xcb0 [ 84.674739] ? ww_mutex_lock_interruptible+0x100/0x100 [ 84.675055] ? ww_mutex_lock_interruptible+0x100/0x100 [ 84.675369] ? kobject_get_unless_zero+0x144/0x190 [ 84.675668] ? kobject_del+0x60/0x60 [ 84.675893] ? __module_get+0x120/0x120 [ 84.676128] ? __mutex_lock_slowpath+0x10/0x10 [ 84.676399] mutex_lock_killable+0xde/0xf0 [ 84.676652] ? __mutex_lock_killable_slowpath+0x10/0x10 [ 84.676967] ? __mutex_lock_slowpath+0x10/0x10 [ 84.677243] ? disk_block_events+0x1d/0x120 [ 84.677509] lo_open+0x16/0xc0 [ 84.677701] ? lo_compat_ioctl+0x160/0x160 [ 84.677954] __blkdev_get+0xb0f/0x1160 [ 84.678185] ? bd_may_claim+0xd0/0xd0 [ 84.678410] ? bdev_disk_changed+0x190/0x190 [ 84.678674] ? _raw_spin_lock+0x7c/0xd0 [ 84.678915] ? _raw_write_lock_bh+0xd0/0xd0 [ 84.679172] blkdev_get+0x9b/0x290 [ 84.679381] ? ihold+0x1a/0x40 [ 84.679574] blkdev_open+0x1bd/0x240 [ 84.679794] do_dentry_open+0x439/0x1000 [ 84.680035] ? blkdev_get_by_dev+0x60/0x60 [ 84.680286] ? __x64_sys_fchdir+0x1a0/0x1a0 [ 84.680557] ? inode_permission+0x86/0x320 [ 84.680814] path_openat+0x998/0x4120 [ 84.681044] ? stack_trace_consume_entry+0x160/0x160 [ 84.681348] ? do_futex+0x136/0x1880 [ 84.681568] ? path_mountpoint+0xb50/0xb50 [ 84.681823] ? save_stack+0x4d/0x80 [ 84.682038] ? save_stack+0x19/0x80 [ 84.682253] ? __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 84.682553] ? kmem_cache_alloc+0xc7/0x210 [ 84.682804] ? getname_flags+0xc4/0x560 [ 84.683045] ? do_sys_open+0x1ce/0x450 [ 84.683272] ? do_syscall_64+0x9a/0x330 [ 84.683509] ? entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 84.683826] ? _raw_spin_lock+0x7c/0xd0 [ 84.684063] ? _raw_write_lock_bh+0xd0/0xd0 [ 84.684319] ? futex_exit_release+0x60/0x60 [ 84.684574] ? kasan_unpoison_shadow+0x30/0x40 [ 84.684844] ? __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 84.685149] ? get_partial_node.isra.83.part.84+0x1e5/0x340 [ 84.685485] ? __fget_light+0x1d1/0x550 [ 84.685721] do_filp_open+0x197/0x270 [ 84.685946] ? may_open_dev+0xd0/0xd0 [ 84.686172] ? kasan_unpoison_shadow+0x30/0x40 [ 84.686443] ? __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 84.686743] ? __alloc_fd+0x1a3/0x580 [ 84.686973] do_sys_open+0x2c7/0x450 [ 84.687195] ? filp_open+0x60/0x60 [ 84.687406] ? __x64_sys_timer_settime32+0x280/0x280 [ 84.687707] do_syscall_64+0x9a/0x330 [ 84.687931] ? syscall_return_slowpath+0x17a/0x230 [ 84.688221] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 84.688524] [ 84.688622] Allocated by task 14056: [ 84.688842] save_stack+0x19/0x80 [ 84.689044] __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 84.689333] kmem_cache_alloc_node+0xe2/0x230 [ 84.689600] copy_process+0x165c/0x72d0 [ 84.689833] _do_fork+0xf9/0x9a0 [ 84.690032] __x64_sys_clone+0x17a/0x200 [ 84.690271] do_syscall_64+0x9a/0x330 [ 84.690496] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 84.690800] [ 84.690903] Freed by task 0: [ 84.691081] save_stack+0x19/0x80 [ 84.691287] __kasan_slab_free+0x125/0x170 [ 84.691535] kmem_cache_free+0x7a/0x2a0 [ 84.691774] __put_task_struct+0x1ec/0x4a0 [ 84.692023] delayed_put_task_struct+0x178/0x1d0 [ 84.692303] rcu_core+0x538/0x16c0 [ 84.692512] __do_softirq+0x175/0x63d [ 84.692741] [ 84.692840] The buggy address belongs to the object at ffff88808dba4380 [ 84.692840] which belongs to the cache task_struct of size 3328 [ 84.693584] The buggy address is located 56 bytes inside of [ 84.693584] 3328-byte region [ffff88808dba4380, ffff88808dba5080) [ 84.694272] The buggy address belongs to the page: [ 84.694563] page:ffffea000236e800 refcount:1 mapcount:0 mapping:ffff8881838acdc0 index:0x0 compound_mapcount: 0 [ 84.695166] flags: 0x100000000010200(slab|head) [ 84.695457] raw: 0100000000010200 dead000000000100 dead000000000122 ffff8881838acdc0 [ 84.695919] raw: 0000000000000000 0000000000090009 00000001ffffffff 0000000000000000 [ 84.696375] page dumped because: kasan: bad access detected [ 84.696705] [ 84.696801] Memory state around the buggy address: [ 84.697089] ffff88808dba4280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 84.697519] ffff88808dba4300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 84.697945] >ffff88808dba4380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 84.698371] ^ [ 84.698674] ffff88808dba4400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 84.699111] ffff88808dba4480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 84.699537] ================================================================== [ 84.699965] Disabling lock debugging due to kernel taint Reported-by: k2ci <kernel-bot@kylinos.cn> Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This reverts commit 13b2856037a651ba3ab4a8b25ecab3e791926da3.

This patch lost a unlock loop_ctl_mutex in loop_get_status(...),
which caused syzbot to report a UAF issue.The upstream patch does not
have this issue. Therefore, we revert this patch and directly apply
the upstream patch later on.

Risk use-after-free as reported by syzbot：

[   84.669496] ==================================================================
[   84.670021] BUG: KASAN: use-after-free in __mutex_lock.isra.9+0xc13/0xcb0
[   84.670433] Read of size 4 at addr ffff88808dba43b8 by task syz-executor.22/14230
[   84.670885]
[   84.670987] CPU: 1 PID: 14230 Comm: syz-executor.22 Not tainted 5.4.270 #4
[   84.671397] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014
[   84.671927] Call Trace:
[   84.672085]  dump_stack+0x94/0xc7
[   84.672293]  ? __mutex_lock.isra.9+0xc13/0xcb0
[   84.672569]  print_address_description.constprop.6+0x16/0x220
[   84.672915]  ? __mutex_lock.isra.9+0xc13/0xcb0
[   84.673187]  ? __mutex_lock.isra.9+0xc13/0xcb0
[   84.673462]  __kasan_report.cold.9+0x1a/0x32
[   84.673723]  ? __mutex_lock.isra.9+0xc13/0xcb0
[   84.673993]  kasan_report+0x10/0x20
[   84.674208]  __mutex_lock.isra.9+0xc13/0xcb0
[   84.674468]  ? __mutex_lock.isra.9+0x617/0xcb0
[   84.674739]  ? ww_mutex_lock_interruptible+0x100/0x100
[   84.675055]  ? ww_mutex_lock_interruptible+0x100/0x100
[   84.675369]  ? kobject_get_unless_zero+0x144/0x190
[   84.675668]  ? kobject_del+0x60/0x60
[   84.675893]  ? __module_get+0x120/0x120
[   84.676128]  ? __mutex_lock_slowpath+0x10/0x10
[   84.676399]  mutex_lock_killable+0xde/0xf0
[   84.676652]  ? __mutex_lock_killable_slowpath+0x10/0x10
[   84.676967]  ? __mutex_lock_slowpath+0x10/0x10
[   84.677243]  ? disk_block_events+0x1d/0x120
[   84.677509]  lo_open+0x16/0xc0
[   84.677701]  ? lo_compat_ioctl+0x160/0x160
[   84.677954]  __blkdev_get+0xb0f/0x1160
[   84.678185]  ? bd_may_claim+0xd0/0xd0
[   84.678410]  ? bdev_disk_changed+0x190/0x190
[   84.678674]  ? _raw_spin_lock+0x7c/0xd0
[   84.678915]  ? _raw_write_lock_bh+0xd0/0xd0
[   84.679172]  blkdev_get+0x9b/0x290
[   84.679381]  ? ihold+0x1a/0x40
[   84.679574]  blkdev_open+0x1bd/0x240
[   84.679794]  do_dentry_open+0x439/0x1000
[   84.680035]  ? blkdev_get_by_dev+0x60/0x60
[   84.680286]  ? __x64_sys_fchdir+0x1a0/0x1a0
[   84.680557]  ? inode_permission+0x86/0x320
[   84.680814]  path_openat+0x998/0x4120
[   84.681044]  ? stack_trace_consume_entry+0x160/0x160
[   84.681348]  ? do_futex+0x136/0x1880
[   84.681568]  ? path_mountpoint+0xb50/0xb50
[   84.681823]  ? save_stack+0x4d/0x80
[   84.682038]  ? save_stack+0x19/0x80
[   84.682253]  ? __kasan_kmalloc.constprop.6+0xc1/0xd0
[   84.682553]  ? kmem_cache_alloc+0xc7/0x210
[   84.682804]  ? getname_flags+0xc4/0x560
[   84.683045]  ? do_sys_open+0x1ce/0x450
[   84.683272]  ? do_syscall_64+0x9a/0x330
[   84.683509]  ? entry_SYSCALL_64_after_hwframe+0x5c/0xc1
[   84.683826]  ? _raw_spin_lock+0x7c/0xd0
[   84.684063]  ? _raw_write_lock_bh+0xd0/0xd0
[   84.684319]  ? futex_exit_release+0x60/0x60
[   84.684574]  ? kasan_unpoison_shadow+0x30/0x40
[   84.684844]  ? __kasan_kmalloc.constprop.6+0xc1/0xd0
[   84.685149]  ? get_partial_node.isra.83.part.84+0x1e5/0x340
[   84.685485]  ? __fget_light+0x1d1/0x550
[   84.685721]  do_filp_open+0x197/0x270
[   84.685946]  ? may_open_dev+0xd0/0xd0
[   84.686172]  ? kasan_unpoison_shadow+0x30/0x40
[   84.686443]  ? __kasan_kmalloc.constprop.6+0xc1/0xd0
[   84.686743]  ? __alloc_fd+0x1a3/0x580
[   84.686973]  do_sys_open+0x2c7/0x450
[   84.687195]  ? filp_open+0x60/0x60
[   84.687406]  ? __x64_sys_timer_settime32+0x280/0x280
[   84.687707]  do_syscall_64+0x9a/0x330
[   84.687931]  ? syscall_return_slowpath+0x17a/0x230
[   84.688221]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1
[   84.688524]
[   84.688622] Allocated by task 14056:
[   84.688842]  save_stack+0x19/0x80
[   84.689044]  __kasan_kmalloc.constprop.6+0xc1/0xd0
[   84.689333]  kmem_cache_alloc_node+0xe2/0x230
[   84.689600]  copy_process+0x165c/0x72d0
[   84.689833]  _do_fork+0xf9/0x9a0
[   84.690032]  __x64_sys_clone+0x17a/0x200
[   84.690271]  do_syscall_64+0x9a/0x330
[   84.690496]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1
[   84.690800]
[   84.690903] Freed by task 0:
[   84.691081]  save_stack+0x19/0x80
[   84.691287]  __kasan_slab_free+0x125/0x170
[   84.691535]  kmem_cache_free+0x7a/0x2a0
[   84.691774]  __put_task_struct+0x1ec/0x4a0
[   84.692023]  delayed_put_task_struct+0x178/0x1d0
[   84.692303]  rcu_core+0x538/0x16c0
[   84.692512]  __do_softirq+0x175/0x63d
[   84.692741]
[   84.692840] The buggy address belongs to the object at ffff88808dba4380
[   84.692840]  which belongs to the cache task_struct of size 3328
[   84.693584] The buggy address is located 56 bytes inside of
[   84.693584]  3328-byte region [ffff88808dba4380, ffff88808dba5080)
[   84.694272] The buggy address belongs to the page:
[   84.694563] page:ffffea000236e800 refcount:1 mapcount:0 mapping:ffff8881838acdc0 index:0x0 compound_mapcount: 0
[   84.695166] flags: 0x100000000010200(slab|head)
[   84.695457] raw: 0100000000010200 dead000000000100 dead000000000122 ffff8881838acdc0
[   84.695919] raw: 0000000000000000 0000000000090009 00000001ffffffff 0000000000000000
[   84.696375] page dumped because: kasan: bad access detected
[   84.696705]
[   84.696801] Memory state around the buggy address:
[   84.697089]  ffff88808dba4280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   84.697519]  ffff88808dba4300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   84.697945] >ffff88808dba4380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   84.698371]                                         ^
[   84.698674]  ffff88808dba4400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   84.699111]  ffff88808dba4480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   84.699537] ==================================================================
[   84.699965] Disabling lock debugging due to kernel taint

Reported-by: k2ci <kernel-bot@kylinos.cn>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
loop: Select I/O scheduler 'none' from inside add_disk() 2023-08-11T09:53:54+00:00 Bart Van Assche bvanassche@acm.org 2021-08-05T17:42:00+00:00 be4d2b4562066f2007789f642bee74b46f726dc4 commit 2112f5c1330a671fa852051d85cb9eadc05d7eb7 upstream. We noticed that the user interface of Android devices becomes very slow under memory pressure. This is because Android uses the zram driver on top of the loop driver for swapping, because under memory pressure the swap code alternates reads and writes quickly, because mq-deadline is the default scheduler for loop devices and because mq-deadline delays writes by five seconds for such a workload with default settings. Fix this by making the kernel select I/O scheduler 'none' from inside add_disk() for loop devices. This default can be overridden at any time from user space, e.g. via a udev rule. This approach has an advantage compared to changing the I/O scheduler from userspace from 'mq-deadline' into 'none', namely that synchronize_rcu() does not get called. This patch changes the default I/O scheduler for loop devices from 'mq-deadline' into 'none'. Additionally, this patch reduces the Android boot time on my test setup with 0.5 seconds compared to configuring the loop I/O scheduler from user space. Cc: Christoph Hellwig <hch@lst.de> Cc: Ming Lei <ming.lei@redhat.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Martijn Coenen <maco@android.com> Cc: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20210805174200.3250718-3-bvanassche@acm.org Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2112f5c1330a671fa852051d85cb9eadc05d7eb7 upstream.

We noticed that the user interface of Android devices becomes very slow
under memory pressure. This is because Android uses the zram driver on top
of the loop driver for swapping, because under memory pressure the swap
code alternates reads and writes quickly, because mq-deadline is the
default scheduler for loop devices and because mq-deadline delays writes by
five seconds for such a workload with default settings. Fix this by making
the kernel select I/O scheduler 'none' from inside add_disk() for loop
devices. This default can be overridden at any time from user space,
e.g. via a udev rule. This approach has an advantage compared to changing
the I/O scheduler from userspace from 'mq-deadline' into 'none', namely
that synchronize_rcu() does not get called.

This patch changes the default I/O scheduler for loop devices from
'mq-deadline' into 'none'.

Additionally, this patch reduces the Android boot time on my test setup
with 0.5 seconds compared to configuring the loop I/O scheduler from user
space.

Cc: Christoph Hellwig <hch@lst.de>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Martijn Coenen <maco@android.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20210805174200.3250718-3-bvanassche@acm.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
loop: Check for overflow while configuring loop 2022-09-05T08:27:43+00:00 Siddh Raman Pant code@siddh.me 2022-08-23T16:08:10+00:00 13b2856037a651ba3ab4a8b25ecab3e791926da3 commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 upstream. The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset. loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h). The function directly copies offset from info to the device as follows (See line 980 of loop.c): lo->lo_offset = info->lo_offset; This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Thus, check for negative value during loop_set_status_from_info(). Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e Reported-and-tested-by: syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Siddh Raman Pant <code@siddh.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220823160810.181275-1-code@siddh.me Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 upstream.

The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &config->info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.

loop_device has lo_offset of type loff_t (see line 52 of loop.c),
which is typdef-chained to long long, whereas loop_info64 has
lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).

The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
	lo->lo_offset = info->lo_offset;

This results in an overflow, which triggers a warning in iomap_iter()
due to a call to iomap_iter_done() which has:
	WARN_ON_ONCE(iter->iomap.offset > iter->pos);

Thus, check for negative value during loop_set_status_from_info().

Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e

Reported-and-tested-by: syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Siddh Raman Pant <code@siddh.me>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20220823160810.181275-1-code@siddh.me
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>