Re: [PATCH v7 00/43] btrfs: add fscrypt support

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Jun 01, 2026 at 07:25:53PM -0700, Eric Biggers wrote:
> On Mon, Jun 01, 2026 at 08:57:30PM +0200, David Sterba wrote:
> > The testing is not straightforward as it needs 3 projects to
> > synchronize, kernel, fstests and btrfs-progs. Testing may need to use
> > custom git branches for all of them. For btrfs-progs the changes will ge
> > it in soon. For fstests it can be a chicken-egg problem, as they don't
> > accept tests for unmerged code. We've been using our fstests [1] with
> > additional fixups (not upstreamable, related to CI workarounds). Though
> > I'm not sure if Daniel has updated the branch with his most recent
> > version.
> > 
> > [1] https://github.com/btrfs/fstests branch staging
> 
> Where are the btrfs-progs changes, then?  I'd like to try this out, but
> there's no way to do it without the btrfs-progs changes.

Please make sure to test with debugging options enabled as well.  Trying
it with KASAN enabled, right away there's an out-of-bounds write in
base64_encode(), because btrfs_real_readdir() has an incorrect buffer
size calculation:

    nokey_len = DIV_ROUND_UP(name_len * 4, 3);

The other filesystems do it right by using fscrypt_fname_alloc_buffer().

Of course it turns out this is in the Sashiko comments as well, quoted
below:

    Is it possible for this check to allow a heap buffer overflow in the
    filldir buffer?

    The length check estimates the fscrypt nokey name size using
    DIV_ROUND_UP(name_len * 4, 3). However, fscrypt_fname_disk_to_usr()
    prepends an 8-byte dirhash before base64 encoding. Furthermore, if
    the name length exceeds 149 bytes, it hashes the name and encodes
    exactly 189 bytes, yielding a 252-byte output.

    If the remaining buffer space is large enough to pass this nokey_len
    check but smaller than the actual bytes produced by
    fscrypt_fname_disk_to_usr(), it looks like
    fscrypt_fname_disk_to_usr() could write past the end of the
    PAGE_SIZE allocation.

I think I've done enough with this series for now.  I'll take a look
again once it's in a better shape.

- Eric