These structures are copied out to userspace, and it's possible to leak
uninitialized stack bytes since these routines and their callers weren't
careful to clear them first. Add memsets to avoid this.
Reported by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Reviewed by: kp, emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53342
(cherry picked from commit ff08916e9ac689e6ce734de72325fc2bd9495a35)
The handlers were not checking that the group names are nul-terminated.
Add checks for this.
Reported by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Reviewed by: zlei
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53344
(cherry picked from commit 32919a34f17ac1af99dec7376f22a8393c251602)
Fix the htons byteorder of vxlan packets after
`vxlan_pick_source_port` picks a source port during encapsulation.
Reviewed by: zlei, kp, adrian
Differential Revision: https://reviews.freebsd.org/D53022
(cherry picked from commit 1cc316727ebae157b3d035d9fb1ad38310a80698)
Add capabilities RXCSUM and RXCSUM6 as well as TXCSUM and TXCSUM6 for
for receive and transmit checksum offloading for TCP and UDP to the
epair interface and enable them by default.
RXCSUM and RXCSUM6 are enabled because an epair interface may receive
a packet with the csum_flag CSUM_DATA_VALID set, which is expected
only if these capabilities are enabled. Since it seems not helpful to
remove this flag, it is not possible to disable these capabilities.
TXCSUM and TXCSUM6 are synchronized between the two epair interface
ends. If enabled/disabled on one end, it will be enabled/disabled on
the other end. If the sending epair interface end has TXCSUM or TXCSUM6
enabled and the receiving end is in a bridge, it is assumed that all
interfaces in the bridge have that capability enabled. Otherwise the
bridge would have disabled that capability on the receiving epair
interface end in the bridge which would have disabled that capability
on the sending epair interface end as well due to the synchronization.
Reviewed by: bcr, Seyed Pouria Mousavizadeh Tehrani
Differential Revision: https://reviews.freebsd.org/D51639
(cherry picked from commit e4ea162509e400340a2bc3e755071a92f3465e2d)
Given IPPROTO_IPV4, IPPROTO_IPV6 and IPPROTO_ETHERIP have different
protocol numbers, then it is perfect valid to tunnel IPv4, IPv6 and
Ethernet traffic over IPv[46] by the same interface. Since gif(4) has
already utilized the inbound csum_data field to carry address family,
also teach if_bridge(4) to do that, rather than checking if a gif(4)
interface is member of a if_bridge(4) interface.
Without this fix, tunnel IPv[46] over IPv[46] will not work when the
gif(4) interface is member of a if_bridge(4) interface, aka the EtherIP
setup, as the address family passed from gif_output() will be overwritten
with the wrong one AF_LINK by gif_transmit(), and end up with incorrectly
encapsulated packets.
PR: 227450
Reviewed by: kp
Tested by: meta
Fixes: 8a03087223 gif(4): Assert that gif_output() isn't called for EtherIP
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D51682
(cherry picked from commit f4744b8acb932fbb3e48b71d31b7cd585566b668)
This is part of the upcoming USB umb(4) work.
PR: 263783
Approved by: adrian, zlei
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48167
(cherry picked from commit 86bfbaf1002c88b5c1a6d3ed261becedb533490b)
and fix assigning IP addresses to the gif(4) interface when it is a
member of a if_bridge(4) interface.
When setting the sysctl net.link.bridge.member_ifaddrs to 1, if_bridge(4)
can eliminate unnecessary walk of the member list to determine whether
the inbound unicast packets are for us or not.
Well when a gif(4) interface is member of a if_bridge(4) interface, it
acts as the tunnel endpoint to tunnel Ethernet frames over IP network,
aka the EtherIP protocol, so the IP addresses configured on it are
independent of the if_bridge(4) interface or other if_bridge(4) members,
hence the sysctl net.link.bridge.member_ifaddrs should not have any
influnce over gif(4) interfaces's behavior of assigning IP addresses.
PR: 227450
Reported by: Siva Mahadevan <me@svmhdvn.name>
Reviewed by: ivy, #bridge
MFC after: 1 week
Fixes: 0a1294f6c610 bridge: allow IP addresses on members to be disabled
Differential Revision: https://reviews.freebsd.org/D52200
(cherry picked from commit 9764aa1ccad08a7ec53ed9b80741b9553f3fa4e6)
While diagnosing PR 279653 and PR 285129, I observed that thread may
write to freed memory but the system does not crash. This hides the
real problem. A clear NULL pointer derefence is much better than writing
to freed memory.
PR: 279653
PR: 285129
Reviewed by: glebius
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D49444
(cherry picked from commit b5c46895fdddcdb7dd1994598925d6989ea7c8f2)
The link-level address and the mbuf shall not overlap. Prefer memcmp()
over bcmp() for slight performance gain.
No functional change intended.
Reviewed by: glebius
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D52345
(cherry picked from commit 51098f0529f0d1cc532512e0eae9bfcffb8e68e4)
This ensures other threads, e.g. ioctl threads, see the correct counter
routine once after the interface has been attached.
This change partially reverts commit 23ac9029f9, which for unclear
reason moved setting the get counter routine after ether_ifattach().
Reviewed by: kbowling, kgalazka, #iflib
Fixes: 23ac9029f9 Update iflib to support more NIC designs
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D50712
(cherry picked from commit ae7f8da8bf6ed0c4f0e9f0e95ae2b08abce54378)
This commit restores if_bpfmtap and if_etherbpfmtap functions, and
implement them as wrappers around bpf_mtap_if and ether_bpf_mtap_if
funcitons.
Fixes: bceb9c2f2b19
Sponsored by: Juniper Networks, Inc.
Summary:
These came in the original DrvAPI commits in 2014, and are obsoleted by
bpf_mtap_if() and ether_bpf_mtap_if(). The `_if` suffix, rather than
prefix, conveys that it's operating on the bpf of the interface, instead
than the interface itself.
Reviewed by: glebius
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D41146
(cherry picked from commit 2a3716432d209c5fef1eb1a719f4c1914e7c8b5a)
If a client changes its IP address notify userspace of this.
The UDP filtering function supplies the remote IP address, so we check if the
address changed there. If so, we tag the packet with the new address. Once the
packet is decrypted (and as part of that, has had its signature checked) we
can commit to the address change. Take the write lock and notify userspace of
the change.
Reviewed by: markj
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D51468
(cherry picked from commit 9c52600a5a150117b4396df3b868cf2516e1674c)
When we parse an nvlist sockaddr we should set the sockaddr_in(6)'s length
field. This isn't currently used by anything yet, but it's reasonable to expect
a sockaddr to contain its length.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit e83df5367d30761803e09bd7fcf518638dfe43d2)
A if_ovpn interface carries a reference to a socket, which has a
credential reference, which holds a reference on the containing prison
and prevents SYSUNINITs from being invoked. So, register a
PR_METHOD_REMOVE callback and destroy the cloner from there instead,
since that mechanism doesn't require the prison refcount to drop to zero
first.
This fixes a bug where jails get left stuck in the DYING state after
running if_ovpn regression tests.
Reviewed by: kp
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51526
(cherry picked from commit 96b29c7f0cffd377a757ad8ccc0cdd8fcb96d0dd)
In UDP server mode, openvpn implements the "multihome" option, which
makes it avoid binding to an address. Instead, the server socket is
bound to INADDR_ANY.
Today, when configuring a new peer and setting the source address,
sockaddr() returns the wildcard address, so the source address is
implicitly determined by the output interface. This doesn't work as one
would want if the WAN interface has multiple addresses and clients
connect to non-primary addresses.
Make multihome mode work properly: use the local address supplied by
openvpn in preference to that of the socket. We still fetch the port
number out of the socket.
PR: 273664
Reviewed by: kp
MFC after: 1 month
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51498
(cherry picked from commit 05b5d56c540335ed17acf843810901338bf862d5)
We do this elsewhere, so copy the pattern here.
Reviewed by: kp
MFC after: 2 weeks
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51496
(cherry picked from commit a7dfc570f2747668b2fdd8fde6e1954fcedb2378)
Replace priorities specified by a base priority and some hardcoded
offset value by symbolic constants. Hardcoded offsets prevent changing
the difference between priorities without changing their relative
ordering, and is generally a dangerous practice since the resulting
priority may inadvertently belong to a different selection policy's
range.
Since RQ_PPQ is 4, differences of less than 4 are insignificant, so just
remove them. These small differences have not been changed for years,
so it is likely they have no real meaning (besides having no practical
effect). One can still consult the changes history to recover them if
ever needed.
No functional change (intended).
MFC after: 1 month
Event: Kitchener-Waterloo Hackathon 202506
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45390
(cherry picked from commit 8ecc41918066422d6788a67251b22d11a6efeddf)
In a mixed lagg, its likely that ifcaps or hwassist may not
match between members. If this is true, the logical OR will
be short-circuited and if_hw_tsomax_update() will not be called.
Fix this by calling it inside the body of the if as well
Sponsored by: Netflix
(cherry picked from commit 78bdaa57cfbac759a6d79ecad2fae570e294a4b3)
ether_ifattach() does not touch if_type, so it is not mandatory to fix
the if_type after ether_ifattach(). Without this change, the event
listeners, e.g. netlink, will see wrong interface type IFT_ETHER rather
than the correct one IFT_L2VLAN. There is also a potential race that
other threads see inconsistent interface type, i.e. initially IFT_ETHER
and eventually IFT_L2VLAN.
As a nice effect, this change eliminates the memory allocation for
if_hw_addr, as vlan(4) interfaces do not support setting or retrieving
the hardware MAC address yet [1].
[1] ddae57504b Persistently store NIC's hardware MAC address, and add a way to retrive it
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50914
(cherry picked from commit a19b353d354d4ef808965c53253103cb6e7e6708)
Change 80e60e236d made the if_index global, and for the whole lifecycle
of an interface its index never changes, then there is no need to
synchronize the interface index in the link layer address when moving
interfaces from one vnet to another.
No functional change intended.
Reviewed by: glebius
Fixes: 80e60e236d ifnet: make if_index global
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50975
(cherry picked from commit 0b4c4833ee3eab0ce46b3bdbf054bca4b6bb7429)
Lots of Ethernet drivers fix the header length after ether_ifattach().
Well since the net stack can conclude it based on the capability
IFCAP_VLAN_MTU, let the net stack do it rather than individual drivers.
Reviewed by: markj, glebius
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D50846
(cherry picked from commit 6ce8fd1978a9526ff0dc02ed98ef797f9154ec1f)
ether_ifattach() no longer sets if_type to IFT_ETHER and keeps it as is
since the change [1].
[1] fc74a9f93a Stop embedding struct ifnet at the top of driver softcs
No functional change intended.
MFC after: 1 week
(cherry picked from commit a07604e6264b88222941fa61c6f989bad5490765)
Prefer tab over eight whitespaces for indentation, and four spaces as
second level idents.
MFC after: 3 days
(cherry picked from commit 721e783a2a3316826f92fb44c931e28163118b3f)
This global variable is used only in this file. While here, constify it
since it is only used to read.
No functional change intended.
MFC after: 1 week
(cherry picked from commit 517eb20e54e59173b9dbede0bb3356f6197b5aa9)
if_link_ifnet() adds the interface to the global network interface list,
and it is a natural synchronization point. With this change, any threads
that obtain the reference of the interface via ifunit(), ifunit_ref() etc.,
will be guaranteed to see the address family dependent data rightly.
The issue [1] reported by Mike Belanger also hints the potential race.
MFC note: this change depends on e64fe5ad3a23, as calculating the max
IPv6 MTU through all the interfaces requires the current interface to
be added to the global network interface list firstly.
[1] https://lists.freebsd.org/archives/freebsd-net/2025-May/006817.html
Reviewed by: glebius
MFC after: 1 month
MFC with: e64fe5ad3a23 netinet6: Remove a set but not used global variable in6_maxmtu
Differential Revision: https://reviews.freebsd.org/D49358
(cherry picked from commit 098b5d4dc744283a90b2d80c11395ecc18a84084)
commit 49f39043a02d6011c1907e1b07eb034652a1269c
Author: phessler <phessler@openbsd.org>
Date: Fri Apr 28 14:08:34 2023 +0000
Relax the "pass all" rule so all forms of neighbor advertisements are allowed
in either direction.
This more closely matches the IPv4 ARP behaviour.
From sashan@
discussed with kn@ deraadt@
If a packet is malformed, it is dropped by pf(4). The rule referenced
in pflog(4) is the default rule. As the default rule is a pass
rule, tcpdump printed "pass" although the packet was actually
dropped. Use the actual action, rather than the rule's action, or an
attempt at guessing the correct action.
Inspired by OpenBSD's 'pflog(4) logs packet dropped by default rule with block.' commit.
Sponsored by: Rubicon Communications, LLC ("Netgate")
pfil hooks (i.e. firewalls) may pass, modify or free the mbuf passed
to them. (E.g. when rejecting a packet, or when gathering up packets
for reassembly).
If the hook returns PFIL_PASS the mbuf must still be present. Assert
this in pfil_mem_common() and ensure that ipfilter follows this
convention. pf and ipfw already did.
Similarly, if the hook returns PFIL_DROPPED or PFIL_CONSUMED the mbuf
must have been freed (or now be owned by the firewall for further
processing, like packet scheduling or reassembly).
This allows us to remove a few extraneous NULL checks.
Suggested by: tuexen
Reviewed by: tuexen, zlei
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43617
This commit also includes the original refactoring changes
This change allows the kernel to operate with the default netisr cpu-affinity settings while having RSS compiled in. Normally, RSS changes quite a bit of the behaviour of the kernel dispatch service - this change allows for reducing impact on incompatible hardware while preserving the option to boost throughput speeds based on packet flow CPU affinity.
Make sure to compile the following options in the kernel:
options RSS
As well as setting the following sysctls:
net.inet.rss.enabled: 1
net.isr.bindthreads: 1
net.isr.maxthreads: -1 (automatically sets it to the number of CPUs)
And optionally (to force a 1:1 mapping between CPUs and buckets):
net.inet.rss.bits: 3 (for 8 CPUs)
net.inet.rss.bits: 2 (for 4 CPUs)
etc.
Set pin_default_swi to 0 by default in the RSS case.
This should be 4094 (0xFFE), not 4095 (0xFFF), since 0xFFF is not a
valid VID.
Fixes: c59492025073 ("sys/net: add DOT1Q_VID_{MIN,MAX}")
MFC after: 3 days
Reviewed by: kevans, kp, adrian
Approved by: kevans (mentor)
Differential Revision: https://reviews.freebsd.org/D50576
(cherry picked from commit d9b6b10e5ebbb517a079e89ac0de99be3b815c8d)
instead of accepting any character as a delimiter, only accept ':', '.'
and '-', and only permit a single delimiter in an address.
this prevents accepting bizarre addresses like:
ifconfig epair2a link 10.1.2.200/28
... which is particularly problematic on an INET6-only system, in which
case ifconfig defaults to the 'link' family, meaning that:
ifconfig epair2a 10.1.2.200/28
... changes the Ethernet address of the interface.
bump __FreeBSD_version so link_addr() consumers can detect the change.
Reviewed by: kp, des
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D49936
(cherry picked from commit a1215090416b8afb346fb2ff5b38f25ba0134a3a)
Note-from-OPNsense: not bumping the FreeBSD version for stable/25.7
this is a re-entrant version of link_ntoa. use an in-out parameter for
the buffer size, so the user requires at most two calls to determine the
needed size.
reimplement link_ntoa using link_ntoa_r with a static buffer.
Reviewed by: des
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D50202
(cherry picked from commit da509c29089ab169b667ebdf82aa903987ba9c6d)
if_unroute() is static since 2004 and is not used anywhere except for
if_down().
This also makes it easier to grep by the pattern `if_flags &= ~IFF_UP`.
No functional change intended.
Reviewed by: glebius
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49356
(cherry picked from commit 0693c3f7cb3d9e5389863a0c131ddef799c77091)
to avoid strange precedence errors, enclose the macro body in
parentheses. this fixes constructs like: if (VLANTAGOF(m) == i)
Reviewed by: kp
(cherry picked from commit f36292f010fcc6391605182f2973fdc12a3bd15f)
If an interface is a bridge member, and a vlan(4) is also created on
that interface, and net.link.bridge.member_ifaddrs=0, then vlan(4)
will never see any incoming frames because bridge doesn't pass them
to the host for processing.
Work around this by checking for locally-addressed frames using the
MAC address of the interface we received the frame on, but only if
the frame has a .1q tag and there's a vlan trunk on the interface.
This behaviour is almost certainly "wrong" and it's not clear if we
really want to support this, but it did work in the past and the
member_ifaddrs change was not supposed to break it, so this restores
the previous behaviour.
PR: 287150
MFC after: 1 week
Reviewed by: kevans, des
Approved by: kevans (mentor), des (mentor)
Differential Revision: https://reviews.freebsd.org/D50623
(cherry picked from commit a5fe142e08447c7116b89159c110d02e860ac6a1)
When adding a new interface to a bridge and allow_llz_overlap=0, which
is the default value, if_bridge checks if the interface has IPv6 link
local addresses assigned, and if it does, it calls in6_ifdetach() to
remove all IPv6 addresses from the interface.
This means it was possible to do this:
% ifconfig bridge1 create inet6 -ifdisabled auto_linklocal up
% ifconfig epair20 create inet6 -ifdisabled auto_linklocal up
% ifconfig bridge1 addm epair20a
... with the result that the link-local address on epair20a would be
removed, then the interface would be added to the bridge.
If member_ifaddrs=0, which is also the default value, this no longer
works:
% ifconfig bridge1 addm epair20a
ifconfig: BRDGADD epair20a: Invalid argument
This is because the member_ifaddrs check runs before allow_llz_overlap
does its thing, and returns EINVAL since the new interface has IP
addresses on it.
To restore the previous behaviour, reverse the order of these two
checks, so the IPv6 addresses are removed before we check whether
the interface has IPv6 addresses.
MFC after: 1 week
Reviewed by: kevans, kp
Approved by: kevans (mentor)
Differential Revision: https://reviews.freebsd.org/D50477
(cherry picked from commit da2dbdc297c948d5923812e3d3b777b790d3bf43)
ether_vlanid_t is a type to represent a VLAN ID, for example inside a
.1q tag. since this is specific to Ethernet, put it in net/ethernet.h.
change bridge to use the new type instead of uint{16,32}_t.
Reviewed by: adrian, kp
Differential Revision: https://reviews.freebsd.org/D49836
(cherry picked from commit 96f830456fd449c4cb5a7df8a2f6c3c96993b43e)
