wireguard-linux/tools/testing/selftests/net, branch devel

selftests: net: bridge: add MRC and QQIC field encoding tests

2026-05-05T02:09:42Z

Enhance vlmc_query_intvl_test and vlmc_query_response_intvl_test in bridge_vlan_mcast.sh to validate IGMPv3/MLDv2 protocol compliance for MRC and QQIC field encoding across both linear and exponential ranges. TEST: Vlan multicast snooping enable [ OK ] TEST: Vlan mcast_query_interval global option default value [ OK ] TEST: Number of tagged IGMPv2 general query [ OK ] TEST: IGMPv3 QQIC linear value 60(s) [ OK ] TEST: MLDv2 QQIC linear value 60(s) [ OK ] TEST: IGMPv3 QQIC non linear value 160(s) [ OK ] TEST: MLDv2 QQIC non linear value 160(s) [ OK ] TEST: Vlan mcast_query_response_interval global option default value [ OK ] TEST: IGMPv3 MRC linear value of 60(x0.1s) [ OK ] TEST: MLDv2 MRC linear value of 24000(ms) [ OK ] TEST: IGMPv3 MRC non linear value of 240(x0.1s) [ OK ] TEST: MLDv2 MRC non linear value of 48000(ms) [ OK ] Reviewed-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Signed-off-by: Ujjal Roy Link: https://patch.msgid.link/20260502131907.987-6-royujjal@gmail.com Signed-off-by: Jakub Kicinski

net: selftests: add getsockopt_iter regression tests

2026-05-05T02:02:30Z

Add a single kselftest covering the proto_ops getsockopt_iter conversions for AF_NETLINK and AF_VSOCK, using one fixture per protocol: netlink: NETLINK_PKTINFO covers the flag-style int path (exact size, oversize clamp, undersize -EINVAL); NETLINK_LIST_MEMBERSHIPS covers the size-discovery path that always reports the required buffer length back via optlen, even when the user buffer is too small to receive any group bits. vsock: SO_VM_SOCKETS_BUFFER_SIZE covers the u64 path (exact size, oversize clamp, undersize -EINVAL). Each fixture also exercises an unknown optname and a bogus level so the returned-length / errno semantics preserved by the sockopt_t conversion are pinned down. Signed-off-by: Breno Leitao Reviewed-by: Bobby Eshleman Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260501-getsock_one-v1-3-810ce23ea70e@debian.org Signed-off-by: Jakub Kicinski

selftests/net: packetdrill: add tcp_syncookies_ip[46]_9k

2026-05-01T03:54:09Z

These tests check syncookie mode is able to reconstruct some client options when TCP TS are used: - wscale option. - sackOK. - MSS (in a limited way, especially for IPv4). - ECN : not enabled. Note that IPv4 and IPv6 have different msstab[] values: IPv4 msstab[4] = { 536, 1300, 1440, 1460 } IPv6 msstab[4] = { 1280 - 60, 1480 - 60, 1500 - 60, 9000 - 60 } IPv4 is currently capping SND_MSS to 1460, even on a 9K MTU network. Signed-off-by: Eric Dumazet Reviewed-by: Neal Cardwell Link: https://patch.msgid.link/20260430021444.2929534-1-edumazet@google.com Signed-off-by: Jakub Kicinski

selftests: net: Add tests for ARP probe and DAD NS handling

2026-05-01T00:35:17Z

Add test cases to verify that ARP probes and DAD Neighbor Solicitations are handled correctly by the bridge neighbor suppression feature. When neighbor suppression is enabled on a bridge VXLAN port, the bridge should reply to ARP/NS messages on behalf of remote hosts when both FDB and neighbor entries exist, and the answer is known. However, when either the FDB or the neighbor exists, ARP probes / DAD NS should be treated like regular ARP requests / NS and flood to VXLAN. Add two new test functions: neigh_suppress_arp_probe(): Tests ARP probe handling by triggering duplicate address detection using arping -D. Verifies that probes are flooded when the bridge doesn't know the answer, and suppressed when FDB and neighbor entries exist. neigh_suppress_dad_ns(): Tests DAD NS handling by constructing DAD NS packets using mausezahn and verifies correct flooding/suppression behavior. Before the previous patch: $ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns" Per-port ARP probe suppression ------------------------------ TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: ARP probe suppression [FAIL] TEST: FDB and neighbor entry installation [ OK ] TEST: arping [FAIL] TEST: ARP probe suppression [FAIL] TEST: neighbor removal [ OK ] TEST: ARP probe suppression [FAIL] TEST: "neigh_suppress" is off [ OK ] TEST: ARP probe suppression [FAIL] Per-port DAD NS suppression --------------------------- TEST: DAD NS suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: DAD NS suppression [FAIL] TEST: FDB and neighbor entry installation [ OK ] TEST: DAD NS suppression [FAIL] TEST: neighbor removal [ OK ] TEST: DAD NS suppression [FAIL] TEST: DAD NS proxy NA reply [FAIL] TEST: "neigh_suppress" is off [ OK ] TEST: DAD NS suppression [FAIL] Tests passed: 10 Tests failed: 10 After the previous patch: $ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns" Per-port ARP probe suppression ------------------------------ TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: ARP probe suppression [ OK ] TEST: FDB and neighbor entry installation [ OK ] TEST: arping [ OK ] TEST: ARP probe suppression [ OK ] TEST: neighbor removal [ OK ] TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is off [ OK ] TEST: ARP probe suppression [ OK ] Per-port DAD NS suppression --------------------------- TEST: DAD NS suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: DAD NS suppression [ OK ] TEST: FDB and neighbor entry installation [ OK ] TEST: DAD NS suppression [ OK ] TEST: neighbor removal [ OK ] TEST: DAD NS suppression [ OK ] TEST: DAD NS proxy NA reply [ OK ] TEST: "neigh_suppress" is off [ OK ] TEST: DAD NS suppression [ OK ] Tests passed: 20 Tests failed: 0 Signed-off-by: Danielle Ratson Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260429062405.1386417-3-danieller@nvidia.com Signed-off-by: Jakub Kicinski

net/tcp-ao: Use crypto library API instead of crypto_ahash

2026-04-30T07:38:56Z

Currently the kernel's TCP-AO implementation does the MAC and KDF computations using the crypto_ahash API. This API is inefficient and difficult to use, and it has required extensive workarounds in the form of per-CPU preallocated objects (tcp_sigpool) to work at all. Let's use lib/crypto/ instead. This means switching to straightforward stack-allocated structures, virtually addressed buffers, and direct function calls. It also means removing quite a bit of error handling. This makes TCP-AO quite a bit faster. This also enables many additional cleanups, which later commits will handle: removing tcp-sigpool, removing support for crypto_tfm cloning, removing more error handling, and replacing more dynamically-allocated buffers with stack buffers based on the now-statically-known limits. Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers Link: https://patch.msgid.link/20260427172727.9310-3-ebiggers@kernel.org Signed-off-by: Paolo Abeni

net/tcp-ao: Drop support for most non-RFC-specified algorithms

2026-04-30T07:38:56Z

RFC 5926 (https://datatracker.ietf.org/doc/html/rfc5926) specifies the use of AES-128-CMAC and HMAC-SHA1 with TCP-AO. This includes a specification for how traffic keys shall be derived for each algorithm. Support for any other algorithms with TCP-AO isn't standardized, though an expired Internet Draft (a work-in-progress document, not a standard) from 2019 does propose adding HMAC-SHA256 support: https://datatracker.ietf.org/doc/html/draft-nayak-tcp-sha2-03 Since both documents specify the KDF for each algorithm individually, it isn't necessarily clear how any other algorithm should be integrated. Nevertheless, the Linux implementation of TCP-AO allows userspace to specify the MAC algorithm as a string tcp_ao_add::alg_name naming either "cmac(aes128)" or an arbitrary algorithm in the crypto_ahash API. The set of valid strings is undocumented. The implementation assumes that "cmac(aes128)" is the only algorithm that requires an entropy extraction step and that all algorithms accept keys with length equal to the untruncated MAC; thus, arbitrary HMAC algorithms probably do work, but some other MAC algorithms like AES-256-CMAC have never actually worked. Unfortunately, this undocumented string allows many obsolete, insecure, or redundant algorithms. For example, "hmac(md5)" and the non-cryptographic "crc32" are accepted. It also ties the implementation to crypto_ahash and requires that most memory be dynamically allocated, making the implementation unnecessarily complex and inefficient. Still furthermore, this implementation requires the crypto API to support "transformation cloning", whose only user is this feature. Fortunately, it's very likely that only a few algorithms are actually used in practice. Let's restrict the set of allowed algorithms to "cmac(aes128)" (or "cmac(aes)" with keylen=16), "hmac(sha1)", and "hmac(sha256)". The first two are the actually standard ones, while HMAC-SHA256 seems like a reasonable algorithm to continue supporting as a Linux extension, considering the Internet Draft for it and the fact that SHA-256 is the usual choice of upgrade from the outdated SHA-1. If any other algorithm ever turns out to be needed, e.g. HMAC-SHA512, it can of course be (re-)added in library form. However, note that the TCP options space limits TCP-AO MACs to 20 bytes (160 bits) anyway, which limits the potential benefit of any further upgrade to the algorithm. Reviewed-by: Ard Biesheuvel Signed-off-by: Eric Biggers Link: https://patch.msgid.link/20260427172727.9310-2-ebiggers@kernel.org Signed-off-by: Paolo Abeni

selftests/net: packetdrill: cover RFC 5961 5.2 challenge ACK on both edges

2026-04-23T18:04:01Z

RFC 5961 Section 5.2 / RFC 793 Section 3.9 require a challenge ACK whenever an incoming SEG.ACK falls outside [SND.UNA - MAX.SND.WND, SND.NXT]. There is currently no packetdrill coverage for either edge. Add tcp_rfc5961_ack-out-of-window.pkt, which in a single passive-open connection exercises: - Upper edge (SEG.ACK > SND.NXT): peer ACKs data that was never sent before the server has transmitted anything. - Lower edge (SEG.ACK < SND.UNA - MAX.SND.WND): after the server has sent 2000 bytes (the peer-advertised rwnd forces two 1000-byte segments, both acknowledged), peer sends an ACK that is older than the acceptable window. Both cases must elicit a challenge ACK . The per-socket RFC 5961 Section 7 rate limit is disabled for the duration of the test so that both challenge ACKs can fire back-to-back. Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260422123605.320000-3-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski

tcp: send a challenge ACK on SEG.ACK > SND.NXT

2026-04-23T18:04:00Z

RFC 5961 Section 5.2 validates an incoming segment's ACK value against the range [SND.UNA - MAX.SND.WND, SND.NXT] and states: "All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back." Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation") opted Linux into this mitigation and implements the challenge ACK on the lower side (SEG.ACK < SND.UNA - MAX.SND.WND), but the symmetric upper side (SEG.ACK > SND.NXT) still takes the pre-RFC-5961 path and silently returns SKB_DROP_REASON_TCP_ACK_UNSENT_DATA, even though RFC 793 Section 3.9 (now RFC 9293 Section 3.10.7.4) has always required: "If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return." Complete the mitigation by sending a challenge ACK on that branch, reusing the existing tcp_send_challenge_ack() path which already enforces the per-socket RFC 5961 Section 7 rate limit via __tcp_oow_rate_limited(). FLAG_NO_CHALLENGE_ACK is honoured for symmetry with the lower-edge case. Update the existing tcp_ts_recent_invalid_ack.pkt selftest, which drives this exact path, to consume the new challenge ACK. Fixes: 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation") Signed-off-by: Jiayuan Chen Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260422123605.320000-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski

selftests: mptcp: add a check for sndbuf of S/C

2026-04-23T11:20:17Z

Add a new chk_sndbuf() helper to diag.sh that extracts the sndbuf (the 'tb' field from 'ss -m' skmem output) for both server and client MPTCP sockets, and verifies they are equal. Without the previous patch, it will fail: ''' 07 ....chk sndbuf server/client [FAIL] sndbuf S=20480 != C=2630656 ''' Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260420-net-mptcp-sync-sndbuf-accept-v1-2-e3523e3aeb44@kernel.org Signed-off-by: Paolo Abeni

selftests: net: add team_bridge_macvlan rx_mode test

2026-04-21T10:50:25Z

Add a test that exercises the ndo_change_rx_flags path through a macvlan -> bridge -> team -> dummy stack. This triggers dev_uc_add under addr_list_lock which flips promiscuity on the lower device. With the new work queue approach, this must not deadlock. Link: https://lore.kernel.org/netdev/20260214033859.43857-1-jiayuan.chen@linux.dev/ Reviewed-by: Breno Leitao Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20260416185712.2155425-15-sdf@fomichev.me Signed-off-by: Paolo Abeni