bnxt_en: Retrieve maximum of 128 APP TLVs
It appears that the maximum number of APP TLVs supported by the hardware
is 128 according to D45005. Well Daniel Porsch reported an issue PR284073
which shows that the number can exceed the limit, causing out of bound
write to on-stack allocated variable app[128] and the kernel panics.
Limit to 128 while retrieving APP TLVs.
PR: 284073
Reviewed by: markj
Tested by: Daniel Porsch <daniel.porsch at loopia.se>
Fixes: 35b53f8c989f bnxt_en: Add PFC, ETS & App TLVs protocols support
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48589
(cherry picked from commit 3de231b4d956f7b9c22e31f75805030a417f7bf3)
pfctl: fix recursive printing of NAT rules
pfctl_show_nat() is called recursively to print nat anchors. This passes the
anchor path, but this path was modified by pfctl_show_nat(), leading to issues
printing the anchors.
Make a copy of the path ('npath') before we modify it. Ensure we do this
correctly by sprinking in 'const', and add a test case to verify that we do now
print things correctly.
Reported by: Thomas Pasqualini <thomas.pasqualini at orange.com>
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 58164dcb55d62ca73b5e550b8344bf61e2d8a47a)
pf: Use a macro to get the hash row in pf_find_state_byid()
This seems a bit preferable to open-coding it. No functional change
intended.
Reviewed by: kp, glebius
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49518
(cherry picked from commit 27f70efebf1d9424462f291e9d04e62272083aa7)
Copy the new ia32 loader
This handles copying in install-boot.sh and bsdinstall's bootconfig.
install-boot.sh:
make_esp_file now optionally takes extra arguments so it can copy
multiple files. This is used by the amd64 release scripts.
make_esp_device also takes an extra optional argument for efibootname.
This is currently unused, but it can be used in the future to do
something like:
make_esp_device loader.efi bootx64
make_esp_device loader_ia32.efi bootia32
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1098
(cherry picked from commit 599273f942b8dc6f957487bb28f36694dab9dad2)
pf: improve pf_state_key_attach() error handling
If we fail to attach the stack key that means we've already attached the wire
key. That means the state could be found by other cores, and given that we then
free it, be used after free.
Fix this by not releasing the ID hashrow lock and key locks until after we've
removed the inserted key again, ensuring the state cannot be found by other
cores.
Reported by: markj
Submitted by: glebius
Reviewed by: glebius, markj
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D49550
netinet: Fix getcred sysctl handlers to do nothing if no input is given
These routines were all assuming that the sysctl handler has some new
value, but this is not the case. SYSCTL_IN() returns 0 in this
scenario, so they were all operating on an uninitialized address. This
is mostly harmless, but trips KMSAN checks, so let's fix them.
Reviewed by: zlei, rrs, glebius
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49348
(cherry picked from commit 3ff865c6a7948b2cfc01d7056c619145b696700a)
tcp: clear sendfile logging struct
The sendfile black box logging struct is much smaller than the
encompassing stack specific logging union. Be sure to clear the
trailing unused memory when logging.
Reviewed by: tuexen
Sponsored by: Netflix, Inc.
(cherry picked from commit 3bd1e85fc13cb90853046300dcaa31d63b45ee21)
sctp: fix double unlock in case adding a remote address fails
Thanks to glebius@ for pointing to the problem.
Reported by: syzbot+1d5c164f1c10de84ad8a at syzkaller.appspotmail.com
Fixes: 2d5c48eccd9f ("sctp: Tighten up locking around sctp_aloc_assoc()")
(cherry picked from commit e8623834ca29b562687db945bdd12a3e2fe4aeb1)
ixgbe: fix mailbox ack handling
Check if CTS bit is set in the mailbox message before waiting for ACK.
Otherwise ACK will never be received causing the function to timeout. Add
a note for ixgbe_write_mbx that it should be called while holding a lock.
Fixes: 6d243d2 ("net/ixgbe/base: introduce new mailbox API")
Cc: stable at dpdk.org
Signed-off-by: Norbert Ciosek <norbertx.ciosek at intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>
Obtained from: DPDK (1f119e4)
(cherry picked from commit 1580f8d9c1740e0c54554e6c185573d34f2dcf76)
igc(4): Fix attach for I226-K and LMVP devices
Summary:
The device IDs for these were in the driver's list of PCI ids to attach
to, but igc_set_mac_type() had never been setup to set the correct mac
type for these devices. Fix this by adding these IDs to the switch block
in order for them to be recognized by the driver instead of returning an
error.
This fixes the igc(4) attach for the I226-K LOM on the ASRock Z790
PG-ITX/TB4 motherboard, allowing it to be recognized and used.
Signed-off-by: Eric Joyner <erj at FreeBSD.org>
Reviewed by: kbowling@
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D49147
(cherry picked from commit 7ee310c80ea7b336972f53cc48b8c3d03029941e)
if_ovpn: fix use-after-free of mbuf
m_unshare() can return a new mbuf pointer. We update the 'm' pointer in
ovpn_udp_input(), but if we decide to pass on the packet (e.g. because it's for
an unknown peer) the caller (udp_append()) continues with the old 'm' pointer,
eventually resulting in a use-after-free.
Re-order operations in ovpn_udp_input() so that we don't modify the 'm' pointer
until we're committed to keeping the packet.
PR: 283426
Test case by: takahiro.kurosawa at gmail.com
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: add INVARIANTS visibility and use it to sidestep a panic
If this pans out we can still release the lock that we are supposed
to unlock here. We do not know the reason why this happens yet,
but we avoid the risk of chasing a pointer which is no longer dependable.
Also add mutex owned and recursed state checks in the output and
avoid unlocking if we no longer own the lock.
pf: add INVARIANTS visibility and use it to sidestep a panic
If this pans out wer can still release the lock that we're supposed
to unlock here. We do not know the reason and if the state is actually
still locked, but we avoid the risk of chasing a pointer which is no
longer dependable.
Also add mutex owned and recursed state checks in the output and
avoid unlocking if we no longer own the lock.
pf: add INVARIANTS visibility and use it to sidestep a panic
If this pans out wer can still release the lock that we're supposed
to unlock here. We do not know the reason and if the state is actually
still locked, but we avoid the risk of chasing a pointer which is no
longer dependable.
pf: do a lock dance in pf_unlink_state()
Both pf_test() and pf_test6() can end up in a panic while
executing PF_UNLOCK_STATE which points to the state being
removed while it is in use.
The PF_LOCK_STATE in the removal subroutine makes sure
that pf_test/pf_test6 are no longer holding the state
and we can safely test and set PFTM_UNLINK.
The other bits of the OpenBSD commit probably apply as well
but for now make sure that this particular panic comes to
and end.
Based on: https://github.com/openbsd/src/commit/9d9f4dc6c83
inpcb: Move the definition of struct inpcblbgroup to in_pcb_var.h
It's only needed for in_pcb.c and in6_pcb.c, so can go to the private
header.
No functional change intended.
Reported by: glebius
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
(cherry picked from commit ca94f92c23fd09b28ac3398657ae2ae9367bcdf5)
inpcb: Add FIB-aware inpcb lookup
Allow protocol layers to look up an inpcb belonging to a particular FIB.
This is indicated by setting INPLOOKUP_FIB; if it is set, the FIB to be
used is obtained from the specificed mbuf or ifnet.
No functional change intended.
Reviewed by: glebius, melifaro
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D48662
(cherry picked from commit da806e8db685eead02bc67888b16ebac6badb6b6)
inpcb: Add a flags parameter to in_pcbbind()
Add a flag, INPBIND_FIB, which means that the inpcb is local to its FIB
number. When this flag is specified, duplicate bindings are permitted,
so long as each FIB contains at most one inpcb bound to the same
address/port. If an inpcb is bound with this flag, it'll have the
INP_BOUNDFIB flag set.
No functional change intended.
Reviewed by: glebius
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D48661
(cherry picked from commit bbd0084baf7539c7042ce94f8c6770210f83f765)
inpcb: Imbue in(6)_pcblookup_local() with a FIB parameter
This is to enable a mode where duplicate inpcb bindings are permitted,
and we want to look up an inpcb with a particular FIB. Thus, add a
"fib" parameter to in_pcblookup() and related functions, and plumb it
through.
A fib value of RT_ALL_FIBS indicates that the lookup should ignore FIB
numbers when searching. Otherwise, it should refer to a valid FIB
number, and the returned inpcb should belong to the specific FIB. For
now, just add the fib parameter where needed, as there are several
layers to plumb through.
No functional change intended.
Reviewed by: glebius
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
[3 lines not shown]
inpcb: Further restrict binding to a port owned by a different UID
See commit 4f02a7d739b3 for more background.
I cannot see a good reason to continue ignoring mismatching UIDs when
binding to INADDR_ANY. Looking at the sdr.V2.4a7n sources (mentioned in
bugzilla PR 7713), there is a CANT_MCAST_BIND hack wherein the
application binds to INADDR_ANY instead of a multicast address, but
CANT_MCAST_BIND isn't defined for FreeBSD builds.
It seems unlikely that we still have a use-case for allowing sockets
from different UIDs to bind to the same port when binding to the
unspecified address. And, as noted in D47832, applications like sdr
would have been broken by the inverted SO_REUSEPORT check removed in
that revision, apparently without any bug reports. Let's break
compatibility and simply disallow this case outright.
Also, add some comments, remove a hack in a regression test which tests
this funtionality, and add a new regression test to exercise the
[8 lines not shown]
