1. 06 1月, 2023 3 次提交
    • G
      xfs: fix super block buf log item UAF during force shutdown · 766ae6eb
      Guo Xuenan 提交于
      mainline inclusion
      from mainline-v6.1-rc4
      commit 575689fc
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=575689fc0ffa6c4bb4e72fd18e31a6525a6124e0
      
      --------------------------------
      
      xfs log io error will trigger xlog shut down, and end_io worker call
      xlog_state_shutdown_callbacks to unpin and release the buf log item.
      The race condition is that when there are some thread doing transaction
      commit and happened not to be intercepted by xlog_is_shutdown, then,
      these log item will be insert into CIL, when unpin and release these
      buf log item, UAF will occur. BTW, add delay before `xlog_cil_commit`
      can increase recurrence probability.
      
      The following call graph actually encountered this bad situation.
      fsstress                    io end worker kworker/0:1H-216
                                  xlog_ioend_work
                                    ->xlog_force_shutdown
                                      ->xlog_state_shutdown_callbacks
                                        ->xlog_cil_process_committed
                                          ->xlog_cil_committed
                                            ->xfs_trans_committed_bulk
      ->xfs_trans_apply_sb_deltas             ->li_ops->iop_unpin(lip, 1);
        ->xfs_trans_getsb
          ->_xfs_trans_bjoin
            ->xfs_buf_item_init
              ->if (bip) { return 0;} //relog
      ->xlog_cil_commit
        ->xlog_cil_insert_items //insert into CIL
                                                 ->xfs_buf_ioend_fail(bp);
                                                   ->xfs_buf_ioend
                                                     ->xfs_buf_item_done
                                                       ->xfs_buf_item_relse
                                                         ->xfs_buf_item_free
      
      when cil push worker gather percpu cil and insert super block buf log item
      into ctx->log_items then uaf occurs.
      
      ==================================================================
      BUG: KASAN: use-after-free in xlog_cil_push_work+0x1c8f/0x22f0
      Write of size 8 at addr ffff88801800f3f0 by task kworker/u4:4/105
      
      CPU: 0 PID: 105 Comm: kworker/u4:4 Tainted: G W
      6.1.0-rc1-00001-g274115149b42 #136
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      1.13.0-1ubuntu1.1 04/01/2014
      Workqueue: xfs-cil/sda xlog_cil_push_work
      Call Trace:
       <TASK>
       dump_stack_lvl+0x4d/0x66
       print_report+0x171/0x4a6
       kasan_report+0xb3/0x130
       xlog_cil_push_work+0x1c8f/0x22f0
       process_one_work+0x6f9/0xf70
       worker_thread+0x578/0xf30
       kthread+0x28c/0x330
       ret_from_fork+0x1f/0x30
       </TASK>
      
      Allocated by task 2145:
       kasan_save_stack+0x1e/0x40
       kasan_set_track+0x21/0x30
       __kasan_slab_alloc+0x54/0x60
       kmem_cache_alloc+0x14a/0x510
       xfs_buf_item_init+0x160/0x6d0
       _xfs_trans_bjoin+0x7f/0x2e0
       xfs_trans_getsb+0xb6/0x3f0
       xfs_trans_apply_sb_deltas+0x1f/0x8c0
       __xfs_trans_commit+0xa25/0xe10
       xfs_symlink+0xe23/0x1660
       xfs_vn_symlink+0x157/0x280
       vfs_symlink+0x491/0x790
       do_symlinkat+0x128/0x220
       __x64_sys_symlink+0x7a/0x90
       do_syscall_64+0x35/0x80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Freed by task 216:
       kasan_save_stack+0x1e/0x40
       kasan_set_track+0x21/0x30
       kasan_save_free_info+0x2a/0x40
       __kasan_slab_free+0x105/0x1a0
       kmem_cache_free+0xb6/0x460
       xfs_buf_ioend+0x1e9/0x11f0
       xfs_buf_item_unpin+0x3d6/0x840
       xfs_trans_committed_bulk+0x4c2/0x7c0
       xlog_cil_committed+0xab6/0xfb0
       xlog_cil_process_committed+0x117/0x1e0
       xlog_state_shutdown_callbacks+0x208/0x440
       xlog_force_shutdown+0x1b3/0x3a0
       xlog_ioend_work+0xef/0x1d0
       process_one_work+0x6f9/0xf70
       worker_thread+0x578/0xf30
       kthread+0x28c/0x330
       ret_from_fork+0x1f/0x30
      
      The buggy address belongs to the object at ffff88801800f388
       which belongs to the cache xfs_buf_item of size 272
      The buggy address is located 104 bytes inside of
       272-byte region [ffff88801800f388, ffff88801800f498)
      
      The buggy address belongs to the physical page:
      page:ffffea0000600380 refcount:1 mapcount:0 mapping:0000000000000000
      index:0xffff88801800f208 pfn:0x1800e
      head:ffffea0000600380 order:1 compound_mapcount:0 compound_pincount:0
      flags: 0x1fffff80010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
      raw: 001fffff80010200 ffffea0000699788 ffff88801319db50 ffff88800fb50640
      raw: ffff88801800f208 000000000015000a 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88801800f280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88801800f300: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88801800f380: fc fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                   ^
       ffff88801800f400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88801800f480: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      Disabling lock debugging due to kernel taint
      Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      (cherry picked from commit 5a5e896a)
      766ae6eb
    • G
      xfs: wait iclog complete before tearing down AIL · fabfebe7
      Guo Xuenan 提交于
      mainline inclusion
      from mainline-v6.1-rc4
      commit 1eb52a6a
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1eb52a6a71981b80f9acbd915acd6a05a5037196
      
      --------------------------------
      
      Fix uaf in xfs_trans_ail_delete during xlog force shutdown.
      In commit cd6f79d1 ("xfs: run callbacks before waking waiters in
      xlog_state_shutdown_callbacks") changed the order of running callbacks
      and wait for iclog completion to avoid unmount path untimely destroy AIL.
      But which seems not enough to ensue this, adding mdelay in
      `xfs_buf_item_unpin` can prove that.
      
      The reproduction is as follows. To ensure destroy AIL safely,
      we should wait all xlog ioend workers done and sync the AIL.
      
      ==================================================================
      BUG: KASAN: use-after-free in xfs_trans_ail_delete+0x240/0x2a0
      Read of size 8 at addr ffff888023169400 by task kworker/1:1H/43
      
      CPU: 1 PID: 43 Comm: kworker/1:1H Tainted: G        W
      6.1.0-rc1-00002-gc28266863c4a #137
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      1.13.0-1ubuntu1.1 04/01/2014
      Workqueue: xfs-log/sda xlog_ioend_work
      Call Trace:
       <TASK>
       dump_stack_lvl+0x4d/0x66
       print_report+0x171/0x4a6
       kasan_report+0xb3/0x130
       xfs_trans_ail_delete+0x240/0x2a0
       xfs_buf_item_done+0x7b/0xa0
       xfs_buf_ioend+0x1e9/0x11f0
       xfs_buf_item_unpin+0x4c8/0x860
       xfs_trans_committed_bulk+0x4c2/0x7c0
       xlog_cil_committed+0xab6/0xfb0
       xlog_cil_process_committed+0x117/0x1e0
       xlog_state_shutdown_callbacks+0x208/0x440
       xlog_force_shutdown+0x1b3/0x3a0
       xlog_ioend_work+0xef/0x1d0
       process_one_work+0x6f9/0xf70
       worker_thread+0x578/0xf30
       kthread+0x28c/0x330
       ret_from_fork+0x1f/0x30
       </TASK>
      
      Allocated by task 9606:
       kasan_save_stack+0x1e/0x40
       kasan_set_track+0x21/0x30
       __kasan_kmalloc+0x7a/0x90
       __kmalloc+0x59/0x140
       kmem_alloc+0xb2/0x2f0
       xfs_trans_ail_init+0x20/0x320
       xfs_log_mount+0x37e/0x690
       xfs_mountfs+0xe36/0x1b40
       xfs_fs_fill_super+0xc5c/0x1a70
       get_tree_bdev+0x3c5/0x6c0
       vfs_get_tree+0x85/0x250
       path_mount+0xec3/0x1830
       do_mount+0xef/0x110
       __x64_sys_mount+0x150/0x1f0
       do_syscall_64+0x35/0x80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Freed by task 9662:
       kasan_save_stack+0x1e/0x40
       kasan_set_track+0x21/0x30
       kasan_save_free_info+0x2a/0x40
       __kasan_slab_free+0x105/0x1a0
       __kmem_cache_free+0x99/0x2d0
       kvfree+0x3a/0x40
       xfs_log_unmount+0x60/0xf0
       xfs_unmountfs+0xf3/0x1d0
       xfs_fs_put_super+0x78/0x300
       generic_shutdown_super+0x151/0x400
       kill_block_super+0x9a/0xe0
       deactivate_locked_super+0x82/0xe0
       deactivate_super+0x91/0xb0
       cleanup_mnt+0x32a/0x4a0
       task_work_run+0x15f/0x240
       exit_to_user_mode_prepare+0x188/0x190
       syscall_exit_to_user_mode+0x12/0x30
       do_syscall_64+0x42/0x80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      The buggy address belongs to the object at ffff888023169400
       which belongs to the cache kmalloc-128 of size 128
      The buggy address is located 0 bytes inside of
       128-byte region [ffff888023169400, ffff888023169480)
      
      The buggy address belongs to the physical page:
      page:ffffea00008c5a00 refcount:1 mapcount:0 mapping:0000000000000000
      index:0xffff888023168f80 pfn:0x23168
      head:ffffea00008c5a00 order:1 compound_mapcount:0 compound_pincount:0
      flags: 0x1fffff80010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
      raw: 001fffff80010200 ffffea00006b3988 ffffea0000577a88 ffff88800f842ac0
      raw: ffff888023168f80 0000000000150007 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888023169300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff888023169380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff888023169400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                         ^
       ffff888023169480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff888023169500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      Disabling lock debugging due to kernel taint
      
      Fixes: cd6f79d1 ("xfs: run callbacks before waking waiters in xlog_state_shutdown_callbacks")
      Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      (cherry picked from commit 1146fdf4)
      fabfebe7
    • G
      xfs: get rid of assert from xfs_btree_islastblock · 837215b2
      Guo Xuenan 提交于
      mainline inclusion
      from mainline-v6.1-rc4
      commit 8c25febf
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c25febf23963431686f04874b96321288504127
      
      --------------------------------
      
      xfs_btree_check_block contains debugging knobs. With XFS_DEBUG setting up,
      turn on the debugging knob can trigger the assert of xfs_btree_islastblock,
      test script as follows:
      
      while true
      do
          mount $disk $mountpoint
          fsstress -d $testdir -l 0 -n 10000 -p 4 >/dev/null
          echo 1 > /sys/fs/xfs/sda/errortag/btree_chk_sblk
          sleep 10
          umount $mountpoint
      done
      
      Kick off fsstress and only *then* turn on the debugging knob. If it
      happens that the knob gets turned on after the cntbt lookup succeeds
      but before the call to xfs_btree_islastblock, then we *can* end up in
      the situation where a previously checked btree block suddenly starts
      returning EFSCORRUPTED from xfs_btree_check_block. Kaboom.
      
      Darrick give a very detailed explanation as follows:
      Looking back at commit 27d9ee57, I think the point of all this was
      to make sure that the cursor has actually performed a lookup, and that
      the btree block at whatever level we're asking about is ok.
      
      If the caller hasn't ever done a lookup, the bc_levels array will be
      empty, so cur->bc_levels[level].bp pointer will be NULL.  The call to
      xfs_btree_get_block will crash anyway, so the "ASSERT(block);" part is
      pointless.
      
      If the caller did a lookup but the lookup failed due to block
      corruption, the corresponding cur->bc_levels[level].bp pointer will also
      be NULL, and we'll still crash.  The "ASSERT(xfs_btree_check_block);"
      logic is also unnecessary.
      
      If the cursor level points to an inode root, the block buffer will be
      incore, so it had better always be consistent.
      
      If the caller ignores a failed lookup after a successful one and calls
      this function, the cursor state is garbage and the assert wouldn't have
      tripped anyway. So get rid of the assert.
      
      Fixes: 27d9ee57 ("xfs: actually check xfs_btree_check_block return in xfs_btree_islastblock")
      Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
      Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      (cherry picked from commit be18cd15)
      837215b2
  2. 21 11月, 2022 37 次提交