pfsync: reject invalid SCTP states
SCTP states should always have a src scrub object associated with them.
Crafted pfsync packets might not have this, leading to us derferencing a
NULL pointer on cleanup.
Validate the pfsync state insertion packet to make sure this is correct.
PR: 294989
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
nfs_pub: move from vfs_subr.c to vfs_export.c
nfs_pub is used only in vfs_export.c.
Reviewed by: kib, rmacklem
Differential Revision: https://reviews.freebsd.org/D56777
bsdinstall: Always use pkg.FreeBSD.org
The FreeBSD-base bits are accessible via pkg.FreeBSD.org, even for
releases, so there is no need to point at pkgbase.FreeBSD.org.
MFC after: 3 days
packages: Make create-sets.sh more robust during release
Commit d1c176fedfc9 made create-sets.sh exit when it encounters an
error, instead of creating an empty repository. However, this turns
out to cause some issues:
1. A package not having any sets is considered an error, but during
the release build, we stuff a 'pkg' package into the repository
which doesn't have any sets, which causes a failure. Avoid this
by simply ignoring the pkg package.
2. No error was printed in this case, which made the problem hard
to diagnose. Add an explicit error message.
3. A similar problem occurred running on a repository which already
contained sets, which is not usually done during the build, but
is not necessarly an inappropriate thing to do. Fix this one by
ignoring set packages when looking for sets.
[11 lines not shown]
nfs_nfsdserv.c: Clip number of callback slots
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
Import smart revision 1.0.2
The smart command allows the user to monitor the various information
reported by Self-Monitoring, Analysis and Reporting Technology (SMART)
present on most ATA, SCSI, and NVMe storage media.
linuxkpi: Implement `module_*()` APIs as static functions
This fixes an "unused variable" warning when building DRM drivers.
Reviewed by: emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56780
execve: Add guard pages around execve KVA buffers
This helps ensure that overflows will trigger a panic instead of
silently corrupting adjacent buffers, as happened in SA-26:13.exec.
Extend kmap_alloc_wait() to support allocation of guard pages on both
sides of a KVA allocation. Modify the exec_map setup accordingly. Add
the "vm.exec_map_guard_pages" tunable to provide control over the guard
page allocations.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56711
ifnet: if_detach(): Fix races with vmove operations
The rationality is that the driver private data holds a strong reference
to the interface, and the detach operation shall never fail. Given the
vmove operation, if_vmove_loan(), if_vmove_reclaim() or vnet_if_return()
is not atomic and spans multiple steps, acquire ifnet_detach_sxlock only
for if_detach_internal() and if_vmove() is not sufficient. It is possible
that the thread running if_detach() sees stale vnet, or the vmoving is
in progress, then if_unlink_ifnet() will fail.
Fix that by extending coverage of ifnet_detach_sxlock a bit to also
cover if_unlink_ifnet(), so that the entire detach and vmove operation
is serialized.
Given it is an error when the if_unlink_ifnet() fails, and if_detach()
is a public KPI, prefer panic() over assertion on failure, to indicate
explicitly that bad thing happens. That shall also prevent potential
corrupted status of the interface, which is a bit hard to diagnose.
[7 lines not shown]
tests/net/if_clone_test: Add a test for races between if_detach() and if_vmove_reclaim()
Ideally we shall have tests for all possible races. It is races between
if_detach(), if_vmove_loan(), if_vmove_reclaim() and vnet_if_return().
Well that requires too many tests and it appears to be less valuable to
have them all. So focus on potential in future regressions related to
recent fixes [1] and [2] only.
[1] ee9456ce3753 ifnet: Fix races in if_vmove_reclaim()
[2] ba7f47d47dc1 ifnet: if_detach(): Fix races with vmove operations
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D56606
(cherry picked from commit f4be16983dea4904f85ac20e921ad2a8c18a0f79)
(cherry picked from commit 696d1590697e9d4c0f07ce0a8d76a62bc77bdfd5)
if_clone: Make ifnet_detach_sxlock opaque to consumers
The change e133271fc1b5e introduced ifnet_detach_sxlock, and change
6d2a10d96fb5 widened its coverage, but there are still consumers,
net80211 and tuntap e.g., want it. Instead of sprinkling it everywhere,
make it opaque to consumers.
Out of tree drivers shall also benefit from this change.
Reviewed by: kp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56298
(cherry picked from commit e9fc0c538264355bd3fd9120c650078281c2a290)
(cherry picked from commit c624e04a0bd0ab147ec64c17e3e53f5ebc769dcf)
ifnet: Move SIOCSIFVNET from ifhwioctl() to ifioctl()
SIOCSIFVNET is not a hardware ioctl. Move it to where it belongs.
Where here, rewrite the logic of checking whether we are moving the
interface from and to the same vnet or not, since it is obviously not
stable to access the interface's vnet, given the current thread may
race with other threads those running if_vmove().
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D55880
(cherry picked from commit 38bd7ef62f318f791e232e217855307a9d75efa0)
(cherry picked from commit 477c3ba3673152e88ec5c50d8f45db24102bdf07)
ifnet: vnet_if_return(): Avoid unnecessary recursive acquisition of ifnet_detach_sxlock
vnet_if_return() will be invocked by vnet_sysuninit() on vnet destructing,
while the lock ifnet_detach_sxlock has been acquired in vnet_destroy()
already.
With this change the order of locking is more clear. There should be no
functional change.
Reviewed by: pouria
Fixes: 868bf82153e8 if: avoid interface destroy race
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56288
(cherry picked from commit f1fae67afbb13a41d488d0e0ec66b1805925019c)
(cherry picked from commit ccfc2d91304e88aafc0ca0e13e0f8b5a156d2a01)
ifnet: Remove unreachable code
The ioctls SIOCSIFVNET and SIOCSIFRVNET are for userland only. For
SIOCSIFVNET, if_vmove_loan(), the interface is obtained from current
VNET. For SIOCSIFRVNET, if_vmove_reclaim(), a valid child prison is
held before getting the interface. In both cases the VNET of the
obtained interfaces is stable, so there's no need to check it.
No functional change intended.
Reviewed by: glebius, jamie (for #jails)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D55828
(cherry picked from commit e0731059af912a27d0f842959218946b1daaa7d1)
(cherry picked from commit a989b0fbc965b453d97e3d032efb4f9c7592734a)
ifnet: Fix races in if_vmove_reclaim()
The thread running if_vmove_reclaim() may race with other threads those
running if_detach(), if_vmove_loan() or if_vmove_reclaim(). In case the
current thread loses race, two issues arise,
1. It is unstable and unsafe to access ifp->if_vnet,
2. The interface is removed from "active" list, hence if_unlink_ifnet()
can fail.
For the first case, check against source prison's vnet instead, given
the interface is obtained from that vnet.
For the second one, return ENODEV to indicate the interface was on the
list but the current thread loses race, to distinguish from ENXIO, which
means the interface or child prison is not found. This is the same with
if_vmove_loan().
Reviewed by: kp, pouria
[6 lines not shown]
amd/int0x80 test: fix inline asm for gcc
Gcc complained about the unused %0 asm argument.
Fixes: 2c2ec6bbc9cc ("tests/sys/arch/amd64: add a program to check INT $0x80 behavior on amd64")
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56781
asmc: rename wol sysctl to auto_poweron
Older SMC firmware exposed AUPO as a Wake-on-LAN control. On updated
firmware, the key controls automatic power-on when AC power is restored
after a power loss; WoL is handled by the GBE controller instead.
Rename the sysctl to reflect the current semantics. No compatibility
alias is provided as the sysctl has not appeared in any release.
Reviewed by: ziaee, adrian
Differential Revision: https://reviews.freebsd.org/D56747
llvm: Don't install /usr/bin/{gcov,objdump} twice
Commit c4f08d46c7f7 moved the symlinks for the LLVM binutils from LLVM
itself to the toolchain (usr.bin/clang/toolchain), but did not remove
the links for /usr/bin/gcov and /usr/bin/objdump from the llvm version,
meaning we installed them twice, once in the clang package and once in
the toolchain package.
Remove the links from the llvm version and move the MLINKs to toolchain,
which is where the other MLINKs dwell.
While here, fix toolchain to use the correct build option for llvm-cov,
MK_LLVM_COV.
Fixes: c4f08d46c7f7 ("llvm-*: Move all LLVM_BINUTILS symlinks to toolchain package")
Reported by: jrm
Reviewed by: jrm, dim, emaste
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D56788
vis.3: Try to better describe VIS_SAFE
The current text fails to draw the reader's attention to the fact that
VIS_SAFE essentially exempts certain characters from being encoded.
While here, fix some markup nits.
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56716
krb5: Fix two NegoEx parsing vulnerabilities
Bring in upstream commit 2e75f0d93 fixing two CVEs. Upstream commit
log is:
In parse_nego_message(), check the result of the second call to
vector_base() before dereferencing it. In parse_message(), check for
a short header_len to prevent an integer underflow when calculating
the remaining message length.
Reported by Cem Onat Karagun.
CVE-2026-40355:
In MIT krb5 release 1.18 and later, if an application calls
gss_accept_sec_context() on a system with a NegoEx mechanism
registered in /etc/gss/mech, an unauthenticated remote attacker can
trigger a null pointer dereference, causing the process to terminate.
[10 lines not shown]
