Both of the aforementioned macros have been present in FreeBSD
for well over a decade: 2009 for `KOBJMETHOD_END`; 2011 for
`DEVMETHOD_END`.
Adapt all hardcoded references of `{0, 0}` with `DEVMETHOD_END`
and `KOBJMETHOD_END` as appropriate. This helps ensure that
future adaptations to drivers following patterns documented
in driver(9) can be made more easily/without issue.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55414
MFC notes:
All conflicts were dropped as they didn't apply to code in branch.
Conflicts:
sys/dev/flash/w25n.c
sys/dev/nvd/nvd.c
sys/dev/nvme/nvme_sim.c
sys/dev/sound/pci/hdsp-pcm.c
sys/dev/sound/pci/hdsp.c
sys/dev/ufshci/ufshci_pci.c
(cherry picked from commit 0fc6c3f731a2cca3120798806c330a3081c9424b)
Only expose `dcb` when either `INET` or `INET6` is defined.
Reported by: clang (`-Wunused`)
MFC after: 1 week
Fixes 5547a7bb39 ("divert: Use a better source identifier...")
Differential Revision: https://reviews.freebsd.org/D55548
(cherry picked from commit bd758ebac3272f720c051570e043e4bc653dcd48)
"total" is the number of slots in the array, so wraparound needs to be
done when "first" or "last" is greater than or equal to the number of
slots.
Note that no consumers of the code are currently connected to the kernel
build.
Reported by: Stanislav Fort <stanislav.fort@aisle.com>
Reviewed by: bz, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56371
(cherry picked from commit 52d2fc702b85d56b35f8828fe7efca3cde0d25b7)
Focus on the MRQE field of the MRQC register, which is 4 bits wide,
and we use these 3 types of values.
- IXGBE_MRQC_RSSEN 0x1 (non VF mode)
- IXGBE_MRQC_VMDQRSS32EN 0xA (less than 33 VFs)
- IXGBE_MRQC_VMDQRSS64EN 0xB (less than 65 VFs)
If we always take a bitwise OR with IXGBE_MRQC_RSSEN,
IXGBE_MRQC_VMDQRSS32EN will never be chosen.
Select these 3 types of values for the proper case.
Signed-off-by: Yuichiro NAITO <naito.yuichiro@gmail.com>
Pull Request: https://github.com/freebsd/freebsd-src/pull/2132
(cherry picked from commit 938c076b9b0bc458a3877b52535527d37199fc09)
FIB_NH_LOG calls the `nhop_get_upper_family(nh)` to read
`nh->nh_priv->nh_upper_family` for failure logging.
Call FIB_NH_LOG before freeing nh so failures are logged
without causing a panic.
MFC after: 3 days
(cherry picked from commit 7d38eb720a8d8345949986d779e785984ae19ae0)
### Description
This particular change contains all functional and security fixes made
between 3.0.16 and 3.0.20, with the net-resulting security issues being
the ones addressed in 3.0.20 [1] [2].
This is a direct commit to stable/14 as stable/15 and later use OpenSSL
3.5, as of writing, and thus this change could not have been merged
through main and stable/15 since the 3.0.17+ was released after :main
switched to OpenSSL 3.5.
This does not contain any merge commits as any MFV changes are banned
unless they go through :main.
### Process used when updating the component
1. Run the subtree merge command in a staging tree.
2. Resolve conflicts.
3. Compare against reference branch.
4. Pull over remaining changes adding new manpages to the build.
5. Take changes from staging tree over to stable/14 .
### Test Plan
Tested with sanity checks on 14-STABLE (amd64) and `make tinderbox` on
all 14-STABLE supported architectures.
1. https://github.com/openssl/openssl/releases/tag/openssl-3.0.20
2. https://github.com/openssl/openssl/blob/openssl-3.0.20/CHANGES.md
There's no good justification to permanently hang a thread until the
tunnel can be destroyed. Make it interruptible so that the admin can
^C it and remedy the situation if something erroneously has the tunnel
open, rather than forcing them to open another shell to resolve it.
Reviewed by: markj
(cherry picked from commit 274bf7c8ae7e7b51853cd541481985f0e687f10e)
The result of IN6_ARE_MASKED_ADDR_EQUAL() macro is not an integer, so
threat it as a boolean value.
PR: 294114
Reported by: Peter Much <pmc citylink dinoex sub org>
(cherry picked from commit d9d7b59486499615a5fdce54443ce62aecf557e8)
nvlist_check_header() validated nvlh_size for overflow before
performing conversion. An mallicous user can set
NV_FLAG_BIG_ENDIAN in the header and craft nvlh_size so that
the orginall value passes the check, but after the conversion the
sizeof(nvlist_header) + size can overflow.
This can lead to a heap buffer overflow.
Approved by: so
Security: FreeBSD-SA-26:17.libnv
Security: CVE-2026-35547
Fixes: 36fa90dbde0060aacb5677d0b113ee168e839071
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56342
The buggy version allowed userspace to overflow the copy into adjacent
execve KVA regions, which enables, among other things, injecting
environment variables into privileged processes.
Approved by: so
Security: FreeBSD-SA-26:13.exec
Security: CVE-2026-7270
Reported by: Ryan Austin of Calif.io
Reviewed by: brooks, kib
Fixes: f373437a01 ("Add helper functions to copy strings into struct image_args.")
Differential Revision: https://reviews.freebsd.org/D56665
As per RFC5061 "4.2. New Parameter Types" the add/delete IP address
parameters (0xc001, 0xc002) may not be present in an INIT or INIT-ACK
chunk. They are only allowed to be present in an ASCONF chunk.
This also prevents unbounded recursion while parsing an SCTP packet.
Approved by: so
Security: FreeBSD-SA-26:14.pf
Security: CVE-2026-7164
PR: 294799
Reported by: Igor Gabriel Sousa e Souza
Sponsored by: Orange Business Services
AMD64 Architecture Programmer's Manual Volume 3 says the following:
> ECX[15:0] contains a count of the number of sequential pages to
> invalidate in addition to the original virtual address, starting from
> the virtual address specified in rAX. A count of 0 invalidates a
> single page. ECX[31]=0 indicates to increment the virtual address at
> the 4K boundary. ECX[31]=1 indicates to increment the virtual address
> at the 2M boundary. The maximum count supported is reported in
> CPUID function 8000_0008h, EDX[15:0].
ECX[31] being what we call INVLPGB_2M_CNT, signaling to increment the
VA by 2M.
> This instruction invalidates the TLB entry or entries, regardless of
> the page size (4 Kbytes, 2 Mbytes, 4 Mbytes, or 1 Gbyte). [...]
Combined with this, my interpretation of the current code is: if
<va> is aligned on a PDE boundary, we'll use INVLPGB_2M_CNT to try and
invalidate <cnt> PDEs with a single call, but that only works if <va> is
the start of at least <cnt> 2M pages. Otherwise, if <va> or any of the
subsequent PDEs isn't actually a superpage, then we would actually only
invalidate the *first* page within the PDE before skipping to the next
PDE, leaving the remainder of the 4K pages in between as they were.
The implication would seem to be that we would need to inspect the range
that we're trying to invalidate if we're planning on using
INVLPGB_2M_CNT at all, so this patch just simplifies it to a series of
4K invalidations. My gut feeling is that we likely still come out on
top vs. the TLB shootdown we're avoiding.
This seems to explain some issues we've seen lately with fdgrowtable()
and kqueue on recent Zen4/Zen5 EPYC hardware, where we'd experience
corruption that we can't explain.
Approved by: so
Security: FreeBSD-EN-26:10.amd64
PR: 293382
Reviewed by: alc, kib, markj
(cherry picked from commit 1b8e5c02f5c07521129e06ff8ab7c660238fd75c)
(cherry picked from commit ff11ae166cd9f8ae16a5c384d46aa1218f3ff013)
pmap_pkru_update_range() did not handle the case where a PDPE has PG_PS
set. More generally, the SET_PKRU and CLEAR_PKRU sysarch
implementations did not check whether the request covers a "boundary" vm
map entry. Fix this, add the missing PG_PS test, and add some tests.
Approved by: so
Security: FreeBSD-SA-26:11.amd64
Security: CVE-2026-6386
Reported by: Nicholas Carlini <npc@anthropic.com>
Reviewed by: kib, alc
Differential Revision: https://reviews.freebsd.org/D56184
The TIOCNOTTY handler detaches the calling process from its controlling
terminal. It clears the link from the session to the tty, but not the
pointers from the tty to the session and process group. This means that
sess_release() doesn't call tty_rel_sess(), and that pgdelete() doesn't
call tty_rel_pgrp(), so the pointers are left dangling.
Fix this by clearing pointers in tty_drop_ctty(). Add a standalone
regression test.
Approved by: so
Security: FreeBSD-SA-26:10.tty
Security: CVE-2026-5398
Reported by: Nicholas Carlini <npc@anthropic.com>
Reviewed by: kib, kevans
Fixes: 1b50b999f9 ("tty: implement TIOCNOTTY")
Differential Revision: https://reviews.freebsd.org/D56046
When a timerfd interval callout misses its scheduled activation time, a
differential is calculated based on the actual activation time and the
scheduled activation time. This differential is divided by the timerfd's
interval time and the quotient is added to the timerfd's counter.
Before this change, the next callout was scheduled to activate at:
scheduled activation time + timerfd interval.
This change fixes the scheduling of the next callout to activate at:
actual activation time + timerfd interval - remainder.
Security: FreeBSD-26:06.timerfd
Approved by: so
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D55790
MFC after: 2 weeks
(cherry picked from commit 85c0f1a87da1fd1eb3e646e86f70e630c48da91a)
(cherry picked from commit 3c00f603a2801fd780666f9e94a26f264a887c90)
- When allocating a page, we should only consider the PG_ZERO flag when
handling the top-level page.
- Unconditionally reset the flag when restarting the fault handler.
Previously, vm_fault_busy_sleep() would fail to reset it.
Approved by: so
Security: FreeBSD-EN-26:05.vm
PR: 294039
Reviewed by: kib
Tested by: Peter Much <pmc@citylink.dinoex.sub.org>
MFC after: 3 days
Fixes: cff67bc43df1 ("vm_fault: only rely on PG_ZERO when the page was newly allocated")
Differential Revision: https://reviews.freebsd.org/D56234
(cherry picked from commit 04132e01004316ddd0e0cde6ef15b100b7b1844d)
(cherry picked from commit 9b7c0f4f81f06424899094d4381dede79669b623)
Compiling drm-kmod on !X86 does not include asm/smp.h which includes
preempt.h on FreeBSD. In order to compile drm-kmod on other
architectures add the secondary #includes for preempt.h to
spinlock.h and hardirq.h (which now also gets included from highmem.h)
to connect the #include chain.
Sponsored by: The FreeBSD Foundation
PR: 279864
Reviewed by: jhibbits, emaste
Differential Revision: https://reviews.freebsd.org/D55974
(cherry picked from commit 1d18872c2519d7ca726ddc49735180ab1d8916e0)
(cherry picked from commit 29dce45d8c50ea5858dc91a4294e83b8d72a2f80)
Depending on the base channel ni_vht_chan2 - ni_vht_chan1 can be
negative. Apply abs() as indicated in the comments right above
| CCFS1 - CCFS0 | = 8 or > 16
in order to fix the channel width selection.
Sponsored by: The FreeBSD Foundation
PR: 293645
Fixes: 4bf049bfeefd9
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D55717
(cherry picked from commit 6cfd2b93e68061c7831016b91c2e308d01658764)
(cherry picked from commit 68fcf0b94c5167f89481052f358064c9b6732553)
This corrects the false detection of duplicate rules.
Approved by: so
Security: FreeBSD-SA-26:09.pf
Security: CVE-2026-4748
Reviewed by: kp
(cherry picked from commit 1fa873c93c8b08561c53107c7b90c53dfad30ddc)
(cherry picked from commit ac6bb58a715eaf0afb7a80dc87083f9819e10ac1)
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@anthropic.com>
Reviewed by: rmacklem
Fixes: a9148abd9d
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.
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: a779388f8b 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)
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.
Reported by: CI
Co-authored-by: bz
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55634
(cherry picked from commit f26cb4757eb74ceace39144933ae198ebf1b4f28)
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)
This corresponds to Linux f74dc880098b4a29f76d756b888fb31d81ad9a0c
That commit does not provide any public background detail, but it's been
in use for over 5 years and corresponds to previous chip bugs w.r.t.
automatic generation of PAUSE frames.
Reviewed by: kgalazka
Differential Revision: https://reviews.freebsd.org/D54555
(cherry picked from commit 2bdec2ee73be7dbafce9982b0dc5c273918a5443)
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.
Approved by: so
Reported by: kib, kp
Fixes: 350ba9672a7f ("unix: Set O_RESOLVE_BENEATH on fds transferred between jails")
(cherry picked from commit 3ef39f58e5d63a78fd1c37e6c62d599bc68d5e1e)
(cherry picked from commit 302120bcb934ea150555362326c812353fb72eaa)
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
Reviewed by: kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D50371
(cherry picked from commit 350ba9672a7f4f16e30534a603df577dfd083b3f)
(cherry picked from commit 3ad3ab5f9b6e91efc923bae9799697a823eb7227)
Approved by: so
Reported by: Ian FREISLICH <ianfreislich@gmail.com>
Fixes: f35525ff2053 ("file: Add a fd flag with O_RESOLVE_BENEATH semantics")
(cherry picked from commit 6783dfb10637100067520bd6d9804e154cfee7ee)
(cherry picked from commit 8f6769b82a2a071cf07080b6d77639e919efbbcf)
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.
Approved by: so
PR: 262180
Reviewed by: kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D50371
(cherry picked from commit f35525ff2053e026a423e852136d73ed93c95803)
(cherry picked from commit 10b3f2138573da952b4db29f88f6d67cfc3300cd)
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)
When icmp6 sends an ICMPv6 message, it reuses the mbuf of the packet
that triggered the ICMPv6 message and prepends an IPv6 and ICMPv6
header. For a locally generated packet with checksum offloading, the
mbuf still has csum_flags set indicating that a SCTP/TCP/UDP checksum
has to be computed and inserted. Since this not the case anymore,
csum_flags need to be cleared.
PR: 293227
Reviewed by: kp, zlei, tuexen
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D55367
(cherry picked from commit ada4dc77577f7162353e8c2916ba5c258b6210f0)
The only possible return value of function ipfw_init() is 0. Make it
return void to match the prototype of SYSINIT.
MFC after: 1 week
(cherry picked from commit 1bba2194c8a960235f8eae36e7d3e96f347ce779)
(cherry picked from commit 745b6ca4ed933f9f4c1d314dc7b0aa31e8e9e0de)
ifnets already track if_allmulti() calls in the if_amcount field. That
field is older than the comment, so I'm not exactly sure what the intent
was; let's just remove it.
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
(cherry picked from commit a45fb94801dffd414bdb1981def0e977ef0c774f)