linux-kernel - Re: [PATCH] fs: btrfs: fix a possible use-after-free bug caused by incorrect error handling in prepare_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <15cdbd02-5d62-95e2-c1f5-2261554a66fe@suse.com>
Date:   Fri, 22 Jul 2022 11:56:44 +0300
From:   Nikolay Borisov <nborisov@...e.com>
To:     Zixuan Fu <r33s3n6@...il.com>, clm@...com, josef@...icpanda.com,
        dsterba@...e.com
Cc:     linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        baijiaju1990@...il.com, TOTE Robot <oslab@...nghua.edu.cn>
Subject: Re: [PATCH] fs: btrfs: fix a possible use-after-free bug caused by
 incorrect error handling in prepare_to_relocate()



On 21.07.22 г. 10:48 ч., Zixuan Fu wrote:
> In btrfs_relocate_block_group(), the structure variable rc is allocated.
> Then btrfs_relocate_block_group() calls relocate_block_group() ->
> prepare_to_relocate() -> set_reloc_control(), and assigns rc to the
> variable fs_info->reloc_ctl. When prepare_to_relocate() returns, it
> calls btrfs_commit_transaction() -> btrfs_start_dirty_block_groups()

nit: transaction commit can fail for a number of reasons, not 
necessarily enomem, even due to ENOSPC errors or faulty hardware.

> -> btrfs_alloc_path() -> kmem_cache_zalloc(), which may fail. When the
> failure occurs, btrfs_relocate_block_group() detects the error and frees
> rc and doesn't set fs_info->reloc_ctl to NULL. After that, in
> btrfs_init_reloc_root(), rc is retrieved from fs_info->reloc_ctl and
> then used, which may cause a use-after-free bug.
> 
> This possible bug can be triggered by calling btrfs_ioctl_balance()
> before calling btrfs_ioctl_defrag().
> 
> To fix this possible bug, in prepare_to_relocate(), an if statement
> is added to check whether btrfs_commit_transaction() fails. If the
> failure occurs, unset_reloc_control() is called to set
> fs_info->reloc_ctl to NULL.
> 
> The error log in our fault-injection testing is shown as follows:
> 
> [   58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs]
> ...
> [   58.753577] Call Trace:
> ...
> [   58.755800]  kasan_report+0x45/0x60
> [   58.756066]  btrfs_init_reloc_root+0x7ca/0x920 [btrfs]
> [   58.757304]  record_root_in_trans+0x792/0xa10 [btrfs]
> [   58.757748]  btrfs_record_root_in_trans+0x463/0x4f0 [btrfs]
> [   58.758231]  start_transaction+0x896/0x2950 [btrfs]
> [   58.758661]  btrfs_defrag_root+0x250/0xc00 [btrfs]
> [   58.759083]  btrfs_ioctl_defrag+0x467/0xa00 [btrfs]
> [   58.759513]  btrfs_ioctl+0x3c95/0x114e0 [btrfs]
> ...
> [   58.768510] Allocated by task 23683:
> [   58.768777]  ____kasan_kmalloc+0xb5/0xf0
> [   58.769069]  __kmalloc+0x227/0x3d0
> [   58.769325]  alloc_reloc_control+0x10a/0x3d0 [btrfs]
> [   58.769755]  btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs]
> [   58.770228]  btrfs_relocate_chunk+0xf1/0x760 [btrfs]
> [   58.770655]  __btrfs_balance+0x1326/0x1f10 [btrfs]
> [   58.771071]  btrfs_balance+0x3150/0x3d30 [btrfs]
> [   58.771472]  btrfs_ioctl_balance+0xd84/0x1410 [btrfs]
> [   58.771902]  btrfs_ioctl+0x4caa/0x114e0 [btrfs]
> ...
> [   58.773337] Freed by task 23683:
> ...
> [   58.774815]  kfree+0xda/0x2b0
> [   58.775038]  free_reloc_control+0x1d6/0x220 [btrfs]
> [   58.775465]  btrfs_relocate_block_group+0x115c/0x1e20 [btrfs]
> [   58.775944]  btrfs_relocate_chunk+0xf1/0x760 [btrfs]
> [   58.776369]  __btrfs_balance+0x1326/0x1f10 [btrfs]
> [   58.776784]  btrfs_balance+0x3150/0x3d30 [btrfs]
> [   58.777185]  btrfs_ioctl_balance+0xd84/0x1410 [btrfs]
> [   58.777621]  btrfs_ioctl+0x4caa/0x114e0 [btrfs]
> ...
> 
> Reported-by: TOTE Robot <oslab@...nghua.edu.cn>
> Signed-off-by: Zixuan Fu <r33s3n6@...il.com>


Reviewed-by: Nikolay Borisov <nborisov@...e.com>