Re: KASAN: use-after-free Read in disk_part_iter_next
From: Ming Lei <hidden>
Date: 2020-12-13 11:41:48
Also in:
lkml
Subsystem:
block layer, the rest · Maintainers:
Jens Axboe, Linus Torvalds
On Fri, Dec 11, 2020 at 01:03:11PM -0800, syzbot wrote:
Hello, syzbot found the following issue on: HEAD commit: 15ac8fdb Add linux-next specific files for 20201207 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=15d8ad37500000 kernel config: https://syzkaller.appspot.com/x/.config?x=3696b8138207d24d dashboard link: https://syzkaller.appspot.com/bug?extid=825f0f9657d4e528046e compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1393dcbd500000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1074cf17500000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+825f0f9657d4e528046e@syzkaller.appspotmail.com ================================================================== BUG: KASAN: use-after-free in bdev_nr_sectors include/linux/genhd.h:264 [inline] BUG: KASAN: use-after-free in disk_part_iter_next+0x4c7/0x560 block/genhd.c:204 Read of size 8 at addr ffff88814080b9a8 by task syz-executor825/9848 CPU: 1 PID: 9848 Comm: syz-executor825 Not tainted 5.10.0-rc6-next-20201207-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230 __kasan_report mm/kasan/report.c:396 [inline] kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413 bdev_nr_sectors include/linux/genhd.h:264 [inline] disk_part_iter_next+0x4c7/0x560 block/genhd.c:204 partition_overlaps+0x96/0x200 block/partitions/core.c:425 bdev_add_partition+0x66/0x130 block/partitions/core.c:444 blkpg_do_ioctl+0x2d0/0x340 block/ioctl.c:43 blkpg_ioctl block/ioctl.c:60 [inline] blkdev_ioctl+0x577/0x6d0 block/ioctl.c:541 block_ioctl+0xf9/0x140 fs/block_dev.c:1649 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9
It should be fixed by the following patch, can you run the test with this patch?
diff --git a/block/genhd.c b/block/genhd.c
index b84b8671e627..98d785e248dd 100644
--- a/block/genhd.c
+++ b/block/genhd.c@@ -244,8 +244,7 @@ struct block_device *disk_part_iter_next(struct disk_part_iter *piter) part = rcu_dereference(ptbl->part[piter->idx]); if (!part) continue; - if (!bdev_nr_sectors(part) && - !(piter->flags & DISK_PITER_INCL_EMPTY) && + if (!(piter->flags & DISK_PITER_INCL_EMPTY) && !(piter->flags & DISK_PITER_INCL_EMPTY_PART0 && piter->idx == 0)) continue;
@@ -253,6 +252,12 @@ struct block_device *disk_part_iter_next(struct disk_part_iter *piter) piter->part = bdgrab(part); if (!piter->part) continue; + if (!bdev_nr_sectors(part)) { + bdput(piter->part); + piter->part = NULL; + continue; + } + piter->idx += inc; break; }
--
Ming