Uninitialized heap data returned in nocache mode when Reader::Read produces short read

[XavLimSG]

Hi maintainers,

I found a correctness issue in the Read() path for -o nocache mode.

When Reader::Read(offset, dst) returns short (for example during sparse-hole reads), the code shrinks dst to the unread tail and then adds dst.size() to the return length. But the NUL padding line is currently commented out, so the unread tail bytes are never initialized before being counted as returned data.

Relevant code (fuse-archive.cc, around line 3398):

ssize_t n = r->Read(offset, dst);
assert(n >= 0);
assert(n <= dst.size());
dst = dst.subspan(n);

// std::ranges::fill(dst, '\0');   // <-- disabled
assert(std::ranges::all_of(dst, [](char const c) { return c == '\0'; }));
n += dst.size();
return static_cast<int>(n);

In release builds (where assert is compiled out), this means the buffer tail goes back to the caller with whatever happened to be in heap memory.

The fix is straightforward: uncomment the std::ranges::fill(dst, '\0') line so that unread tail bytes are explicitly zeroed before inflating the return length.

I have a patch and a regression test ready. Happy to open a PR if that works for you.

[fdegros]

Thanks for your report.

As far as I can tell, the output buffer passed to the Read() function is already zeroed out by the FUSE layer. There is no need to zero it out again. The debug assertion you mentioned checks that this is the case. You can build fuse-archive with debug assertions and run the tests by running:

$ DEBUG=1 make clean check

I took your test and ran it, but without modifying fuse-archive. It passes, and there is no indication of any data corruption.

$ DEBUG=1 make clean check
rm -rf out
mkdir -p out
g++  -DFUSE_USE_VERSION=30 -I/usr/include/fuse3  -std=c++20 -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -D_FILE_OFFSET_BITS=64 -O0 -g fuse-archive.cc -lfuse3 -lpthread -larchive  -o out/fuse-archive
python3 test/test.py
INFO:root:Test sparse short read zero-fill in nocache mode
INFO:root:PASS: All tests passed

I also checked with FUSE 2. (I had to remove the '--' argument in your test for that.)

$ DEBUG=1 FUSE_MAJOR_VERSION=2 make clean check
rm -rf out
mkdir -p out
g++  -DFUSE_USE_VERSION=26 -I/usr/include/fuse -D_FILE_OFFSET_BITS=64  -std=c++20 -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -D_FILE_OFFSET_BITS=64 -O0 -g fuse-archive.cc -lfuse -pthread -larchive  -o out/fuse-archive
python3 test/test.py
INFO:root:Will skip tests relying on openssl
INFO:root:Test sparse short read zero-fill in nocache mode
INFO:root:PASS: All tests passed

I also checked without the debug assertions:

$ DEBUG=0 FUSE_MAJOR_VERSION=3 make clean check
rm -rf out
mkdir -p out
g++  -DFUSE_USE_VERSION=30 -I/usr/include/fuse3  -std=c++20 -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -D_FILE_OFFSET_BITS=64 -O2 -DNDEBUG fuse-archive.cc -lfuse3 -lpthread -larchive  -o out/fuse-archive
python3 test/test.py
INFO:root:Will skip tests relying on openssl
INFO:root:Test sparse short read zero-fill in nocache mode
INFO:root:PASS: All tests passed

$ DEBUG=0 FUSE_MAJOR_VERSION=2 make clean check
rm -rf out
mkdir -p out
g++  -DFUSE_USE_VERSION=26 -I/usr/include/fuse -D_FILE_OFFSET_BITS=64  -std=c++20 -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -D_FILE_OFFSET_BITS=64 -O2 -DNDEBUG fuse-archive.cc -lfuse -pthread -larchive  -o out/fuse-archive
python3 test/test.py
INFO:root:Will skip tests relying on openssl
INFO:root:Test sparse short read zero-fill in nocache mode
INFO:root:PASS: All tests passed

So far, I don't see any issue.

Can you provide a verifiable proof of an actual issue? If yes, please specify the exact OS type and OS version, as well as the FUSE library version.

[XavLimSG]

@fdegros

I went back and re-tested this more carefully in a real local setup.

What I verified:

• Upstream main at 0bf9b34
• Ubuntu 22.04.5 LTS
• fuse3 3.10.5-1build1
• libfuse3-3 3.10.5-1build1
• libarchive13 3.6.0-1ubuntu1.6

With a hole-only sparse tar mounted using -o nocache,direct_io, and with MALLOC_PERTURB_=170 set, the first pread(..., 4096, 0) from hole.bin returns uninitialized 0x55 bytes instead of zeros.

I also isolated libarchive directly on the same machine. For that sparse entry, archive_read_data() returns 0 on the first 4096-byte read. In fuse-archive, that leaves the destination buffer untouched and then the code still inflates the return length to the full request.

So the issue is real.

A couple of corrections to my original report:

• My earlier regression test was not strong enough by itself, because without allocator poisoning this can be masked by zeroed heap pages.
• On current main, this is no longer literally an "uncomment" fix, because the fill line is gone now.

The fix is still the same in substance: zero the unread tail before counting it as returned data, i.e. add:

std::ranges::fill(dst, '\0');

right before:

n += dst.size();

I verified that with that change, the same repro returns all-zero data as expected.

One caveat: in the default usage model this looks like a local same-user memory disclosure / hardening bug, not a demonstrated cross-user leak.

Here is a reproducible proof script validated on Ubuntu 22.04.5 / fuse3 3.10.5 / libarchive 3.6.0

fuse.sh