linux-kernel - Re: [PATCH] fs: btrfs: fix possible use-after-free bug in error handling code of btrfs_get_root

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]

Date:   Thu, 24 Mar 2022 19:19:40 +0100
From:   David Sterba <dsterba@...e.cz>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
Cc:     clm@...com, josef@...icpanda.com, dsterba@...e.com,
        linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: btrfs: fix possible use-after-free bug in error
 handling code of btrfs_get_root_ref()

On Thu, Mar 24, 2022 at 06:44:54AM -0700, Jia-Ju Bai wrote:
> In btrfs_get_root_ref(), when btrfs_insert_fs_root() fails,
> btrfs_put_root() will be called to possibly free the memory area of
> the variable root. However, this variable is then used again in error
> handling code after "goto fail", when ret is not -EEXIST.
> 
> To fix this possible bug, btrfs_put_root() is only called when ret is 
> -EEXIST for "goto again".
> 
> Reported-by: TOTE Robot <oslab@...nghua.edu.cn>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@...il.com>
> ---
>  fs/btrfs/disk-io.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index b30309f187cf..126f244cdf88 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -1850,9 +1850,10 @@ static struct btrfs_root *btrfs_get_root_ref(struct btrfs_fs_info *fs_info,
>  
>  	ret = btrfs_insert_fs_root(fs_info, root);
>  	if (ret) {
> -		btrfs_put_root(root);
> -		if (ret == -EEXIST)
> +		if (ret == -EEXIST) {
> +			btrfs_put_root(root);

I think this fix is correct, though it's not that clear. If you look how
the code changed, there was the unconditional put and then followed by a
free:

8c38938c7bb0 ("btrfs: move the root freeing stuff into btrfs_put_root")

Here it's putting twice where one will be the final free.

And then the whole refcounting gets updated in

4785e24fa5d2 ("btrfs: don't take an extra root ref at allocation time")

which could be removing the wrong put, I'm not yet sure.