netgraph/ng_ksocket: Enter epoch on NG_SEND_DATA_ONLY
The work queued by ng_send_fn() is intentionally processed
outside of the epoch in ngthread().
It is ng_ksocket's responsibility to enter epoch if it decides
to send data from such work.
Reviewed by: glebius
Fixes: 104827151e2a ("ng_iface: don't recursively enter epoch ...")
Differential Revision: https://reviews.freebsd.org/D60589
(cherry picked from commit 67be955f6bd5d5b51fdee407969d1a7cde156f65)
ng_socket: plug node reference leak
There is no need to reference node in its constructor, the framework
already granted us a reference. This extraneous reference was later given
back on socket detach. However, if node is destroyed before the socket,
the node was leaked. This leak was harmless until VIMAGE, where
vnet_netgraph_uninit() would cycle through all nodes and shut them down
expecting them to not exist after the shutdown.
Fixes: 19284374970533e1aa04020d4f840e8877ed6266
(cherry picked from commit 4d3cbeb7b407e127a5364f86039745068fbfc61f)
ipfw/nat64: Fix type confusion panic when using wrong NAT64 instance type
Add etlv type validation to ipfw_nat64clat() and ipfw_nat64stl() to
verify that the retrieved instance is actually a nat64clat instance
before use.
All NAT64 instance types share the same srvstate[] array but have
different struct layouts.
Without type validation, using the wrong instance type with
a handler causes type confusion and kernel panic.
Signed-off-by: Teddy Engel <engel.teddy at gmail.com>
PR: 292023
Reviewed by: pouria
Pull Request: https://github.com/freebsd/freebsd-src/pull/2259
(cherry picked from commit 2e6b22abf44d99b84abf17fe25ca2e8f89716c04)
nat64lsn: Fix type confusion panic when using wrong NAT64 instance type
When an ipfw rule references a NAT64 instance by name using
'nat64lsn', the kernel looks up the instance in the shared
srvstate[] array without verifying the instance type.
If the named instance is actually a nat64clat or nat64stl
instance (created with 'nat64clat' or 'nat64stl'), the code
incorrectly casts the instance to nat64lsn_instance and
dereferences the ->cfg pointer, which causes a kernel panic.
The root cause is that all NAT64 instance types share the same
srvstate[] array but have different struct layouts.
For nat64lsn_instance, the field after 'no' is a pointer to nat64lsn_cfg.
For nat64clat_cfg, the same offset contains an embedded nat64_config struct.
Fix by adding a type check after NAT64_LOOKUP() to verify that the
instance's etlv matches IPFW_TLV_NAT64LSN_NAME before proceeding.
If the type doesn't match, return IP_FW_DENY to reject the packet
safely rather than crashing.
[8 lines not shown]
carp: fix global demotion counter to VRRP advertisements
When net.inet.carp.preempt=1 and a physical interface goes down, the global
V_carp_demotion counter is incremented. For CARP this was already reflected in
outgoing advertisements via DEMOTE_ADVSKEW(), but VRRP sent the raw
sc_vrrp_prio unchanged, so demotion had no effect.
Add DEMOTE_VRRP_PRIO(), a macro analogous to DEMOTE_ADVSKEW():
It subtracts V_carp_demotion from the configured priority and clamps the result
to [0, 254]. Priority 0 is VRRPv3's "resign" signal and causes backups to
preempt immediately. Priority 255 (IP address owner) is never demoted.
Reviewed by: kp
Approved by: kp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D55558
(cherry picked from commit 9f71153aec0cb455cd49af6d4ca7e4c16fd45d7a)
pfil: Avoid potential mbuf tag leak
In '398254f9999e mbuf: simplify m_free' we removed tag processing
on m_free() of M_NOFREE mbufs. It is possible that a packet filter
could attach a tag to this stack mbuf and call m_free()
on it, meaning that 398254f9999e may have introduced a tag leak.
However,if a tag is attached without anyone calling m_free(), then
this leak was pre-existing.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D60686
Fixes: 398254f9999e
Sponsored by: Netflix
(cherry picked from commit f4ff995e361fa72cea240c4dbac2d0931965c80f)
mbuf: simplify m_free
The check for (M_PKTHDR|M_NOFREE) was added by np@ in
"91d1b03d3617 Merge r254736 from user/np/cxl_tuning."
in order to support a clever rx mode optimization used
by cxgbe at the time. That optimization was removed in
46e1e307edb6 several years ago. This check is otherwise
unneeded and adds an extraneous test to every mbuf free,
so let's remove it.
Reviewed by: glebius, np
Differential Revision: https://reviews.freebsd.org/D60686
Sponsored by: Netflix
(cherry picked from commit 398254f9999eb1af5f0842570111d584aaf8d01a)
[libc] Clean up redundant libc_errno includes and dependencies. (#237273)
- Replace `src/__support/libc_errno.h` with `hdr/errno_macros.h` in
pthread, spawn, stdio, threads, time, and test files that only use errno
constants.
- Remove unused `libc_errno.h` includes and
`libc.src.__support.libc_errno` dependencies from err, stdio,
syscall_wrappers, and tests.
- Remove redundant `libc.src.errno.errno` / `:errno` dependencies from
math, unistd, mman, test, and fuzzer targets in CMake and Bazel.
Assisted-by: Gemini
pf: fix a crash on sendfile()
The network layer must not pass unmapped (M_EXTPG) mbufs to if_output()
of network interfaces without IFCAP_MEXTPG. pf should convert these
mbufs by mb_unmapped_to_ext() for such interfaces but it didn't.
The problem had occurred on sendfile because sendfile system call
uses unmapped mbufs for the file data.
Reported by: feld
Reviewed by: kp, glebius
Differential Revision: https://reviews.freebsd.org/D58021
(cherry picked from commit 8a14fcd23a201944f3eb5086403d10cfe1fc128f)
netinet6: Fix check for pktinfo outgoing ifindex in route cache
lookup_route is only called for outgoing traffic, therefore
check nh_ifp index instead of nh_aifp as specified by RFC3542 sec 6.
Differential Revision: https://reviews.freebsd.org/D58544
(cherry picked from commit 7753a59fdf196fcbd8bb5706ad44bfc590bce0a9)
Revert "[SCEV] Try other implications when sign-flipped ones fail"
This reverts the code change of commit 8cd6cafe2e037733c4d7d9d768920453ed09b319.
It causes a large compile-time increase on loop chains where each loop's
A
IV starts at the previous loop's exit value.
Assisted-By: Claude
ktls: Fix capability checks in ktls_reset_receive_tag()
IFCAP2_RXTLS4 and IFCAP2_RXTLS6 are bit numbers, not masks, so
ktls_reset_receive_tag() tested if_capenable2 against 0 for IPv4 and against the
RXTLS4 bit for IPv6. An IPv4 connection with NIC receive TLS offload thus never
got a new receive tag after its packets moved to another interface, and fell
back to software decryption for good.
c721694 fixed the same checks in ktls_alloc_rcv_tag(); use IFCAP2_BIT() here
as well.
Fixes: fe8c78f ("ktls: Add full support for TLS RX offloading via network interface.")
Approved by: gallatin, kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D60757
(cherry picked from commit 32a981471c0147ea494745477434807cf8b6dadb)
ktls: Take the receiving interface of each packet in sbappend_ktls_rx()
sbappend_ktls_rx() read the receiving interface of each packet header it
demotes from the chain's first mbuf, whose header it had zeroed on the first
pass. A chain of two packets or more thus had no interface, and a change of
input interface went unnoticed: the TLS receive tag stayed on the old interface
until a later append of one packet.
Read it from the packet being demoted, as the decrypted mark is.
Fixes: fe8c78f0d202 ("ktls: Add full support for TLS RX offloading via network interface.")
Approved by: gallatin
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D60758
(cherry picked from commit c9599b80015a50e66c907dc667334a53bc234dab)
sendfile: Fix bug when using headers with SW KTLS offload
When using SW KTLS, we must account for the headers in sf_iodone()
in terms of either freeing or enqueuing them for TLS work.
Not doing so can lead to a situation where we enqueue only
the payload, and not the header, for encryption. Rather than
leaking the header, the socket is left "hung" with the header marked
M_NOTREADY.
Sponsored by: Netflix
Reviewed by: glebius, kib
Differential Revision: https://reviews.freebsd.org/D57134
(cherry picked from commit fd9af1e7084c550358d9598407f9ee7583e6a53f)
iwn: fix TX QoS AC -> TID mapping for A-MPDU selection
Map the packet QoS value to a TID before looking it up in the
per node + TID AMPDU state array.
The TX A-MPDU state used to be per-AC, but I changed it to be
per-TID because it /is/ negotiated per-TID. However this is
not aligned correctly and A-MPDU on eg the voice queue would
cause a mismatch and thus packets to get dropped.
(TIDs 8..15 are special and session based, not traffic QoS based.)
I noticed this because "ssh host" failed after a while, but
"telnet host 22" succeeded. It turned out that frames weren't
making it to the driver transmit path and I traced it
back to being dropped here. Traffic worked for a while until
A-MPDU TX was negotiated, and then all traffic on a TID
would fail until the 802.11 association was re-established.
[7 lines not shown]
Sparc: Remove redundant check for +/-0.5 immediates
getExactLog2Abs() == -1 already checks for +/-0.5, so drop the
separate isExactlyValue comparisons.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
iwm: mask closed_rb_num to the RX ring size
iwm_notif_intr() reads hw = le16toh(sc->rxq.stat->closed_rb_num) & 0xfff and
loops while (sc->rxq.cur != hw) without masking hw to the ring size (512 entries
for 9000-series MQ RX, 256 for legacy). If the hardware reports a value at or
above the ring size, cur never equals hw: the loop walks stale ring entries
indefinitely and the write-pointer update uses a bogus index. Linux iwlwifi
masks the value (5eae443eb5e2) and OpenBSD has done the same since 9000-series
support was added (3287dca4fa10).
This was found while debugging an iwm crash on another BSD using the same
driver lineage (DragonFly, upstream bug 3449)
Locally tested:
* 7260, 9260, STA mode
PR: kern/299427
Submitted by: David Bidner <david at crap.solutions>
[4 lines not shown]
mwl: return ENOMEM when rx buffer allocation fails
The malloc() failure path returned error, which is 0 at this point,
so callers would treat the allocation failure as success.
Return ENOMEM instead to correctly propagate the out-of-memory condition.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D42282
(cherry picked from commit fa75c1cc242665d123ef5bf2f4ced2e076b35450)
ath: fix ath_buf leak if ath_tx_tag_crypto() returns an error
If ath_tx_tag_crypto() returns an error, then ath_tx_normal_setup()
should consume the mbuf and return an error, so the caller knows to
free the ath_buf. But it wasn't.
This fixes issues I've seen locally where a an AP VAP constantly hits
error conditions (due to other RF/PHY/MAC chipset issues which I haven't
yet figured out) and encryption fails because the station goes away
whilst something's being queued.
Locally tested:
* AR9380, AP mode (2G HT20, 5G HT20, 5G HT40)
(cherry picked from commit f7aad20db59210a4411559d07976a48809b3b0a7)
cxgbe(4): Fix assertion in timer calibration
The calibration callout is stopped when the adapter is marked off limits
but not when the adapter is merely stopped.
Sponsored by: Chelsio Communications
(cherry picked from commit afe55ae68e742ea5e5eb9e78cf68d570d458cd0d)
