[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPhRvkwLg=5mKv3XKvfLUOPUcbNCAYW2reNub60s5pkLXP=xSQ@mail.gmail.com>
Date: Tue, 23 Sep 2025 12:55:39 -0300
From: Anderson Nascimento <anderson@...elesecurity.com>
To: dsterba@...e.cz
Cc: clm@...com, josef@...icpanda.com, dsterba@...e.com,
linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: Avoid potential out-of-bounds in btrfs_encode_fh()
On Tue, Sep 23, 2025 at 12:11 PM David Sterba <dsterba@...e.cz> wrote:
>
> On Tue, Sep 23, 2025 at 11:37:33AM -0300, Anderson Nascimento wrote:
> > On Tue, Sep 9, 2025 at 7:45 PM David Sterba <dsterba@...e.cz> wrote:
> > >
> > > On Mon, Sep 08, 2025 at 09:49:02AM -0300, Anderson Nascimento wrote:
> > > > Hello all,
> > > >
> > > > The function btrfs_encode_fh() does not properly account for the three
> > > > cases it handles.
> > > >
> > > > Before writing to the file handle (fh), the function only returns to the
> > > > user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or
> > > > BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).
> > > >
> > > > However, when a parent exists and the root ID of the parent and the
> > > > inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT
> > > > (10 dwords, 40 bytes).
> > > >
> > > > If *max_len is not large enough, this write goes out of bounds because
> > > > BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than
> > > > BTRFS_FID_SIZE_CONNECTABLE originally returned.
> > > >
> > > > This results in an 8-byte out-of-bounds write at
> > > > fid->parent_root_objectid = parent_root_id.
> > > >
> > > > A previous attempt to fix this issue was made but was lost.
> > > >
> > > > https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/
> > > >
> > > > Although this issue does not seem to be easily triggerable, it is a
> > > > potential memory corruption bug that should be fixed. This patch
> > > > resolves the issue by ensuring the function returns the appropriate size
> > > > for all three cases and validates that *max_len is large enough before
> > > > writing any data.
> > > >
> > > > Tested on v6.17-rc4.
> > > >
> > > > Fixes: be6e8dc0ba84 ("NFS support for btrfs - v3")
> > > > Signed-off-by: Anderson Nascimento <anderson@...elesecurity.com>
> > >
> > > Thanks for finding the problem and the fix. It's 17 years old though the
> > > other patch was sent about 2 years after btrfs merge to linux kernel.
> > > I'll add it to for-next, with the minor whitespace issues fixed.
> >
> > David, has it been queued somewhere? I don't see it in any of your branches.
>
> That's strange, I thought I'd applied it the same day but the patch is
> nowhere to be found. I'll add it to for-next again, sorry.
No worries, thank you very much.
--
Anderson Nascimento
Allele Security Intelligence
https://www.allelesecurity.com
Powered by blists - more mailing lists