Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v4 0/3] btrfs: fix a UAF where btrfs_root::dirty_list is freed but still referred
Date: Fri, 9 Oct 2026 09:30:51 -0700	[thread overview]
Message-ID: <20261009163051.GA2648158@zen.localdomain> (raw)
In-Reply-To: <cover.1791497576.git.wqu@suse.com>

On Fri, Oct 09, 2026 at 08:43:37AM +1030, Qu Wenruo wrote:
> [CHANGELOG]
> v4:
> - Also cleanup qgroup swapped blocks and dirty_log_pages
>   Which are only released during switch_commit_roots().
> 
> v3:
> - Use Yalagada's v2 fix as the final UAF fix
>   The delayed list_del_init() call inside btrfs_put_root() is not
>   safe as another racing ioctl can grab the quota root, extending
>   its lifespan.
> 
> v2:
> - Add extra patches to address Sashiko's comment
>   * Make all root->dirty_list users to hold trans_lock
>   * Release root->dirty_list from cur_trans->switch_commits during
>     transaction cleanup
> 
> The first patch is to make lock consistent when accessing
> btrfs_root::dirty_list, btrfs_fs_info::dirty_cowonly_roots and
> btrfs_transaction::switch_commits.
> 
> Normally it's not a big deal as the existing lock-holding callers are
> also holding a trans handle, thus they can not race with transaction
> committing.
> But the last commit will change the cleanup timing, and Sashiko is not
> happy with that, so make it more consistent and shut Sashiko up.

As far as I can tell, it is possible but unlikely (rescan + squota?) for
the new callsite to actually do the removal outside a trans handle. Is
that your understanding?

I would prefer to have the bar for "shutting sashiko up" to be at real
bugs, even if they are sort of unlikely. If I misunderstood and it's
fully a false alarm, I would sort of rather not make changes to satisfy
its misconceptions.

Fixes look good overall, thanks.
Reviewed-by: Boris Burkov <boris@bur.io>

> 
> The second patch is an existing bug exposed by Sashiko, which also
> affects the last UAF fix.
> 
> The last one is the final UAF fix for the bug reported by syzbot.
> 
> Qu Wenruo (2):
>   btrfs: protect dirty_cowonly_roots, switch_commits and
>     root->dirty_list
>   btrfs: prevent use-after-free in btrfs_transaction::switch_commits
> 
> Yalagada Pavan Kumar (1):
>   btrfs: fix use-after-free on quota enable allocation failure
> 
>  fs/btrfs/disk-io.c     | 14 ++++++++++++++
>  fs/btrfs/qgroup.c      |  7 +++++++
>  fs/btrfs/transaction.c | 30 ++++++++++++++++++++++++++----
>  3 files changed, 47 insertions(+), 4 deletions(-)
> 
> -- 
> 2.55.0
> 

  parent reply	other threads:[~2026-10-09 16:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 22:13 [PATCH v4 0/3] btrfs: fix a UAF where btrfs_root::dirty_list is freed but still referred Qu Wenruo
2026-10-08 22:13 ` [PATCH v4 1/3] btrfs: protect dirty_cowonly_roots, switch_commits and root->dirty_list Qu Wenruo
2026-10-08 22:13 ` [PATCH v4 2/3] btrfs: prevent use-after-free in btrfs_transaction::switch_commits Qu Wenruo
2026-10-08 22:13 ` [PATCH v4 3/3] btrfs: fix use-after-free on quota enable allocation failure Qu Wenruo
2026-10-09 16:30 ` Boris Burkov [this message]
2026-10-09 21:00   ` [PATCH v4 0/3] btrfs: fix a UAF where btrfs_root::dirty_list is freed but still referred Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261009163051.GA2648158@zen.localdomain \
    --to=boris@bur.io \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox