From: Greg Kroah-Hartman Date: Sat, 28 Nov 2020 12:39:32 +0000 (+0100) Subject: 4.19-stable patches X-Git-Tag: v4.4.247~38 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1ba64e390925ab36d9f80c5cd2e598e87e833167;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: btrfs-don-t-access-possibly-stale-fs_info-data-for-printing-duplicate-device.patch btrfs-fix-lockdep-splat-when-reading-qgroup-config-on-mount.patch --- diff --git a/queue-4.19/btrfs-don-t-access-possibly-stale-fs_info-data-for-printing-duplicate-device.patch b/queue-4.19/btrfs-don-t-access-possibly-stale-fs_info-data-for-printing-duplicate-device.patch new file mode 100644 index 00000000000..57e508bb258 --- /dev/null +++ b/queue-4.19/btrfs-don-t-access-possibly-stale-fs_info-data-for-printing-duplicate-device.patch @@ -0,0 +1,171 @@ +From 0697d9a610998b8bdee6b2390836cb2391d8fd1a Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Wed, 18 Nov 2020 18:03:26 +0900 +Subject: btrfs: don't access possibly stale fs_info data for printing duplicate device + +From: Johannes Thumshirn + +commit 0697d9a610998b8bdee6b2390836cb2391d8fd1a upstream. + +Syzbot reported a possible use-after-free when printing a duplicate device +warning device_list_add(). + +At this point it can happen that a btrfs_device::fs_info is not correctly +setup yet, so we're accessing stale data, when printing the warning +message using the btrfs_printk() wrappers. + + ================================================================== + BUG: KASAN: use-after-free in btrfs_printk+0x3eb/0x435 fs/btrfs/super.c:245 + Read of size 8 at addr ffff8880878e06a8 by task syz-executor225/7068 + + CPU: 1 PID: 7068 Comm: syz-executor225 Not tainted 5.9.0-rc5-syzkaller #0 + Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 + Call Trace: + __dump_stack lib/dump_stack.c:77 [inline] + dump_stack+0x1d6/0x29e lib/dump_stack.c:118 + print_address_description+0x66/0x620 mm/kasan/report.c:383 + __kasan_report mm/kasan/report.c:513 [inline] + kasan_report+0x132/0x1d0 mm/kasan/report.c:530 + btrfs_printk+0x3eb/0x435 fs/btrfs/super.c:245 + device_list_add+0x1a88/0x1d60 fs/btrfs/volumes.c:943 + btrfs_scan_one_device+0x196/0x490 fs/btrfs/volumes.c:1359 + btrfs_mount_root+0x48f/0xb60 fs/btrfs/super.c:1634 + legacy_get_tree+0xea/0x180 fs/fs_context.c:592 + vfs_get_tree+0x88/0x270 fs/super.c:1547 + fc_mount fs/namespace.c:978 [inline] + vfs_kern_mount+0xc9/0x160 fs/namespace.c:1008 + btrfs_mount+0x33c/0xae0 fs/btrfs/super.c:1732 + legacy_get_tree+0xea/0x180 fs/fs_context.c:592 + vfs_get_tree+0x88/0x270 fs/super.c:1547 + do_new_mount fs/namespace.c:2875 [inline] + path_mount+0x179d/0x29e0 fs/namespace.c:3192 + do_mount fs/namespace.c:3205 [inline] + __do_sys_mount fs/namespace.c:3413 [inline] + __se_sys_mount+0x126/0x180 fs/namespace.c:3390 + do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + RIP: 0033:0x44840a + RSP: 002b:00007ffedfffd608 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5 + RAX: ffffffffffffffda RBX: 00007ffedfffd670 RCX: 000000000044840a + RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffedfffd630 + RBP: 00007ffedfffd630 R08: 00007ffedfffd670 R09: 0000000000000000 + R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000001a + R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003 + + Allocated by task 6945: + kasan_save_stack mm/kasan/common.c:48 [inline] + kasan_set_track mm/kasan/common.c:56 [inline] + __kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461 + kmalloc_node include/linux/slab.h:577 [inline] + kvmalloc_node+0x81/0x110 mm/util.c:574 + kvmalloc include/linux/mm.h:757 [inline] + kvzalloc include/linux/mm.h:765 [inline] + btrfs_mount_root+0xd0/0xb60 fs/btrfs/super.c:1613 + legacy_get_tree+0xea/0x180 fs/fs_context.c:592 + vfs_get_tree+0x88/0x270 fs/super.c:1547 + fc_mount fs/namespace.c:978 [inline] + vfs_kern_mount+0xc9/0x160 fs/namespace.c:1008 + btrfs_mount+0x33c/0xae0 fs/btrfs/super.c:1732 + legacy_get_tree+0xea/0x180 fs/fs_context.c:592 + vfs_get_tree+0x88/0x270 fs/super.c:1547 + do_new_mount fs/namespace.c:2875 [inline] + path_mount+0x179d/0x29e0 fs/namespace.c:3192 + do_mount fs/namespace.c:3205 [inline] + __do_sys_mount fs/namespace.c:3413 [inline] + __se_sys_mount+0x126/0x180 fs/namespace.c:3390 + do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + Freed by task 6945: + kasan_save_stack mm/kasan/common.c:48 [inline] + kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 + kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 + __kasan_slab_free+0xdd/0x110 mm/kasan/common.c:422 + __cache_free mm/slab.c:3418 [inline] + kfree+0x113/0x200 mm/slab.c:3756 + deactivate_locked_super+0xa7/0xf0 fs/super.c:335 + btrfs_mount_root+0x72b/0xb60 fs/btrfs/super.c:1678 + legacy_get_tree+0xea/0x180 fs/fs_context.c:592 + vfs_get_tree+0x88/0x270 fs/super.c:1547 + fc_mount fs/namespace.c:978 [inline] + vfs_kern_mount+0xc9/0x160 fs/namespace.c:1008 + btrfs_mount+0x33c/0xae0 fs/btrfs/super.c:1732 + legacy_get_tree+0xea/0x180 fs/fs_context.c:592 + vfs_get_tree+0x88/0x270 fs/super.c:1547 + do_new_mount fs/namespace.c:2875 [inline] + path_mount+0x179d/0x29e0 fs/namespace.c:3192 + do_mount fs/namespace.c:3205 [inline] + __do_sys_mount fs/namespace.c:3413 [inline] + __se_sys_mount+0x126/0x180 fs/namespace.c:3390 + do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + + The buggy address belongs to the object at ffff8880878e0000 + which belongs to the cache kmalloc-16k of size 16384 + The buggy address is located 1704 bytes inside of + 16384-byte region [ffff8880878e0000, ffff8880878e4000) + The buggy address belongs to the page: + page:0000000060704f30 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x878e0 + head:0000000060704f30 order:3 compound_mapcount:0 compound_pincount:0 + flags: 0xfffe0000010200(slab|head) + raw: 00fffe0000010200 ffffea00028e9a08 ffffea00021e3608 ffff8880aa440b00 + raw: 0000000000000000 ffff8880878e0000 0000000100000001 0000000000000000 + page dumped because: kasan: bad access detected + + Memory state around the buggy address: + ffff8880878e0580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff8880878e0600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + >ffff8880878e0680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ^ + ffff8880878e0700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff8880878e0780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ================================================================== + +The syzkaller reproducer for this use-after-free crafts a filesystem image +and loop mounts it twice in a loop. The mount will fail as the crafted +image has an invalid chunk tree. When this happens btrfs_mount_root() will +call deactivate_locked_super(), which then cleans up fs_info and +fs_info::sb. If a second thread now adds the same block-device to the +filesystem, it will get detected as a duplicate device and +device_list_add() will reject the duplicate and print a warning. But as +the fs_info pointer passed in is non-NULL this will result in a +use-after-free. + +Instead of printing possibly uninitialized or already freed memory in +btrfs_printk(), explicitly pass in a NULL fs_info so the printing of the +device name will be skipped altogether. + +There was a slightly different approach discussed in +https://lore.kernel.org/linux-btrfs/20200114060920.4527-1-anand.jain@oracle.com/t/#u + +Link: https://lore.kernel.org/linux-btrfs/000000000000c9e14b05afcc41ba@google.com +Reported-by: syzbot+582e66e5edf36a22c7b0@syzkaller.appspotmail.com +CC: stable@vger.kernel.org # 4.19+ +Reviewed-by: Nikolay Borisov +Reviewed-by: Anand Jain +Signed-off-by: Johannes Thumshirn +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/volumes.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -857,7 +857,13 @@ static noinline struct btrfs_device *dev + if (device->bdev != path_bdev) { + bdput(path_bdev); + mutex_unlock(&fs_devices->device_list_mutex); +- btrfs_warn_in_rcu(device->fs_info, ++ /* ++ * device->fs_info may not be reliable here, so ++ * pass in a NULL instead. This avoids a ++ * possible use-after-free when the fs_info and ++ * fs_info->sb are already torn down. ++ */ ++ btrfs_warn_in_rcu(NULL, + "duplicate device %s devid %llu generation %llu scanned by %s (%d)", + path, devid, found_transid, + current->comm, diff --git a/queue-4.19/btrfs-fix-lockdep-splat-when-reading-qgroup-config-on-mount.patch b/queue-4.19/btrfs-fix-lockdep-splat-when-reading-qgroup-config-on-mount.patch new file mode 100644 index 00000000000..eea60b1977f --- /dev/null +++ b/queue-4.19/btrfs-fix-lockdep-splat-when-reading-qgroup-config-on-mount.patch @@ -0,0 +1,162 @@ +From 3d05cad3c357a2b749912914356072b38435edfa Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Mon, 23 Nov 2020 14:28:44 +0000 +Subject: btrfs: fix lockdep splat when reading qgroup config on mount + +From: Filipe Manana + +commit 3d05cad3c357a2b749912914356072b38435edfa upstream. + +Lockdep reported the following splat when running test btrfs/190 from +fstests: + + [ 9482.126098] ====================================================== + [ 9482.126184] WARNING: possible circular locking dependency detected + [ 9482.126281] 5.10.0-rc4-btrfs-next-73 #1 Not tainted + [ 9482.126365] ------------------------------------------------------ + [ 9482.126456] mount/24187 is trying to acquire lock: + [ 9482.126534] ffffa0c869a7dac0 (&fs_info->qgroup_rescan_lock){+.+.}-{3:3}, at: qgroup_rescan_init+0x43/0xf0 [btrfs] + [ 9482.126647] + but task is already holding lock: + [ 9482.126777] ffffa0c892ebd3a0 (btrfs-quota-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x120 [btrfs] + [ 9482.126886] + which lock already depends on the new lock. + + [ 9482.127078] + the existing dependency chain (in reverse order) is: + [ 9482.127213] + -> #1 (btrfs-quota-00){++++}-{3:3}: + [ 9482.127366] lock_acquire+0xd8/0x490 + [ 9482.127436] down_read_nested+0x45/0x220 + [ 9482.127528] __btrfs_tree_read_lock+0x27/0x120 [btrfs] + [ 9482.127613] btrfs_read_lock_root_node+0x41/0x130 [btrfs] + [ 9482.127702] btrfs_search_slot+0x514/0xc30 [btrfs] + [ 9482.127788] update_qgroup_status_item+0x72/0x140 [btrfs] + [ 9482.127877] btrfs_qgroup_rescan_worker+0xde/0x680 [btrfs] + [ 9482.127964] btrfs_work_helper+0xf1/0x600 [btrfs] + [ 9482.128039] process_one_work+0x24e/0x5e0 + [ 9482.128110] worker_thread+0x50/0x3b0 + [ 9482.128181] kthread+0x153/0x170 + [ 9482.128256] ret_from_fork+0x22/0x30 + [ 9482.128327] + -> #0 (&fs_info->qgroup_rescan_lock){+.+.}-{3:3}: + [ 9482.128464] check_prev_add+0x91/0xc60 + [ 9482.128551] __lock_acquire+0x1740/0x3110 + [ 9482.128623] lock_acquire+0xd8/0x490 + [ 9482.130029] __mutex_lock+0xa3/0xb30 + [ 9482.130590] qgroup_rescan_init+0x43/0xf0 [btrfs] + [ 9482.131577] btrfs_read_qgroup_config+0x43a/0x550 [btrfs] + [ 9482.132175] open_ctree+0x1228/0x18a0 [btrfs] + [ 9482.132756] btrfs_mount_root.cold+0x13/0xed [btrfs] + [ 9482.133325] legacy_get_tree+0x30/0x60 + [ 9482.133866] vfs_get_tree+0x28/0xe0 + [ 9482.134392] fc_mount+0xe/0x40 + [ 9482.134908] vfs_kern_mount.part.0+0x71/0x90 + [ 9482.135428] btrfs_mount+0x13b/0x3e0 [btrfs] + [ 9482.135942] legacy_get_tree+0x30/0x60 + [ 9482.136444] vfs_get_tree+0x28/0xe0 + [ 9482.136949] path_mount+0x2d7/0xa70 + [ 9482.137438] do_mount+0x75/0x90 + [ 9482.137923] __x64_sys_mount+0x8e/0xd0 + [ 9482.138400] do_syscall_64+0x33/0x80 + [ 9482.138873] entry_SYSCALL_64_after_hwframe+0x44/0xa9 + [ 9482.139346] + other info that might help us debug this: + + [ 9482.140735] Possible unsafe locking scenario: + + [ 9482.141594] CPU0 CPU1 + [ 9482.142011] ---- ---- + [ 9482.142411] lock(btrfs-quota-00); + [ 9482.142806] lock(&fs_info->qgroup_rescan_lock); + [ 9482.143216] lock(btrfs-quota-00); + [ 9482.143629] lock(&fs_info->qgroup_rescan_lock); + [ 9482.144056] + *** DEADLOCK *** + + [ 9482.145242] 2 locks held by mount/24187: + [ 9482.145637] #0: ffffa0c8411c40e8 (&type->s_umount_key#44/1){+.+.}-{3:3}, at: alloc_super+0xb9/0x400 + [ 9482.146061] #1: ffffa0c892ebd3a0 (btrfs-quota-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x120 [btrfs] + [ 9482.146509] + stack backtrace: + [ 9482.147350] CPU: 1 PID: 24187 Comm: mount Not tainted 5.10.0-rc4-btrfs-next-73 #1 + [ 9482.147788] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 + [ 9482.148709] Call Trace: + [ 9482.149169] dump_stack+0x8d/0xb5 + [ 9482.149628] check_noncircular+0xff/0x110 + [ 9482.150090] check_prev_add+0x91/0xc60 + [ 9482.150561] ? kvm_clock_read+0x14/0x30 + [ 9482.151017] ? kvm_sched_clock_read+0x5/0x10 + [ 9482.151470] __lock_acquire+0x1740/0x3110 + [ 9482.151941] ? __btrfs_tree_read_lock+0x27/0x120 [btrfs] + [ 9482.152402] lock_acquire+0xd8/0x490 + [ 9482.152887] ? qgroup_rescan_init+0x43/0xf0 [btrfs] + [ 9482.153354] __mutex_lock+0xa3/0xb30 + [ 9482.153826] ? qgroup_rescan_init+0x43/0xf0 [btrfs] + [ 9482.154301] ? qgroup_rescan_init+0x43/0xf0 [btrfs] + [ 9482.154768] ? qgroup_rescan_init+0x43/0xf0 [btrfs] + [ 9482.155226] qgroup_rescan_init+0x43/0xf0 [btrfs] + [ 9482.155690] btrfs_read_qgroup_config+0x43a/0x550 [btrfs] + [ 9482.156160] open_ctree+0x1228/0x18a0 [btrfs] + [ 9482.156643] btrfs_mount_root.cold+0x13/0xed [btrfs] + [ 9482.157108] ? rcu_read_lock_sched_held+0x5d/0x90 + [ 9482.157567] ? kfree+0x31f/0x3e0 + [ 9482.158030] legacy_get_tree+0x30/0x60 + [ 9482.158489] vfs_get_tree+0x28/0xe0 + [ 9482.158947] fc_mount+0xe/0x40 + [ 9482.159403] vfs_kern_mount.part.0+0x71/0x90 + [ 9482.159875] btrfs_mount+0x13b/0x3e0 [btrfs] + [ 9482.160335] ? rcu_read_lock_sched_held+0x5d/0x90 + [ 9482.160805] ? kfree+0x31f/0x3e0 + [ 9482.161260] ? legacy_get_tree+0x30/0x60 + [ 9482.161714] legacy_get_tree+0x30/0x60 + [ 9482.162166] vfs_get_tree+0x28/0xe0 + [ 9482.162616] path_mount+0x2d7/0xa70 + [ 9482.163070] do_mount+0x75/0x90 + [ 9482.163525] __x64_sys_mount+0x8e/0xd0 + [ 9482.163986] do_syscall_64+0x33/0x80 + [ 9482.164437] entry_SYSCALL_64_after_hwframe+0x44/0xa9 + [ 9482.164902] RIP: 0033:0x7f51e907caaa + +This happens because at btrfs_read_qgroup_config() we can call +qgroup_rescan_init() while holding a read lock on a quota btree leaf, +acquired by the previous call to btrfs_search_slot_for_read(), and +qgroup_rescan_init() acquires the mutex qgroup_rescan_lock. + +A qgroup rescan worker does the opposite: it acquires the mutex +qgroup_rescan_lock, at btrfs_qgroup_rescan_worker(), and then tries to +update the qgroup status item in the quota btree through the call to +update_qgroup_status_item(). This inversion of locking order +between the qgroup_rescan_lock mutex and quota btree locks causes the +splat. + +Fix this simply by releasing and freeing the path before calling +qgroup_rescan_init() at btrfs_read_qgroup_config(). + +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/qgroup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/qgroup.c ++++ b/fs/btrfs/qgroup.c +@@ -488,13 +488,13 @@ next2: + break; + } + out: ++ btrfs_free_path(path); + fs_info->qgroup_flags |= flags; + if (!(fs_info->qgroup_flags & BTRFS_QGROUP_STATUS_FLAG_ON)) + clear_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags); + else if (fs_info->qgroup_flags & BTRFS_QGROUP_STATUS_FLAG_RESCAN && + ret >= 0) + ret = qgroup_rescan_init(fs_info, rescan_progress, 0); +- btrfs_free_path(path); + + if (ret < 0) { + ulist_free(fs_info->qgroup_ulist); diff --git a/queue-4.19/series b/queue-4.19/series index d5646d4eac1..da8c4923c0c 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -1,2 +1,4 @@ perf-event-check-ref_reloc_sym-before-using-it.patch netfilter-clear-skb-next-in-nf_hook_list.patch +btrfs-don-t-access-possibly-stale-fs_info-data-for-printing-duplicate-device.patch +btrfs-fix-lockdep-splat-when-reading-qgroup-config-on-mount.patch