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]
firewall: adjust sort order in networks and aliases; closes #10022 #10031
While here also switch to use the cached model exclusively and change the
formatting of address/network shortcuts actually calling them "network".
