src/sys/fs, branch main

fusefs: Handle buggy servers' LISTXATTR response

2026-05-20T19:34:50Z

The fuse protocol requires server to respond to LISTXATTR with a NUL-terminated string. If they don't, report an error rather than attempt to scan through uninitialized memory for a NUL. Approved by: so Security: FreeBSD-SA-26:20.fusefs Security: CVE-2026-45252 admbugs: 1039 Reported by: Joshua Rogers Sponsored by: ConnectWise

tmpfs: Overhaul option handling on remount

2026-05-19T06:54:28Z

On remount, we must accept all the same options as on initial mount. For parameters which we're unable to modify on the fly, fail only if the new value is different from the existing one. PR: 295096 MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D57044

nullfs: do not allow to mount a vnode over itself

2026-05-17T19:44:06Z

This causes recursion in VFS that is not worth handling. PR: 275570 Reported by: Alex S Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D57043

nfsd: Allow vfs.nfsd.srvmaxio to be up to 4Mbytes

2026-05-14T22:33:23Z

Without this patch, the maximum setting for vfs.nfsd.srvmaxio was 1Mbyte. This patch increases that to 4Mbytes. The same as for any setting above 128Kbytes, settings up to 4Mbytes require that kern.ipc.maxsockbuf be increased. (A message generated after setting vfs.nfsd.srvmaxio via the /etc/rc.conf variable nfs_server_maxio will indicate the minimum setting, which will be somewhat greater than four times the setting of vfs.nfsd.srvmaxio.) Requested by: Cedric Blancher MFC after: 2 weeks Fixes: 13d3bd165e22 ("subr_uio.c: Remove a KASSERT() for large NFS server I/O")

p9fs: Fix creating files with restrictive permissions

2026-05-07T04:23:28Z

When a file is created via p9fs with restrictive permissions (like 000), the 9P TCREATE request successfully creates and natively opens the file, returning an open, writable file descriptor. Previously, p9fs would attempt a subsequent TOPEN. That TOPEN would fail with EACCES due to the restrictive mode, leaving a 0-byte file and causing operations like 'mv' to abort. We now preserve the writable descriptor returned by TCREATE so that the subsequent VOP_OPEN can use it directly, avoiding the failing TOPEN. Additionally, p9fs_compatible_mode now appropriately isolates the base access intent when matching fids, preventing extended flags from breaking the match. A test case for this behavior has been submitted to pjdfstest: https://github.com/pjd/pjdfstest/pull/87 Resolves: https://github.com/CTSRD-CHERI/cheribsd/issues/2617 Reviewed by: markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D56494

p9fs: implement basic pathconf support

2026-05-07T04:23:04Z

This is needed for various pjdfstest tests which fail with syntax errors if pathconf _PC_NAME_MAX/_PC_PATH_MAX return -1. For NAME_MAX we can use the 9P2000.L Tstatfs call to get namelen from the host. While this could theoretically be different for nested filesystems in the shared mount it is a much better guess than just returning 255. There does not seem to be a way to get the host PATH_MAX, so we just return the conservative kernel default. Found while fixing https://github.com/CTSRD-CHERI/cheribsd/issues/2617. Reviewed by: markj, kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D56493

p9fs: Move UMA zone initialization to VFS module lifecycle

2026-05-07T04:23:04Z

Previously, the UMA zones required for 9P requests (p9fs_buf_zone, p9fs_req_zone, etc.) were initialized and destroyed in the virtio_p9fs transport module. This caused issues when unloading the core p9fs module. This change moves p9_init_zones() and p9_destroy_zones() into p9fs_init() and p9fs_uninit() inside p9fs_vfsops.c so that they are correctly bound to the VFS filesystem module lifecycle via vfs_modevent, aligning p9fs with standard FreeBSD VFS semantics. Found while fixing https://github.com/CTSRD-CHERI/cheribsd/issues/2617. Reviewed by: kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D56492

nfs_clsubs.c: Fix ncl_getcookie() when "pos" is negative

2026-05-06T14:54:55Z

In ncl_getcookie(), a very large value for "off" for a directory can result in "pos" being set to a bogus value (including a negative one), due to truncation. When "pos" is negative, is can skip past the while (pos >= NFSNUMCOOKIES) loop and return a bogus pointer instead of NULL. This patch changes the type to u_int and also adds a sanity check for a very large "off" to ensure that a NULL pointer is returned for this case. This bug has been in the code for decades and I am not aware of any report of it causing a problem for users. Reviewed by: markj Reported by: Joshua Rogers of AISLE Research Team MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D56779

nfs_nfsdserv.c: Clip number of callback slots

2026-05-05T00:04:00Z

The client tells the server how many callback slots it can handle in the callback session. However, the NFSv4.1/4.2 server can only handle a maximum of NFSV4_SLOTS slots. This patch clips the client's value to that, to avoid using too high a slot# for a callback. Fortunately, I do not know of an extant client that specifies a value greater than NFSV4_SLOTS, so this patch is not really needed, as yet. Also, the client rarely uses a slot# above 0 when doing callbacks. MFC after: 2 weeks

nfsd: Disable use of callbacks for NFSv4.0

2026-05-03T23:25:45Z

Commit 71ac1ec5c9d9 disabled callbacks for the NFS client for NFSv4.0. This patch does the same for the NFSv4.0 server. The only use for callbacks for NFSv4.0 is delegations and delegations rarely work well for NFSv4.0 anyhow. Therefore, this patch disables callbacks for the NFSv4.0 server. This is the same behavior as occurs when vfs.nfsd.issue_delegations is 0. This change allowed the functions called nfsrv_getclientipaddr() and nfsrv_getipnumber() to be removed from the kernel. MFC after: 2 weeks