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.
pf tests: verify that we handle address range rules correctly
There's been a problem where rules which differed only in address ranges
were considered duplicates and not added. Test for this.
Approved by: so
Security: FreeBSD-SA-26:09.pf
Security: CVE-2026-4748
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit ab74151e8d097b263237942c0b12277098bc9533)
(cherry picked from commit 958dbc87e9c59a2e9f83d84115ce03fb96e9b249)
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.
ifnet: Fix decreasing the vnet interface count
It should be decreased only when the interface has been successfully
removed from the "active" list.
This prevents vnet_if_return() from potential OOB writes to the
allocated memory "pending".
Reviewed by: kp, pouria
Fixes: a779388f8bb3 if: Protect V_ifnet in vnet_if_return()
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D55873
(cherry picked from commit 8065ff63c0e5c3bb4abb02f55b20cb47bb51d1a7)
(cherry picked from commit 1b7687f053afcf251ee7643ee5a4f22a225f4a02)
LinuxKPI: avoid -Werror=unused-value in sort() from BUILD_BUG_ON_ZERO()
The BUILD_BUG_ON_ZERO() macro returns an (int)0 if it does not fail
at build time. LinuxKPI sort() has it as a guard for an unsupported
argument but ignores the return value.
This leads to gcc complaining:
/usr/src/sys/compat/linuxkpi/common/include/linux/build_bug.h:60:33: error: statement with no effect [-Werror=unused-value]
60 | #define BUILD_BUG_ON_ZERO(x) ((int)sizeof(struct { int:-((x) != 0); }))
| ^
/usr/src/sys/compat/linuxkpi/common/include/linux/sort.h:37:9: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
37 | BUILD_BUG_ON_ZERO(swap); \
| ^~~~~~~~~~~~~~~~~
/usr/src/sys/contrib/dev/rtw89/core.c:2575:9: note: in expansion of macro 'sort'
2575 | sort(drift, RTW89_BCN_TRACK_STAT_NR, sizeof(*drift), cmp_u16, NULL);
Change to BUILD_BUG_ON() for the statement version.
[8 lines not shown]
netinet6: try to guard against known in6_selecthlim() panic
At least for tcp_default_output() it's easy to avoid this. May cause
more panics but we will have to go one by one since the FreeBSD fixes
on main are not compatible/backported.
PR: https://forum.opnsense.org/index.php?topic=51348.0
unix: Set O_RESOLVE_BENEATH on fds transferred between jails
If a pair of jails with different filesystem roots is able to exchange
SCM_RIGHTS messages (e.g., using a unix socket in a shared nullfs
mount), a process in one jail can open a directory outside of the root
of the second jail and then pass the fd to that second jail, allowing
the receiving process to escape the jail chroot.
Address this using the new FD_RESOLVE_BENEATH flag. When externalizing
an SCM_RIGHTS message into the receiving process, automatically set this
flag on all new fds where a jail boundary is crossed. This ensures that
the receiver cannot do more than access files underneath the directory;
in particular, the received fd cannot be used to access vnodes not
accessible by the sender.
Approved by: so
Security: FreeBSD-SA-26:04.jail
Security: CVE-2025-15576
PR: 262179
[6 lines not shown]
file: Add a fd flag with O_RESOLVE_BENEATH semantics
The O_RESOLVE_BENEATH openat(2) flag restricts name lookups such that
they remain under the directory referenced by the dirfd. This commit
introduces an implicit version of the flag, FD_RESOLVE_BENEATH, stored
in the file descriptor entry. When the flag is set, any lookup relative
to that fd automatically has O_RESOLVE_BENEATH semantics. Furthermore,
the flag is sticky, meaning that it cannot be cleared, and it is copied
by dup() and openat().
File descriptors with FD_RESOLVE_BENEATH set may not be passed to
fchdir(2) or fchroot(2). Various fd lookup routines are modified to
return fd flags to the caller.
This flag will be used to address a case where jails with different root
directories and the ability to pass SCM_RIGHTS messages across the jail
boundary can transfer directory fds in such as way as to allow a
filesystem escape.
[8 lines not shown]
file: Qualify pointers to capsicum rights as const
File descriptor lookup routines typically take a set of capsicum rights
as input to the lookup, so that the fd's rights can be atomically
checked. This set should be qualified with const.
No functional change intended.
Approved by: so
Reviewed by: olce, oshogbo, brooks, kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D50419
(cherry picked from commit 5319cb21610ad947c56fd0cd4f18ef5b58bc8db7)
(cherry picked from commit 2060337c0937f08d9960d629eb59ce737339640c)
vnet: Ensure the space allocated by vnet_data_alloc() is sufficent aligned
Some 32-bit architectures, e.g., armv7, require strict 8-byte
alignment while doing atomic 64-bit access. Hence aligning to the
pointer type (4-byte alignment) does not meet the requirement on
those architectures.
Make the space allocated by vnet_data_alloc() sufficent aligned to
avoid unaligned access.
PR: 265639
Diagnosed by: markj
Reviewed by: jhb, markj
Co-authored-by: jhb
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D55560
(cherry picked from commit 32beb3ae71cb320dbe4190a01c036943d99083b3)
(cherry picked from commit 973d607b284ba68e63f0386af44c28bfde15add2)
bsdinstall: fix EFI boot entry creation
update_uefi_bootentry assumes that the caller sets FREEBSD_BOOTNAME and
mntpt, which isn't the case anymore. The result is that there is no
"FreeBSD" boot entry created/updated after install. Most machines manage
to boot from the removable media path (if the loader is installed there
too), but some don't.
Take the loader's path as an argument and rename the variable used in
the ZFS mirror loop so mntpt can be reused below.
Also mark nentries as a local variable so it doesn't leak out of the
function.
PR: 293385
Fixes: 494de51bc0074472d1b01604f085daea0844f240
MFC after: 2 days
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D55469
[2 lines not shown]
divert: Use a better source identifier for netisr_queue_src() calls
These opaque IDs are used by netisr to distribute work among threads.
The mapping function is simply SourceID % numthreads, so using socket
addresses as source IDs isn't going to distribute packets well due to
alignment.
Use the divert socket's generation number instead, as that suits this
purpose much better.
unix: Set O_RESOLVE_BENEATH on fds transferred between jails
If a pair of jails with different filesystem roots is able to exchange
SCM_RIGHTS messages (e.g., using a unix socket in a shared nullfs
mount), a process in one jail can open a directory outside of the root
of the second jail and then pass the fd to that second jail, allowing
the receiving process to escape the jail chroot.
Address this using the new FD_RESOLVE_BENEATH flag. When externalizing
an SCM_RIGHTS message into the receiving process, automatically set this
flag on all new fds where a jail boundary is crossed. This ensures that
the receiver cannot do more than access files underneath the directory;
in particular, the received fd cannot be used to access vnodes not
accessible by the sender.
Approved by: so
Security: FreeBSD-SA-26:04.jail
Security: CVE-2025-15576
PR: 262179
[6 lines not shown]
