[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241015163828.GK1609@twin.jikos.cz>
Date: Tue, 15 Oct 2024 18:38:28 +0200
From: David Sterba <dsterba@...e.cz>
To: Filipe Manana <fdmanana@...nel.org>
Cc: Edward Adam Davis <eadavis@...com>,
syzbot+c3a3a153f0190dca5be9@...kaller.appspotmail.com, clm@...com,
dsterba@...e.com, josef@...icpanda.com, linux-btrfs@...r.kernel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH next] btrfs: Accessing head_ref within delayed_refs lock
On Tue, Oct 15, 2024 at 01:49:04PM +0100, Filipe Manana wrote:
> On Tue, Oct 15, 2024 at 1:40 PM Edward Adam Davis <eadavis@...com> wrote:
> >
> > This is because the thread routine btrfs_work_helper released head_def after
> > exiting delayed_refs->lock in add_delayed_ref.
>
> This should be explained a lot better. Starting the changelog with
> "This is because..." is odd. It should explain why the head reference
> was freed (because delayed references were run).
>
> > Causing add_delayed_ref to encounter uaf when accessing head_def->bytenr
> > outside the delayed_refs->lock.
> >
> > Move head_ref->bytenr into the protection range of delayed_refs->lock
> > to avoid uaf in add_delayed_ref.
>
>
> This was already fixed yesterday, in a simpler way and with an
> explanation of what's going on to trigger the use-after-free:
>
> https://lore.kernel.org/linux-btrfs/02fc507b62b19be2348fc08de8b13bd7af1a440e.1728922973.git.fdmanana@suse.com/
This will be in the upcoming linux-next, so we'll not get the syzbot and
build reports anymore.
Powered by blists - more mailing lists