linux-kernel - Re: [PATCH] btrfs: Avoid potential out-of-bounds in btrfs_encode

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: <20250923151110.GV5333@suse.cz>
Date: Tue, 23 Sep 2025 17:11:11 +0200
From: David Sterba <dsterba@...e.cz>
To: Anderson Nascimento <anderson@...elesecurity.com>
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 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.