Re: [PATCH] fs: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak

[Yochai E <echelonh@gmail.com>]

On Mon, Mar 23, 2026 at 4:26 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Sun, Mar 22, 2026 at 08:39:35AM +0200, Yochai Eisenrich wrote:
> > From: Yochai Eisenrich <yochaie@sweet.security>
> >
> > btrfs_ioctl_space_info() has a TOCTOU race between two passes over the
> > block group RAID type lists. The first pass counts entries to determine
> > the allocation size, then the second pass fills the buffer. The
> > groups_sem rwlock is released between passes, allowing concurrent block
> > group removal to reduce the entry count.
> >
> > When the second pass fills fewer entries than the first pass counted,
> > copy_to_user() copies the full alloc_size bytes including trailing
> > uninitialized kmalloc bytes to userspace.
>
> This sounds correct.
>
> > Fix by copying only total_spaces entries (the actually-filled count from
> > the second pass) instead of alloc_size bytes, and switch to kzalloc so
> > any future copy size mismatch cannot leak heap data.
>
> Trying to hit this race looks very hard though, reducing number of block
> group types is quite rare.

I agree that this may not be your btrfs typical behavior, but I wouldn't
have raised the issue if I wasn't able to prove it. I can send the PoC
code your way if you're interested - it leaks kernel data. A malicious
user can utilize a fresh btrfs disk over e.g. zram to trigger the issue.

> The change to kzalloc looks like best fix, for all ioctls that are
> exposed to userspace. Copying the exact number makes sense. The other
> case (copying too much) has been fixed in 51788b1bdd0d68 ("btrfs:
> prevent heap corruption in btrfs_ioctl_space_info()").

Just to make sure we're on the same page:
1. Following the above, do you approve of the copy_to_user fix I
    suggested?
2. I think it makes sense to treat other ioctl kmallocs in a different
    patch, no?

> >
> > Fixes: 7fde62bffb57 ("Btrfs: buffer results in the space_info ioctl")
> >
> > Signed-off-by: Yochai Eisenrich <echelonh@gmail.com>
>
> Added to for-next, thanks.