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)
This is more natural and corresponds more closely to the v4 multicast
routing code. No functional change intended.
Reviewed by: glebius
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54983
(cherry picked from commit b370fcc716b9cfd4d08e291f0009f02452c84d64)
Refactoring to perform the batch processing of
log messaged in two phases. First cycling through a limited
number of collected packets, and only thereafter freeing
the processed packets. This prevents any chance of calling
free while in a critical / spinlocked section.
Reviewed By: tuexen
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D42949
(cherry picked from commit a95cd6e4870b79178860e03366c4327e533ecf1e)
- The v6 socket option and ioctl handlers had no privilege checks at
all. The socket options, I believe, can only be reached via a raw
socket, but a jailed root user with a raw socket shouldn't be able to
configure multicast routing in a non-VNET jail. The ioctls can only
be used to fetch stats.
- Delete a bogus comment in X_mrt_ioctl(), one can issue multicast
routing ioctls against any socket. Note that the call path is
soo_ioctl()->rtioctl_fib()->mrt_ioctl().
I think all of the mroute privilege checks should be done within the
ip(6)_mroute code, but let's first make the v4 and v6 modules
consistent.
Reviewed by: glebius
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54982
(cherry picked from commit 74839871be363c5c2ac7ccd3396f36bdb58d19de)
The multicast routing code was using spin mutexes for packet counting,
but there is no reason to use them instead of regular mutexes, given
that none of this code runs in an interrupt context. Convert to using
default mutexes.
Reviewed by: glebius
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54603
(cherry picked from commit a265c8b4a5a7c8fdd33e27b8f74bd2a514f82c70)
Count input/output packets and bytes on the interface as well, not just
in openvpn-specific counters.
PR: 292464
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 21d666a19331f31fb6dfa1e370de5a84a1a5cb46)
Use sbuf_new_for_sysctl() instead of sbuf_new_auto() when exposing
the flags via sysctl.
(cherry picked from commit 8da838ac31692e381adfc63d83ea49f2adabbf23)
Right now the 64-bit flags field needs to be casted to a 32-bit field,
because clang warns if more than 32-bits are used.
Once clang is fixed, this restriction will be removed and more bits
will be added.
Reviewed by: markj, Timo Völker
Differential Revision: https://reviews.freebsd.org/D54288
(cherry picked from commit 634d9c0d111b630c3d63a1cf25d15c32a37afab8)
Provide the flags used for a vtnet interface via the sysctl tree.
This is mostly used for debugging purposes.
Reviewed by: Timo Völker
Differential Revision: https://reviews.freebsd.org/D54283
(cherry picked from commit e3a0571ad74d8429a95fcae9efc1d91cc109a337)
This allows adding flags in the upper 32 bits in a consistent way.
No functional change intended.
(cherry picked from commit e0c6c4ecfc755b78ac9135033053d2f15c62bf04)
In the ice_if_promisc_set function, the driver currently disables the
IFF_ALLMULTI flag, thereby preventing the activation of multicast mode.
To address this issue, implement appropriate handling to ensure the
flag is managed correctly.
Signed-off-by: Yogesh Bhosale <yogesh.bhosale@intel.com>
Tested by: Gowthamkumar K S <gowtham.kumar.ks@intel.com>
Differential Revision: https://reviews.freebsd.org/D54186
(cherry picked from commit 98bdf63f6e94be42a1787de73608de15bcb3419a)
The variable reg_rctl stores the value read from reg E1000_RCTL. It
may contain bits E1000_RCTL_VFE and E1000_RCTL_CFIEN which control
VLAN hardware filter feature. The promiscuous mode implies all tagged
or untagged packets should be accepted, so the VLAN hardware filter
feature should be disabled when enabling the promiscuous mode.
Calling em_if_vlan_filter_disable() did the task, but later writing
the value of reg_rctl back to the reg E1000_RCTL may restore the
feature.
Move the calling of em_if_vlan_filter_disable() after writing the reg
to fix that.
PR: 292759
Reviewed by: kbowling
Tested by: vova@zote.me
Fixes: 2796f7cab1 e1000: Fix up HW vlan ops
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54973
(cherry picked from commit e63ee5fedb8dab51f1bd6d24cc650b68d9663db5)
(cherry picked from commit 8880678b7a47ccfdcc14d3e7cad7f137862dccea)
IGMP requires hosts to use the lowest version they have seen on the network.
When net.inet.igmp.default_version is changed, we do not change IGMP
version used by interface even if the interface use an higher version than
V_igmp_default_version. So we could send IGMPv3 even if the user has requested
IGMPv2 or IGMPv1 via the sysctl.
Change IGMP version for each interface when V_igmp_default_version is smaller
than the version used by the interface.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1615
Differential Revision: https://reviews.freebsd.org/D50071
IGMP requires hosts to use the lowest version they've seen on the
network. When the IGMP timers expire we take the opportunity to upgrade again.
However, we did not take the net.inet.igmp.default_version sysctl
setting into account, so we could end up switching to IGMPv3 even if the
user had requested IGMPv2 or IGMPv1 via the sysctl.
Check V_igmp_default_version before we upgrade the IGMP version.
Reviewed by: adrian
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D41628
