Re: [PATCH 0/5] btrfs: fix exploits that allow malicious users to turn fs into RO mode

[Boris Burkov <boris@bur.io>]

On Thu, Feb 26, 2026 at 09:18:06PM +0000, Filipe Manana wrote:
> On Thu, Feb 26, 2026 at 7:09 PM Boris Burkov <boris@bur.io> wrote:
> >
> > On Thu, Feb 26, 2026 at 02:33:57PM +0000, fdmanana@kernel.org wrote:
> > > From: Filipe Manana <fdmanana@suse.com>
> > >
> > > We have a couple scenarios that regular users can exploit to trigger a
> > > transaction abort and turn a filesystem into RO mode, causing some
> > > disruption. The first 2 patches fix these, the remainder are just a few
> > > trivial and cleanups.
> >
> > Bug fixes and cleanups look good. No need to abort in these cases as you
> > have shown.
> > Reviewed-by: Boris Burkov <boris@bur.io>
> >
> > But on the topic of security, or malicious users:
> >
> > How is this sort of attack conceptually different from simply filling
> > up the filesystem with fallocates then doing random metadata operations
> > until we ENOSPC and go readonly?
> 
> What makes you think that users causing an ENOSPC that triggers a
> transaction abort isn't an issue?
> 
> If we know of any intentional way to trigger that, we should definitely fix it.
> Even some weeks ago I fixed such a case reported by a user when
> running bonnie++:
> 
> https://lore.kernel.org/linux-btrfs/SA1PR18MB56922F690C5EC2D85371408B998FA@SA1PR18MB5692.namprd18.prod.outlook.com/
> 
> We often see users reporting that sort of issue, but we don't know the
> workloads, how to reproduce and the state of their fs most of the
> time.
> 
> >
> > What about if the attacker also exploits the behavior of the extent
> > allocator to try to produce fragmentation driven metadata ENOSPCs
> > aborts?
> 
> Do you know of a way to do that?
> If you do, we should fix it.
> 
> No matter what a user does, especially a non-privileged user, it
> should not trigger transaction aborts in an easy way (or anything else
> bad, like memory leaks, use-after-frees, NULL pointer derefs, etc).

Fair enough, I like this stance.

Looks like I had too low of an opinion of our intended ENOSPC
guarantees :)

> 
> Thanks.
> 
> >
> > Thanks,
> > Boris
> >
> > >
> > > Filipe Manana (5):
> > >   btrfs: fix transaction abort on file creation due to name hash collision
> > >   btrfs: fix transaction abort when snapshotting received subvolumes
> > >   btrfs: stop checking for -EEXIST return value from btrfs_uuid_tree_add()
> > >   btrfs: remove duplicated uuid tree existence check in btrfs_uuid_tree_add()
> > >   btrfs: remove pointless error check in btrfs_check_dir_item_collision()
> > >
> > >  fs/btrfs/dir-item.c    |  4 +---
> > >  fs/btrfs/inode.c       | 19 +++++++++++++++++++
> > >  fs/btrfs/ioctl.c       |  2 +-
> > >  fs/btrfs/transaction.c | 18 +++++++++++++++++-
> > >  fs/btrfs/uuid-tree.c   |  5 +----
> > >  5 files changed, 39 insertions(+), 9 deletions(-)
> > >
> > > --
> > > 2.47.2
> > >