]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.19-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 28 Nov 2020 12:39:32 +0000 (13:39 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 28 Nov 2020 12:39:32 +0000 (13:39 +0100)
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

queue-4.19/btrfs-don-t-access-possibly-stale-fs_info-data-for-printing-duplicate-device.patch [new file with mode: 0644]
queue-4.19/btrfs-fix-lockdep-splat-when-reading-qgroup-config-on-mount.patch [new file with mode: 0644]
queue-4.19/series

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 (file)
index 0000000..57e508b
--- /dev/null
@@ -0,0 +1,171 @@
+From 0697d9a610998b8bdee6b2390836cb2391d8fd1a Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+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 <johannes.thumshirn@wdc.com>
+
+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 <nborisov@suse.com>
+Reviewed-by: Anand Jain <anand.jain@oracle.com>
+Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 (file)
index 0000000..eea60b1
--- /dev/null
@@ -0,0 +1,162 @@
+From 3d05cad3c357a2b749912914356072b38435edfa Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Mon, 23 Nov 2020 14:28:44 +0000
+Subject: btrfs: fix lockdep splat when reading qgroup config on mount
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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 <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
index d5646d4eac18b6eaa72ca7e1b1a6dae61e3485a2..da8c4923c0cf13dc4165d88bd95d67fe1985fa01 100644 (file)
@@ -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