If the FUSE_GETATTR issued to query a file's size during
fuse_vnop_deallocate failed for any reason, then fuse_vnop_deallocate
would attempt to destroy an uninitialized fuse_dispatcher struct, with a
crash the likely result. This bug only affects FUSE file systems that
implement FUSE_FALLOCATE, and is unlikely to be seen on those that don't
disable attribute caching.
Reported by: Coverity Scan
CID: 1505308
(cherry picked from commit f93a50d69df2e996ff1d4f793d0dcb9de655ebdc)
Background:
If a user does pathconf(_, _PC_MIN_HOLE_SIZE) on a fusefs file system,
the kernel must actually issue a FUSE_LSEEK operation in order to
determine whether the server supports it. We cache that result, so we
only have to send FUSE_LSEEK the first time that _PC_MIN_HOLE_SIZE is
requested on any given mountpoint.
Problem 1:
Unlike fpathconf, pathconf operates on files that may not be open. But
FUSE_LSEEK requires the file to be open. As described in PR 278135,
FUSE_LSEEK cannot be sent for unopened files, causing _PC_MIN_HOLE_size
to wrongly report EINVAL. We never noticed that before because the
fusefs test suite only uses fpathconf, not pathconf. Fix this bug by
opening the file if necessary.
Problem 2:
On a completely sparse file, with no data blocks at all, FUSE_LSEEK with
SEEK_DATA would fail to ENXIO. That's correct behavior, but
fuse_vnop_pathconf wrongly interpreted that as "FUSE_LSEEK not
supported". Fix the interpretation.
PR: 278135
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D44618
(cherry picked from commit 6efba04df3f8c77b9b12f1df3e5124a7249b82fc)
These ones were unambiguous cases where the Foundation was the only
listed copyright holder.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 5c2bc3db201a4fe8d7911cf816bea104d5dc2138)
Remove assumptions in two test cases that maxphys won't be huge.
Reported by: kib
Sponsored by: Axcient
(cherry picked from commit b2792a300ddb8d8334b234fe7744f5141cc96103)
The tests try to read kern.maxphys sysctl into int value, while
unsigned long is required. Not sure when this was broken, seems like
since cd85379104.
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D45053
(cherry picked from commit e9b411d273336647e61704213964b995952a44fd)
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D44599
(cherry picked from commit b1fd95c9e24791d44593e611406b41e57826a5b8)
tarfs: Ignore global extended headers.
Previously, we would error out if we encountered a global extended
header, because we don't know what it means. This doesn't really
matter though, and traditionally, tar implementations have either
ignored them or treated them as plain files, so just ignore them.
This allows tarfs to mount tar files created by `git archive`.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D44600
(cherry picked from commit 584e1c355ae3c994331005b7196cc87a714e5317)
tarfs: Fix 32-bit build.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D44613
(cherry picked from commit 0238d3711d9b888f678fce4274eccc9175168395)
* Reject hard or soft links with an empty target path. Currently, a
debugging kernel will hit an assertion in tarfs_lookup_path() while
a non-debugging kernel will happily create a link to the mount root.
* Use a temporary variable to store the result of the link target path,
and copy it to tnp->other only once we have found it to be valid.
Otherwise we error out after creating a reference to the target but
before incrementing the target's reference count, which results in a
use-after-free situation in the cleanup code.
* Correctly return ENOENT from tarfs_lookup_path() if the requested
path was not found and create_dirs is false. Luckily, existing
callers did not rely solely on the return value.
MFC after: 3 days
PR: 277360
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D44161
(cherry picked from commit 38b3683592d4c20a74f52a6e8e29368e6fa61858)
tarfs: Improve validation of numeric fields.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: sjg, allanjude
Differential Revision: https://reviews.freebsd.org/D44166
(cherry picked from commit 8427d94ce05682abb6c75e2a27c8c497962c0dc5)
tarfs: Avoid overflow in exthdr calculation.
MFC after: 3 days
PR: 277420
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44202
(cherry picked from commit c291b7914e1db9469cc820abcb1f5dde7a6f7f28)
tarfs: Remove unnecessary hack and obsolete comment.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D44203
(cherry picked from commit e212f0c0666e7d3a24dce03b8c88920d14b80e47)
tarfs: Fix checksum calculation.
The checksum code assumed that struct ustar_header filled an entire
block and calculcated the checksum based on the size of the structure.
The header is in fact only 500 bytes long while the checksum covers
the entire block (“logical record” in POSIX terms). Add padding and
an assertion, and clean up the checksum code.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44226
(cherry picked from commit 0118b0c8e58a438a931a5ce1bf8d7ae6208cc61b)
tarfs: Factor out common test code.
MFC after: 3 days
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D44227
(cherry picked from commit 32b8aac6f9b77a1c4326083472d634e5de427547)
tarfs: Fix checksum on 32-bit platforms.
MFC after: 3 days
Fixes: b56872332e47786afc09515a4daaf1388da4d73c
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D44261
(cherry picked from commit cbddb2f02c7687d1039abcffd931e94e481c11a5)
If a file system's on-disk format does not support st_birthtime, it
isn't clear what value it should return in stat(2). Neither our man
page nor the OpenGroup specifies. But our convention for UFS and
msdosfs is to return { .tv_sec = -1, .tv_nsec = 0 }. fusefs is
different. It returns { .tv_sec = -1, .tv_nsec = -1 }. It's done that
ever since the initial import in SVN r241519.
Most software apparently handles this just fine. It must, because we've
had no complaints. But the Rust standard library will panic when
reading such a timestamp during std::fs::metadata, even if the caller
doesn't care about that particular value. That's a separate bug, and
should be fixed.
Change our invalid value to match msdosfs and ufs, pacifying the Rust
standard library.
PR: 276602
Sponsored by: Axcient
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D43590
(cherry picked from commit 55b80e2ca52c4b27c4920d372a6e71ac9ab7da9e)
If a copy_file_range operation tries to read from a page that was
previously written via mmap, that page must be flushed first.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D43451
(cherry picked from commit 1c909c300b92601f7690610097ac98126caff835)
The bug isn't fusefs-specific, but this is the easiest way to reproduce
it.
PR: 276191
Differential Revision: https://reviews.freebsd.org/D43446
Reviewed by: kib
(cherry picked from commit 6b1c534927ad47e9b0dd8be1a39f56c3ea813d44)
Building tests/sys/fs/fusefs with clang 18 results the following
warning:
tests/sys/fs/fusefs/cache.cc:145:14: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
145 | uint8_t buf[bufsize];
| ^~~~~~~
Because we do not particularly care that this is a clang extension,
suppress the warning.
MFC after: 3 days
(cherry picked from commit dc0b4094abf6784bf1a9492c2fea3fb91116b014)
In the Mknod.parent_inode test case, the kernel sends an extra
FUSE_FORGET message. But because it gets sent asynchronously with the
failing syscall, it doesn't always get received before the test ends.
So we never setup an expectation for it. And 90+% of the time the test
would exit successfully.
Fix the intermittency by always waiting to receive the FUSE_FORGET
message.
Sponsored by: Axcient
(cherry picked from commit 86885b18689889e9b9142fd31d8c67f21334ba32)
Fix intermittency in the sys.fs.fusefs.symlink.main test
This change is identical to 86885b18689 but for symlink instead of
mknod. The kernel sends a FUSE_FORGET asynchronously with the final
syscall. The lack of an expectation caused this test to occasionally
fail.
Also, remove a sleep that accidentally snuck into a different test.
Sponsored by: Axcient
(cherry picked from commit 8399d764c929a4b2fa98dbfae0ca7359810e4668)
If VOP_READLINK returns a path that contains a NUL, it will trigger an
assertion in vfs_lookup. Sanitize such paths in fusefs, rejecting any
and warning the user about the misbehaving server.
PR: 274268
Sponsored by: Axcient
Reviewed by: mjg, markj
Differential Revision: https://reviews.freebsd.org/D42081
(cherry picked from commit 662ec2f781521c36b76af748d74bb0a3c2e27a76)
When using cached attributes, we must update a file's atime during
close, if it has been read since the last attribute refresh. But,
* Don't update atime if we lack write permissions to the file or if the
file system is readonly.
* If the daemon fails our atime update request for any reason, don't
report this as a failure for VOP_CLOSE.
PR: 270749
Reported by: Jamie Landeg-Jones <jamie@catflap.org>
Sponsored by: Axcient
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D41925
(cherry picked from commit fb619c94c679e939496fe0cf94b8d2cba95e6e63)
fusefs: fix unused variables from fb619c94c67
PR: 270749
Reported by: cy
Sponsored by: Axcient
(cherry picked from commit e5236d25f2c0709acf3547e6af45f4bb4eec4f02)
`INSTANTIATE_TEST_CASE_P` has been replaced with `INSTANTIATE_TEST_SUITE_P`.
Replace all uses of the former macro with the latter macro.
While here, address the fact that the latter macro doesn't permit some
of the constructions that the former macro did, e.g., empty parameters,
etc.
MFC after: 2 weeks
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D41398
GCC complains that DNAME in the inval_entry_below_root test is not
used, but EXPECT_LOOKUP() does pass DNAME to strcmp in an internal
lambda function.
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D40661
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
The actual overflow occured in the ReadAhead.readahead test.
Surprisingly it has never segfaulted or resulted in any bad behavior.
MFC after: 1 week
Sponsored by: Axcient
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38718
The previous fix was incorrect: we need to verify that the current node, if it exists, is not a directory, but we were checking the parent node instead. Address this, add more tests, and fix the test cleanup routines.
PR: 269519, 269561
Fixes: ae6cff8973
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D38645
* tarfs_alloc_mount(): Remove an unnecessary null check (CID 1504505) and an unused variable.
* tarfs_alloc_one(): Verify that the file size is not negative (CID 1504506). While there, also validate the mode, owner and group.
* tarfs_vget(), tarfs_zio_init(): Explicitly ignore return value from getnewvnode(), which cannot fail (CID 1504508)
* tarfs_lookup_path(): Fix a case where a specially-crafted tarball could trigger a null pointer dereference by first descending into, and then backing out of, a previously unknown directory. (CID 1504515)
* mktar: Construct a tarball that triggers the aforementioned null pointer dereference.
Reported by: Coverity
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D38463
When the user specifies SEEK_END, unlike SEEK_CUR, VOP_ADVLOCK must
adjust lock offsets itself.
Sort-of related to bug 266886.
MFC after: 2 weeks
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37040
* If during FUSE_CREATE, FUSE_MKDIR, etc the server returns the same
inode number for the new file as for its parent directory, reject it.
Previously this would triggers a recurse-on-non-recursive lock panic.
* If during FUSE_LINK the server returns a different inode number for
the new name as for the old one, reject it. Obviously, that can't be
a hard link.
* If during FUSE_LOOKUP the server returns the same inode number for the
new file as for its parent directory, reject it. Nothing good can
come of this.
PR: 263662
Reported by: Robert Morris <rtm@lcs.mit.edu>
MFC after: 2 weeks
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D35128
The fusefs tests intentionally leak file descriptors. Annotate all of
the leakages in order to hopefully pacify Coverity.
Reported by: Coverity (20 different CIDs)
MFC after: 2 weeks
Sponsored by: Axcient
The daemon can specify fsname=XXX in its mount options. If so, the file
system should report f_mntfromname as XXX during statfs. This will show
up in the output of commands like mount and df.
Submitted by: Ali Abdallah <ali.abdallah@suse.com>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35090
At mount time server can set, for example, "subtype=xfs", so that
mount(8) will later show the mountpoint's file system as "fusefs.xfs".
fusefs has had this feature ever since the original GSoC commit in 2012,
but there's never been a test for it.
MFC after: 2 weeks
Prior to fuse protocol version 7.9, the fuse_entry_out structure had a
smaller size. But fuse_vnop_create did not take that into account when
working with servers that use older protocols. The bug does not matter
for servers which don't use file handles or open flags (the only fields
affected).
PR: 263625
Submitted by: Ali Abdallah <ali.abdallah@suse.com>
MFC after: 2 weeks
