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