fusefs: redo vnode attribute locking
Previously most fields in fuse_vnode_data were protected by the vnode
lock. But because DEBUG_VFS_LOCKS was never enabled by default until
stable/15 the assertions were never checked, and many were wrong.
Others were missing. This led to panics in stable/15 and 16.0-CURRENT,
when a vnode was expected to be exclusively locked but wasn't, for fuse
file systems that mount with "-o async".
In some places it isn't possible to exclusively lock the vnode when
accessing these fields. So protect them with a new mutex instead. This
fixes panics and unprotected field accesses in VOP_READ,
VOP_COPY_FILE_RANGE, VOP_GETATTR, VOP_BMAP, and FUSE_NOTIFY_INVAL_ENTRY.
Add assertions everywhere the protected fields are accessed.
Lock the vnode exclusively when handling FUSE_NOTIFY_INVAL_INODE.
During fuse_vnode_setsize, if the vnode isn't already exclusively
locked, use the vn_delayed_setsize mechanism. This fixes panics during
[14 lines not shown]
fusefs: add a regression test for a cluster_read bug
VOP_BMAP is purely advisory. If VOP_BMAP returns an error during
readahead, cluster_read should still succeed, because the actual data
was still read just fine.
Add a regression test for PR 264196, wherein cluster_read would fail if
VOP_BMAP did.
PR: 264196
Reported by: danfe
Reviewed by: arrowd
Differential Revision: https://reviews.freebsd.org/D51316
(cherry picked from commit 6d408ac490730614b3ed0ebd3caffcd23f303fb4)
vfs_cluster.c: Do not propagate VOP_BMAP errors to the caller
The code that makes this VOP_BMAP call tries to perform a read-ahead I/O
operation. Failing to do that for any reason isn't fatal for `cluster_read()`,
because we still can return some data to the caller. This change is consistent
with other places within `cluster_read()`, where error returned by VOP_BMAP is
not returned to the caller - see the `if (nblks > 1)` block above the changed
lines and `if (reqbp)` at the end of the function.
PR: 264196
Approved by: markj, kib
Differential Revision: https://reviews.freebsd.org/D51254
(cherry picked from commit 62aef3f73f38db9fb68bffc12cc8900fecd58f0e)
fusefs: remove the obsolete rename_lock
This lock was included in the original GSoC submission. Its purpose
seems to have been to prevent concurrent FUSE_RENAME operations for the
current mountpoint, as well as to synchronize FUSE_RENAME with
fuse_vnode_setparent. But it's obsolete, now that ef6ea91593e added
mnt_renamelock .
Sponsored by: ConnectWise
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D55231
(cherry picked from commit 7755a406a6ae3801e885a79f714155f97c4d2bc6)
aio(4) tests: do not rely on (int *)-1 being invalid address
Explicitly mmap guard and use it as the invalid address instead.
(cherry picked from commit dc9a8d300ba5c4c319589d78231e9d0e76576cbf)
tests: sys/capsicum/functional requires mqueuefs
Skip this test if mqueuefs isn't loaded. Unfortunately, that will skip
the entire googletest test program, including test cases that don't
require mqueuefs. But the test's own skipping logic doesn't work, and
we don't yet have a googletest-compatible require_kmods() function.
Sponsored by: ConnectWise
Reviewed by: emaste, ngie
Differential Revision: https://reviews.freebsd.org/D54902
(cherry picked from commit df68a09ea2ec18ee975fb937d46a18250d4663c8)
manuals: System message vs kernel message
Wordsmith mentions throughout the manual of syslog and dmesg, to clearly
differentiate them in an externally consisteny way, increasing operator
onboarding speed and elegance.
The daemon that handles general system messages, syslog, describes them
as "system messages", and "messages" is the standard filename. Rewrite
syslog related manual titles to align search results with this, and hier
entries to align the index. Use care to maintain keywords and not add
extra lines. Newsyslog trades "maintain" with "rotate" for visibility.
MFC after: 3 days
Reviewed by: markj
Closes: https://github.com/freebsd/freebsd-src/pull/2067
kldload.2: Provide more info about file argument
The information is basically taken from kldload(8).
Reviewed by: kib, ziaee
Differential Revision: https://reviews.freebsd.org/D55170
libc/amd64/strrchr.S: fix rebase error
I accidentally dropped a part of the patch on squash rebase.
Should be fine now.
Fixes: 253f15c016ca699906f78b8e522a3f7ed675929b
PR: 293915
MFC after: 1 week
libc/amd64/strrchr.S: rewrite and fix scalar implementation
The original scalar implementation of strrchr() had incorrect
logic that failed if the character searched for was the NUL
character. It was also possibly affected by the issue fixed
in 3d8ef251a for strchrnul().
Rewrite the function with logic that actually works. We defer
checking for the character until after we have checked for NUL.
When we encounter the final NUL byte, we mask out the characters
beyond the tail before checking for a match.
This bug only affects users running on amd64 with ARCHLEVEL=scalar
(cf. simd(7)). The default configuration is not affected.
The bug was unfortunately not caught by the unit test inherited
from NetBSD. An extended unit test catching the issue is proposed
in D56037.
[6 lines not shown]
rtnetlink: Add support for nexthop expiration in new/get route
Before this change, netlink only shows nexthop
expire value if route is not multipath.
Now it can set expire time during route creation.
Also, show expire time of multipath nexthops.
Reviewed by: glebius
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D55442
(cherry picked from commit ff6d1faa65a1a77d04746b43023feb457cfa27b8)
Delete error-check code that can never happen.
Near the top of kern_mmap() that implements the mmap(2) system call,
it sets
prot = PROT_EXTRACT(prot);
with
So prot can only be the three PROT_ flags.
The following test of the user's mmap(2) parameters (near line 275
in vm/vm_mmap.c):
if (prot != PROT_NONE &&
(prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC)) != 0) {
return (EXTERROR(EINVAL, "invalid prot %#jx", prot));
}
[8 lines not shown]
rpcsec_gss: Fix a stack overflow in svc_rpc_gss_validate()
svc_rpc_gss_validate() copies the input message into a stack buffer
without ensuring that the buffer is large enough. Sure enough,
oa_length may be up to 400 bytes, much larger than the provided space.
This enables an unauthenticated user to trigger an overflow and obtain
remote code execution.
Add a runtime check which verifies that the copy won't overflow.
Approved by: so
Security: FreeBSD-SA-26:08.rpcsec_gss
Security: CVE-2026-4747
Reported by: Nicholas Carlini <npc at anthropic.com>
Reviewed by: rmacklem
Fixes: a9148abd9da5d
rpcsec_gss: Fix a stack overflow in svc_rpc_gss_validate()
svc_rpc_gss_validate() copies the input message into a stack buffer
without ensuring that the buffer is large enough. Sure enough,
oa_length may be up to 400 bytes, much larger than the provided space.
This enables an unauthenticated user to trigger an overflow and obtain
remote code execution.
Add a runtime check which verifies that the copy won't overflow.
Approved by: so
Security: FreeBSD-SA-26:08.rpcsec_gss
Security: CVE-2026-4747
Reported by: Nicholas Carlini <npc at anthropic.com>
Reviewed by: rmacklem
Fixes: a9148abd9da5d
(cherry picked from commit 143293c14f8de00c6d3de88cd23fc224e7014206)
rpcsec_gss: Fix a stack overflow in svc_rpc_gss_validate()
svc_rpc_gss_validate() copies the input message into a stack buffer
without ensuring that the buffer is large enough. Sure enough,
oa_length may be up to 400 bytes, much larger than the provided space.
This enables an unauthenticated user to trigger an overflow and obtain
remote code execution.
Add a runtime check which verifies that the copy won't overflow.
Approved by: so
Security: FreeBSD-SA-26:08.rpcsec_gss
Security: CVE-2026-4747
Reported by: Nicholas Carlini <npc at anthropic.com>
Reviewed by: rmacklem
Fixes: a9148abd9da5d
(cherry picked from commit 143293c14f8de00c6d3de88cd23fc224e7014206)
tcp: plug an mbuf leak
When a challenge ACK should be sent via tcp_send_challenge_ack(),
but the rate limiter suppresses the sending, free the mbuf chain.
The caller of tcp_send_challenge_ack() expects this similar to the
callers of tcp_respond().
Approved by: so
Security: FreeBSD-SA-26:06.tcp
Security: CVE-2026-4247
Reviewed by: lstewart
Tested by: lstewart
Sponsored by: Netflix, Inc.
(cherry picked from commit 6b2d6ccad2552e46a5c9c3ba70b2d0ed27c70ca8)
rpcsec_gss: Fix a stack overflow in svc_rpc_gss_validate()
svc_rpc_gss_validate() copies the input message into a stack buffer
without ensuring that the buffer is large enough. Sure enough,
oa_length may be up to 400 bytes, much larger than the provided space.
This enables an unauthenticated user to trigger an overflow and obtain
remote code execution.
Add a runtime check which verifies that the copy won't overflow.
Approved by: so
Security: FreeBSD-SA-26:08.rpcsec_gss
Security: CVE-2026-4747
Reported by: Nicholas Carlini <npc at anthropic.com>
Reviewed by: rmacklem
Fixes: a9148abd9da5d
(cherry picked from commit 143293c14f8de00c6d3de88cd23fc224e7014206)
tcp: plug an mbuf leak
When a challenge ACK should be sent via tcp_send_challenge_ack(),
but the rate limiter suppresses the sending, free the mbuf chain.
The caller of tcp_send_challenge_ack() expects this similar to the
callers of tcp_respond().
Approved by: so
Security: FreeBSD-SA-26:06.tcp
Security: CVE-2026-4247
Reviewed by: lstewart
Tested by: lstewart
Sponsored by: Netflix, Inc.
(cherry picked from commit 6b2d6ccad2552e46a5c9c3ba70b2d0ed27c70ca8)
rpcsec_gss: Fix a stack overflow in svc_rpc_gss_validate()
svc_rpc_gss_validate() copies the input message into a stack buffer
without ensuring that the buffer is large enough. Sure enough,
oa_length may be up to 400 bytes, much larger than the provided space.
This enables an unauthenticated user to trigger an overflow and obtain
remote code execution.
Add a runtime check which verifies that the copy won't overflow.
Approved by: so
Security: FreeBSD-SA-26:08.rpcsec_gss
Security: CVE-2026-4747
Reported by: Nicholas Carlini <npc at anthropic.com>
Reviewed by: rmacklem
Fixes: a9148abd9da5d
tcp: plug an mbuf leak
When a challenge ACK should be sent via tcp_send_challenge_ack(),
but the rate limiter suppresses the sending, free the mbuf chain.
The caller of tcp_send_challenge_ack() expects this similar to the
callers of tcp_respond().
Approved by: so
Security: FreeBSD-SA-26:06.tcp
Security: CVE-2026-4247
Reviewed by: lstewart
Tested by: lstewart
Sponsored by: Netflix, Inc.
