Simply opening a fuse-backed file with open(pathname, O_EXEC) is enough to trigger a panic. The bug is in fuse_filehandle_xlate_from_fflags, which assumes that at least one of FREAD or FWRITE will always be set. But that's not true when opening a file with O_EXEC. It seems surprising that nobody's run into this bug already. panic: FUSE: What kind of a flag is this (40000)? cpuid = 3 time = 1551894988 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0030ca4510 vpanic() at vpanic+0x1b4/frame 0xfffffe0030ca4570 panic() at panic+0x43/frame 0xfffffe0030ca45d0 fuse_vnop_open() at fuse_vnop_open+0xdf/frame 0xfffffe0030ca4610 VOP_OPEN_APV() at VOP_OPEN_APV+0x60/frame 0xfffffe0030ca4630 vn_open_vnode() at vn_open_vnode+0x1b1/frame 0xfffffe0030ca46d0 vn_open_cred() at vn_open_cred+0x34c/frame 0xfffffe0030ca4820 kern_openat() at kern_openat+0x1fd/frame 0xfffffe0030ca4990 amd64_syscall() at amd64_syscall+0x276/frame 0xfffffe0030ca4ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0030ca4ab0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x8005bc40a, rsp = 0x7fffffffe588, rbp = 0x7fffffffe600 ---
I honestly didn't know O_EXEC existed. What can an O_EXEC fd be used for? I guess just fexecve()? Probably used mostly by capsicum sandboxes? How do you think it should map into FUSE semantics? (Maybe we should just check for and reject the open?)
Looks like this trivial patch should at least fix the panic without loss of existing functionality: --- a/sys/fs/fuse/fuse_vnops.c +++ b/sys/fs/fuse/fuse_vnops.c @@ -1174,6 +1174,9 @@ fuse_vnop_open(struct vop_open_args *ap) if (fuse_isdeadfs(vp)) { return ENXIO; } + if ((mode & (FREAD | FWRITE)) == 0) + return EINVAL; + fvdat = VTOFUD(vp); if (vnode_isdir(vp)) {
(In reply to Conrad Meyer from comment #1) I think we should pass O_EXEC to FUSE_OPEN. Nothing in the FUSE documentation says that the open flags should be limited to O_RDONLY, O_RDWR, and O_WRONLY. Indeed, it suggests the opposite. It says that O_CREAT, O_EXCL, and O_NOCTTY will _not_ be present, but it is silent about the rest. It sounds like we should probably be passing O_APPEND through, too, but that may not matter at our current protocol level.
Hm, ok. That will really complicate how we track FUSE filehandles per vnode today. Is there a complete list of valid modes? This is something I'd expect a protocol to define. Do userspace filesystems (or libfuse) use Linux mode constants (either by specification or accident)? Or do they use host-native constants to decode the FUSE_OPEN flags? It would probably simplify our FUSE implementation to install our own fileops vector in fuse_vnop_open, like devfs_open. We can track the FUSE filehandle and mode on the file object. Either way, there is a straightforward fix for the trivially induced panic we should go ahead and commit. I haven't done it because you've assigned this bug to yourself; let me know if you want to do it, or I can. Thanks!
(In reply to Conrad Meyer from comment #4) Sadly there's no list of which open flags a fuse filesystem might expect. I think the answer is "whatever Linux might throw at it". Definitely O_APPEND and O_TRUNC are to be expected, at least for some protocol versions and mount options. The example programs also try to handle O_NOFOLLOW. I haven't seen any Linux constants hard-coded; AFAICT the code uses the usual host-native versions everywhere. I think we should probably pass all of the open flags to FUSE_OPEN. Currently, we don't filter any out from VOP_OPEN. I'd like to check what Linux does; it may be passing them all, too. The panic fix looks ok, but it's not a permanent solution. You can commit it if you like (and consider it as reviewed by me), but I wouldn't MFC it until we have a complete fix.
(In reply to Alan Somers from comment #5) > The panic fix looks ok, but it's not a permanent solution. Right. > You can commit > it if you like (and consider it as reviewed by me), but I wouldn't MFC it > until we have a complete fix. Sure, will do.
A commit references this bug: Author: cem Date: Wed Mar 6 22:56:49 UTC 2019 New revision: 344857 URL: https://svnweb.freebsd.org/changeset/base/344857 Log: FUSE: Prevent trivial panic When open(2) was invoked against a FUSE filesystem with an unexpected flags value (no O_RDONLY / O_RDWR / O_WRONLY), an assertion fired, causing panic. For now, prevent the panic by rejecting such VOP_OPENs with EINVAL. This is not considered the correct long term fix, but does prevent an unprivileged denial-of-service. PR: 236329 Reported by: asomers Reviewed by: asomers Sponsored by: Dell EMC Isilon Changes: head/sys/fs/fuse/fuse_vnops.c
(In reply to Conrad Meyer from comment #1) FYI the only thing I can find that uses O_EXEC is daemon(3), which uses it with fchdir(2).
The quick and dirty fix is in, but fixing this properly depends on bug 236340.
A commit references this bug: Author: asomers Date: Sun Mar 31 03:19:11 UTC 2019 New revision: 345742 URL: https://svnweb.freebsd.org/changeset/base/345742 Log: fusefs: replace the fufh table with a linked list The FUSE protocol allows each open file descriptor to have a unique file handle. On FreeBSD, these file handles must all be stored in the vnode. The old method (also used by OSX and OpenBSD) is to store them all in a small array. But that limits the total number that can be stored. This commit replaces the array with a linked list (a technique also used by Illumos). There is not yet any change in functionality, but this is the first step to fixing several bugs. PR: 236329, 236340, 236381, 236560, 236844 Discussed with: cem Sponsored by: The FreeBSD Foundation Changes: projects/fuse2/sys/fs/fuse/fuse_file.c projects/fuse2/sys/fs/fuse/fuse_file.h projects/fuse2/sys/fs/fuse/fuse_internal.c projects/fuse2/sys/fs/fuse/fuse_node.c projects/fuse2/sys/fs/fuse/fuse_node.h projects/fuse2/sys/fs/fuse/fuse_vnops.c
A commit references this bug: Author: asomers Date: Mon Apr 1 16:36:05 UTC 2019 New revision: 345768 URL: https://svnweb.freebsd.org/changeset/base/345768 Log: fusefs: allow opening files O_EXEC O_EXEC is useful for fexecve(2) and fchdir(2). Treat it as another fufh type alongside the existing RDONLY, WRONLY, and RDWR. Prior to r345742 this would've caused a memory and performance penalty. PR: 236329 Sponsored by: The FreeBSD Foundation Changes: projects/fuse2/sys/fs/fuse/fuse_file.c projects/fuse2/sys/fs/fuse/fuse_file.h projects/fuse2/sys/fs/fuse/fuse_vnops.c projects/fuse2/tests/sys/fs/fusefs/mockfs.cc projects/fuse2/tests/sys/fs/fusefs/open.cc projects/fuse2/tests/sys/fs/fusefs/opendir.cc projects/fuse2/tests/sys/fs/fusefs/readdir.cc projects/fuse2/tests/sys/fs/fusefs/releasedir.cc projects/fuse2/tests/sys/fs/fusefs/utils.cc
A commit references this bug: Author: asomers Date: Wed Aug 7 00:38:29 UTC 2019 New revision: 350665 URL: https://svnweb.freebsd.org/changeset/base/350665 Log: fusefs: merge from projects/fuse2 This commit imports the new fusefs driver. It raises the protocol level from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and adds many new features. New features include: * Optional kernel-side permissions checks (-o default_permissions) * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK * Allow interrupting FUSE operations * Support named pipes and unix-domain sockets in fusefs file systems * Forward UTIME_NOW during utimensat(2) to the daemon * kqueue support for /dev/fuse * Allow updating mounts with "mount -u" * Allow exporting fusefs file systems over NFS * Server-initiated invalidation of the name cache or data cache * Respect RLIMIT_FSIZE * Try to support servers as old as protocol 7.4 Performance enhancements include: * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags * Cache file attributes * Cache lookup entries, both positive and negative * Server-selectable cache modes: writethrough, writeback, or uncached * Write clustering * Readahead * Use counter(9) for statistical reporting PR: 199934 216391 233783 234581 235773 235774 235775 PR: 236226 236231 236236 236291 236329 236381 236405 PR: 236327 236466 236472 236473 236474 236530 236557 PR: 236560 236844 237052 237181 237588 238565 Reviewed by: bcr (man pages) Reviewed by: cem, ngie, rpokala, glebius, kib, bde, emaste (post-commit review on project branch) MFC after: 3 weeks Relnotes: yes Sponsored by: The FreeBSD Foundation Pull Request: https://reviews.freebsd.org/D21110 Changes: _U head/ head/MAINTAINERS head/UPDATING head/etc/mtree/BSD.tests.dist head/sbin/mount_fusefs/mount_fusefs.8 head/sbin/mount_fusefs/mount_fusefs.c head/share/man/man5/fusefs.5 head/sys/fs/fuse/fuse.h head/sys/fs/fuse/fuse_device.c head/sys/fs/fuse/fuse_file.c head/sys/fs/fuse/fuse_file.h head/sys/fs/fuse/fuse_internal.c head/sys/fs/fuse/fuse_internal.h head/sys/fs/fuse/fuse_io.c head/sys/fs/fuse/fuse_io.h head/sys/fs/fuse/fuse_ipc.c head/sys/fs/fuse/fuse_ipc.h head/sys/fs/fuse/fuse_kernel.h head/sys/fs/fuse/fuse_main.c head/sys/fs/fuse/fuse_node.c head/sys/fs/fuse/fuse_node.h head/sys/fs/fuse/fuse_param.h head/sys/fs/fuse/fuse_vfsops.c head/sys/fs/fuse/fuse_vnops.c head/sys/sys/param.h head/tests/sys/fs/Makefile head/tests/sys/fs/fusefs/
A commit references this bug: Author: asomers Date: Fri Sep 6 17:56:27 UTC 2019 New revision: 351943 URL: https://svnweb.freebsd.org/changeset/base/351943 Log: MFC r344183-r344187, r344333-r344334, r344407, r344857, r344865 (by cem) r344183: FUSE: Respect userspace FS "do-not-cache" of file attributes The FUSE protocol demands that kernel implementations cache user filesystem file attributes (vattr data) for a maximum period of time in the range of [0, ULONG_MAX] seconds. In practice, typical requests are for 0, 1, or 10 seconds; or "a long time" to represent indefinite caching. Historically, FreeBSD FUSE has ignored this client directive entirely. This works fine for local-only filesystems, but causes consistency issues with multi-writer network filesystems. For now, respect 0 second cache TTLs and do not cache such metadata. Non-zero metadata caching TTLs in the range [0.000000001, ULONG_MAX] seconds are still cached indefinitely, because it is unclear how a userspace filesystem could do anything sensible with those semantics even if implemented. In the future, as an optimization, we should implement notify_inval_entry, etc, which provide userspace filesystems a way of evicting the kernel cache. One potentially bogus access to invalid cached attribute data was left in fuse_io_strategy. It is restricted behind the undocumented and non-default "vfs.fuse.fix_broken_io" sysctl or "brokenio" mount option; maybe these are deadcode and can be eliminated? Some minor APIs changed to facilitate this: 1. Attribute cache validity is tracked in FUSE inodes ("fuse_vnode_data"). 2. cache_attrs() respects the provided TTL and only caches in the FUSE inode if TTL > 0. It also grows an "out" argument, which, if non-NULL, stores the translated fuse_attr (even if not suitable for caching). 3. FUSE VTOVA(vp) returns NULL if the vnode's cache is invalid, to help avoid programming mistakes. 4. A VOP_LINK check for potential nlink overflow prior to invoking the FUSE link op was weakened (only performed when we have a valid attr cache). The check is racy in a multi-writer network filesystem anyway -- classic TOCTOU. We have to trust any userspace filesystem that rejects local caching to account for it correctly. PR: 230258 (inspired by; does not fix) r344184: FUSE: Respect userspace FS "do-not-cache" of path components The FUSE protocol demands that kernel implementations cache user filesystem path components (lookup/cnp data) for a maximum period of time in the range of [0, ULONG_MAX] seconds. In practice, typical requests are for 0, 1, or 10 seconds; or "a long time" to represent indefinite caching. Historically, FreeBSD FUSE has ignored this client directive entirely. This works fine for local-only filesystems, but causes consistency issues with multi-writer network filesystems. For now, respect 0 second cache TTLs and do not cache such metadata. Non-zero metadata caching TTLs in the range [0.000000001, ULONG_MAX] seconds are still cached indefinitely, because it is unclear how a userspace filesystem could do anything sensible with those semantics even if implemented. Pass fuse_entry_out to fuse_vnode_get when available and only cache lookup if the user filesystem did not set a zero second TTL. PR: 230258 (inspired by; does not fix) r344185: FUSE: Only "dirty" cached file size when data is dirty Most users of fuse_vnode_setsize() set the cached fvdat->filesize and update the buf cache bounds as a result of either a read from the underlying FUSE filesystem, or as part of a write-through type operation (like truncate => VOP_SETATTR). In these cases, do not set the FN_SIZECHANGE flag, which indicates that an inode's data is dirty (in particular, that the local buf cache and fvdat->filesize have dirty extended data). PR: 230258 (related) r344186: FUSE: The FUSE design expects writethrough caching At least prior to 7.23 (which adds FUSE_WRITEBACK_CACHE), the FUSE protocol specifies only clean data to be cached. Prior to this change, we implement and default to writeback caching. This is ok enough for local only filesystems without hardlinks, but violates the general design contract with FUSE and breaks distributed filesystems or concurrent access to hardlinks of the same inode. In this change, add cache mode as an extension of cache enable/disable. The new modes are UC (was: cache disabled), WT (default), and WB (was: cache enabled). For now, WT caching is implemented as write-around, which meets the goal of only caching clean data. WT can be better than WA for workloads that frequently read data that was recently written, but WA is trivial to implement. Note that this has no effect on O_WRONLY-opened files, which were already coerced to write-around. Refs: * https://sourceforge.net/p/fuse/mailman/message/8902254/ * https://github.com/vgough/encfs/issues/315 PR: 230258 (inspired by) r344187: FUSE: Refresh cached file size when it changes (lookup) The cached fvdat->filesize is indepedent of the (mostly unused) cached_attrs, and we failed to update it when a cached (but perhaps inactive) vnode was found during VOP_LOOKUP to have a different size than cached. As noted in the code comment, this can occur in distributed filesystems or with other kinds of irregular file behavior (anything is possible in FUSE). We do something similar in fuse_vnop_getattr already. PR: 230258 (as reported in description; other issues explored in comments are not all resolved) Reported by: MooseFS FreeBSD Team <freebsd AT moosefs.com> Submitted by: Jakub Kruszona-Zawadzki <acid AT moosefs.com> (earlier version) r344333: fuse: add descriptions for remaining sysctls (Except reclaim revoked; I don't know what that goal of that one is.) r344334: Fuse: whitespace and style(9) cleanup Take a pass through fixing some of the most egregious whitespace issues in fs/fuse. Also fix some style(9) warts while here. Not 100% cleaned up, but somewhat less painful to look at and edit. No functional change. r344407: fuse: Fix a regression introduced in r337165 On systems with non-default DFLTPHYS and/or MAXBSIZE, FUSE would attempt to use a buf cache block size in excess of permitted size. This did not affect most configurations, since DFLTPHYS and MAXBSIZE both default to 64kB. The issue was discovered and reported using a custom kernel with a DFLTPHYS of 512kB. PR: 230260 (comment #9) Reported by: ken@ r344857: FUSE: Prevent trivial panic When open(2) was invoked against a FUSE filesystem with an unexpected flags value (no O_RDONLY / O_RDWR / O_WRONLY), an assertion fired, causing panic. For now, prevent the panic by rejecting such VOP_OPENs with EINVAL. This is not considered the correct long term fix, but does prevent an unprivileged denial-of-service. PR: 236329 Reported by: asomers Reviewed by: asomers Sponsored by: Dell EMC Isilon r344865: fuse: switch from DFLTPHYS/MAXBSIZE to maxcachebuf On GENERIC kernels with empty loader.conf, there is no functional change. DFLTPHYS and MAXBSIZE are both 64kB at the moment. This change allows larger bufcache block sizes to be used when either MAXBSIZE (custom kernel) or the loader.conf tunable vfs.maxbcachebuf (GENERIC) is adjusted higher than the default. Suggested by: ken@ Changes: _U stable/12/ stable/12/sys/fs/fuse/fuse.h stable/12/sys/fs/fuse/fuse_device.c stable/12/sys/fs/fuse/fuse_file.c stable/12/sys/fs/fuse/fuse_file.h stable/12/sys/fs/fuse/fuse_internal.c stable/12/sys/fs/fuse/fuse_internal.h stable/12/sys/fs/fuse/fuse_io.c stable/12/sys/fs/fuse/fuse_ipc.c stable/12/sys/fs/fuse/fuse_ipc.h stable/12/sys/fs/fuse/fuse_node.c stable/12/sys/fs/fuse/fuse_node.h stable/12/sys/fs/fuse/fuse_vfsops.c stable/12/sys/fs/fuse/fuse_vnops.c
I'm not going to MFC to 11 since no new releases are planned for that branch.
A commit references this bug: Author: asomers Date: Sun Sep 15 04:14:34 UTC 2019 New revision: 352351 URL: https://svnweb.freebsd.org/changeset/base/352351 Log: MFC the new fusefs driver MFC r350665, r350990, r350992, r351039, r351042, r351061, r351066, r351113, r351560, r351961, r351963, r352021, r352025, r352230 r350665: fusefs: merge from projects/fuse2 This commit imports the new fusefs driver. It raises the protocol level from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and adds many new features. New features include: * Optional kernel-side permissions checks (-o default_permissions) * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK * Allow interrupting FUSE operations * Support named pipes and unix-domain sockets in fusefs file systems * Forward UTIME_NOW during utimensat(2) to the daemon * kqueue support for /dev/fuse * Allow updating mounts with "mount -u" * Allow exporting fusefs file systems over NFS * Server-initiated invalidation of the name cache or data cache * Respect RLIMIT_FSIZE * Try to support servers as old as protocol 7.4 Performance enhancements include: * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags * Cache file attributes * Cache lookup entries, both positive and negative * Server-selectable cache modes: writethrough, writeback, or uncached * Write clustering * Readahead * Use counter(9) for statistical reporting PR: 199934 216391 233783 234581 235773 235774 235775 PR: 236226 236231 236236 236291 236329 236381 236405 PR: 236327 236466 236472 236473 236474 236530 236557 PR: 236560 236844 237052 237181 237588 238565 Reviewed by: bcr (man pages) Reviewed by: cem, ngie, rpokala, glebius, kib, bde, emaste (post-commit review on project branch) Relnotes: yes Sponsored by: The FreeBSD Foundation Pull Request: https://reviews.freebsd.org/D21110 r350990: fusefs: add SVN Keywords to the test files Reported by: SVN pre-commit hooks MFC-With: r350665 Sponsored by: The FreeBSD Foundation r350992: fusefs: skip some tests when unsafe aio is disabled MFC-With: r350665 Sponsored by: The FreeBSD Foundation r351039: fusefs: fix intermittency in the default_permissions.Unlink.ok test The test needs to expect a FUSE_FORGET operation. Most of the time the test would pass anyway, because by chance FUSE_FORGET would arrive after the unmount. MFC-With: 350665 Sponsored by: The FreeBSD Foundation r351042: fusefs: Fix the size of fuse_getattr_in In FUSE protocol 7.9, the size of the FUSE_GETATTR request has increased. However, the fusefs driver is currently not sending the additional fields. In our implementation, the additional fields are always zero, so I there haven't been any test failures until now. But fusefs-lkl requires the request's length to be correct. Fix this bug, and also enhance the test suite to catch similar bugs. PR: 239830 MFC-With: 350665 Sponsored by: The FreeBSD Foundation r351061: fusefs: fix the 32-bit build after 351042 Reported by: jhb MFC-With: 351042 Sponsored by: The FreeBSD Foundation r351066: fusefs: fix conditional from r351061 The entirety of r351061 was a copy/paste error. I'm sorry I've been comitting so hastily. Reported by: rpokala Reviewed by: rpokala MFC-With: 351061 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21265 r351113: fusefs: don't send the namespace during listextattr The FUSE_LISTXATTR operation always returns the full list of a file's extended attributes, in all namespaces. There's no way to filter the list server-side. However, currently FreeBSD's fusefs driver sends a namespace string with the FUSE_LISTXATTR request. That behavior was probably copied from fuse_vnop_getextattr, which has an attribute name argument. It's been there ever since extended attribute support was added in r324620. This commit removes it. Reviewed by: cem Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21280 r351560: fusefs: Fix some bugs regarding the size of the LISTXATTR list * A small error in r338152 let to the returned size always being exactly eight bytes too large. * The FUSE_LISTXATTR operation works like Linux's listxattr(2): if the caller does not provide enough space, then the server should return ERANGE rather than return a truncated list. That's true even though in FUSE's case the kernel doesn't provide space to the client at all; it simply requests a maximum size for the list. We previously weren't handling the case where the server returns ERANGE even though the kernel requested as much size as the server had told us it needs; that can happen due to a race. * We also need to ensure that a pathological server that always returns ERANGE no matter what size we request in FUSE_LISTXATTR won't cause an infinite loop in the kernel. As of this commit, it will instead cause an infinite loop that exits and enters the kernel on each iteration, allowing signals to be processed. Reviewed by: cem Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21287 r351961: Coverity fixes in fusefs(5) CID 1404532 fixes a signed vs unsigned comparison error in fuse_vnop_bmap. It could potentially have resulted in VOP_BMAP reporting too many consecutive blocks. CID 1404364 is much worse. It was an array access by an untrusted, user-provided variable. It could potentially have resulted in a malicious file system crashing the kernel or worse. Reported by: Coverity Reviewed by: emaste Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21466 r351963: fusefs: coverity cleanup in the tests Address the following defects reported by Coverity: * Structurally dead code (CID 1404366): set m_quit before FAIL, not after * Unchecked return value of sysctlbyname (CID 1404321) * Unchecked return value of stat(2) (CID 1404471) * Unchecked return value of open(2) (CID 1404402, 1404529) * Unchecked return value of dup(2) (CID 1404478) * Buffer overflows. These are all false positives caused by the fact that Coverity thinks I'm using a buffer to store strings, when in fact I'm really just using it to store a byte array that happens to be initialized with a string. I'm changing the type from char to uint8_t in the hopes that it will placate Coverity. (CID 1404338, 1404350, 1404367, 1404376, 1404379, 1404381, 1404388, 1404403, 1404425, 1404433, 1404434, 1404474, 1404480, 1404484, 1404503, 1404505) * False positive file descriptor leak. I'm going to try to fix this with Coverity modeling, but I'll also change an EXPECT to ASSERT so we don't perform meaningless assertions after the failure. (CID 1404320, 1404324, 1404440, 1404445). * Unannotated file descriptor leak. This will be followed up by a Coverity modeling change. (CID 1404326, 1404334, 1404336, 1404357, 1404361, 1404372, 1404391, 1404395, 1404409, 1404430, 1404448, 1404451, 1404455, 1404457, 1404458, 1404460) * Uninitialized variables in C++ constructors (CID 1404327, 1404346). In the case of m_maxphys, this actually led to part of the FUSE_INIT's response being set to stack garbage during the WriteCluster::clustering test. * Uninitialized sun_len field in struct sockaddr_un (CID 1404330, 1404371, 1404429). Reported by: Coverity Reviewed by: emaste Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21457 r352021: fusefs: suppress some Coverity resource leak CIDs in the tests The fusefs tests deliberately leak file descriptors. To do otherwise would add extra complications to the tests' mock FUSE server. This annotation should hopefully convince Coverity to shut up about the leaks. Reviewed by: uqs Sponsored by: The FreeBSD Foundation r352025: mount_fusefs: fix a segfault on memory allocation failure Reported by: Coverity Coverity CID: 1354188 Sponsored by: The FreeBSD Foundation r352230: fusefs: Fix iosize for FUSE_WRITE in 7.8 compat mode When communicating with a FUSE server that implements version 7.8 (or older) of the FUSE protocol, the FUSE_WRITE request structure is 16 bytes shorter than normal. The protocol version check wasn't applied universally, leading to an extra 16 bytes being sent to such servers. The extra bytes were allocated and bzero()d, so there was no information disclosure. Reviewed by: emaste MFC-With: r350665 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21557 Changes: _U stable/12/ stable/12/MAINTAINERS stable/12/UPDATING stable/12/etc/mtree/BSD.tests.dist stable/12/sbin/mount_fusefs/mount_fusefs.8 stable/12/sbin/mount_fusefs/mount_fusefs.c stable/12/share/man/man5/fusefs.5 stable/12/sys/fs/fuse/fuse.h stable/12/sys/fs/fuse/fuse_device.c stable/12/sys/fs/fuse/fuse_file.c stable/12/sys/fs/fuse/fuse_file.h stable/12/sys/fs/fuse/fuse_internal.c stable/12/sys/fs/fuse/fuse_internal.h stable/12/sys/fs/fuse/fuse_io.c stable/12/sys/fs/fuse/fuse_io.h stable/12/sys/fs/fuse/fuse_ipc.c stable/12/sys/fs/fuse/fuse_ipc.h stable/12/sys/fs/fuse/fuse_kernel.h stable/12/sys/fs/fuse/fuse_main.c stable/12/sys/fs/fuse/fuse_node.c stable/12/sys/fs/fuse/fuse_node.h stable/12/sys/fs/fuse/fuse_param.h stable/12/sys/fs/fuse/fuse_vfsops.c stable/12/sys/fs/fuse/fuse_vnops.c stable/12/sys/sys/param.h stable/12/tests/sys/fs/Makefile stable/12/tests/sys/fs/fusefs/ stable/12/tests/sys/fs/fusefs/access.cc stable/12/tests/sys/fs/fusefs/allow_other.cc stable/12/tests/sys/fs/fusefs/bmap.cc stable/12/tests/sys/fs/fusefs/create.cc stable/12/tests/sys/fs/fusefs/default_permissions.cc stable/12/tests/sys/fs/fusefs/default_permissions_privileged.cc stable/12/tests/sys/fs/fusefs/destroy.cc stable/12/tests/sys/fs/fusefs/dev_fuse_poll.cc stable/12/tests/sys/fs/fusefs/fifo.cc stable/12/tests/sys/fs/fusefs/flush.cc stable/12/tests/sys/fs/fusefs/forget.cc stable/12/tests/sys/fs/fusefs/fsync.cc stable/12/tests/sys/fs/fusefs/fsyncdir.cc stable/12/tests/sys/fs/fusefs/getattr.cc stable/12/tests/sys/fs/fusefs/interrupt.cc stable/12/tests/sys/fs/fusefs/io.cc stable/12/tests/sys/fs/fusefs/link.cc stable/12/tests/sys/fs/fusefs/locks.cc stable/12/tests/sys/fs/fusefs/lookup.cc stable/12/tests/sys/fs/fusefs/mkdir.cc stable/12/tests/sys/fs/fusefs/mknod.cc stable/12/tests/sys/fs/fusefs/mockfs.cc stable/12/tests/sys/fs/fusefs/mockfs.hh stable/12/tests/sys/fs/fusefs/mount.cc stable/12/tests/sys/fs/fusefs/nfs.cc stable/12/tests/sys/fs/fusefs/notify.cc stable/12/tests/sys/fs/fusefs/open.cc stable/12/tests/sys/fs/fusefs/opendir.cc stable/12/tests/sys/fs/fusefs/read.cc stable/12/tests/sys/fs/fusefs/readdir.cc stable/12/tests/sys/fs/fusefs/readlink.cc stable/12/tests/sys/fs/fusefs/release.cc stable/12/tests/sys/fs/fusefs/releasedir.cc stable/12/tests/sys/fs/fusefs/rename.cc stable/12/tests/sys/fs/fusefs/rmdir.cc stable/12/tests/sys/fs/fusefs/setattr.cc stable/12/tests/sys/fs/fusefs/statfs.cc stable/12/tests/sys/fs/fusefs/symlink.cc stable/12/tests/sys/fs/fusefs/unlink.cc stable/12/tests/sys/fs/fusefs/utils.cc stable/12/tests/sys/fs/fusefs/utils.hh stable/12/tests/sys/fs/fusefs/write.cc stable/12/tests/sys/fs/fusefs/xattr.cc