wireguard-linux, branch stable

wireguard: noise: reject response consumption after intermediate initiation

2026-10-08T12:51:27Z

Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on down_write(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same down_write(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls up_write(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire down_write(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A. Thread A Thread B Thread C down_read() sA = handshake->state memcpy(cA, handshake->crypto) up_read() if (sA != 1) goto fail slow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB) down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail memcpy(handshake->crypto, cB) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() This seems basically impossible to hit in a meaningful way in practice, but ensure that it absolutely cannot happen by comparing the ephemeral private key that's on the stack with the latest one that the peer's handshake state has. Cc: stable@vger.kernel.org Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Reported-by: Jérémy Jean Signed-off-by: Jason A. Donenfeld

wireguard: queueing: preserve tstamp_type when encapsulating packet

2026-10-06T15:17:21Z

Sending traffic through a wireguard tunnel on a host using the fq qdisc fills the log with: fq: likely mono tstamp with tstamp_type 0 An skb carries a timestamp in skb->tstamp and, separately, a skb->tstamp_type field recording which clock that timestamp came from. The two have to agree. When wireguard encapsulates a packet it calls wg_reset_packet(), which clears the fields that must not leak from the inner packet into the tunnel packet. It does so in two steps: skb_scrub_packet(skb, true); memset(&skb->headers, 0, sizeof(skb->headers)); skb_scrub_packet() deliberately keeps skb->tstamp when it holds a monotonic timestamp: that value is the time the packet is scheduled to be sent, and the qdisc still needs it. The memset then zeroes skb->tstamp_type, because that field sits inside the headers group while skb->tstamp does not. The packet therefore leaves wireguard carrying a monotonic timestamp labelled as a realtime one. Nothing noticed until commit c4f796c4f16b ("net_sched: sch_fq: convert skb->tstamp if not monotonic"): fq used to assume every timestamp was monotonic. It now consults tstamp_type, spots the mismatch, warns, and falls back to treating the value as monotonic. Pacing still ends up correct, so the log spam is the actual problem. Save tstamp_type before the memset and restore it when encapsulating, next to the hash fields that are already carried over this way. When decapsulating it stays zeroed, which is right: an incoming packet's timestamp is a realtime receive timestamp. Fixes: d98d58a00261 ("net: Set skb->mono_delivery_time and clear it after sch_handle_ingress()") Signed-off-by: Ramses de Norre Reviewed-by: Toke Høiland-Jørgensen Reviewed-by: Eric Dumazet Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld

wireguard: noise: remove unused variable

2026-10-06T15:17:21Z

This is a harmless artifact from early pre-release wireguard development. These days, static_private is read from a shared data structure under a read lock directly, and it doesn't need to be copied to the stack. So remove the unused variable. Signed-off-by: Jason A. Donenfeld

Revert "net: stmmac: propagate PTP addend and system time programming errors"

2026-10-06T01:19:42Z

This reverts commit 232d49dd4b40a666283de9e722899f088ed581b2. Anirudh reports a regression from this change. It is not appropriate for net this late in the release cycle in the first place, so let's revert and revisit in net-next. Reported-by: Anirudh Srinivasan Link: https://lore.kernel.org/CAEev2e8+fr1tJnSErD+2TtLDw5fGJbQOMcM5eefMnLyFUR+m7w@mail.gmail.com Fixes: 232d49dd4b40 ("net: stmmac: propagate PTP addend and system time programming errors") Signed-off-by: Jakub Kicinski

net: airoha: Add retry mechanism to airoha_qdma_set_trtcm_param()

2026-10-06T00:45:01Z

CPU accesses QDMA via the bus. When multiple modules are using the bus simultaneously, CPU access to QDMA may encounter bus timeouts and fails, resulting in QDMA configuration failures and potentially causing packet transmission issues. In order to mitigate the issue, introduce a retry mechanism to airoha_qdma_set_trtcm_param routine in order to ensure the configuration is correctly applied to the hardware. It's enough to try a second time for the TRTCM config to be actually applied to make sure we are not in the middle of bucket handling as it does operate on fixed time slot internally. Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support") Signed-off-by: Leto Liu (刘涛) [ improve commit description, drop memory block, apply better loop logic] Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20260930065855.46171-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski

Merge branch 'gve-various-xdp-fixes'

2026-10-06T00:00:07Z

Joshua Washington says: ==================== gve: various XDP fixes This patch series consists of a number of small XDP-related fixes. These changes are split off from https://lore.kernel.org/20260922194533.631387-1-joshwash@google.com in an effort to prevent blocking relatively simple fixes on more complex fixes that will need more feedback to merge. A summary of the changes: 1) fix an issue where XSK buffers that have not been processed are leaked when disabling XSK pools 2) fix an XSK buffer leak when an RX error descriptor comes back from the hardware 3) fix a deadlock introduced by attempting to acquire the netdev lock after it has already been acquired ==================== Link: https://patch.msgid.link/20260930214735.3288780-1-joshwash@google.com Signed-off-by: Jakub Kicinski

gve: fix napi_disable deadlock when attempting to disable XSK pools

2026-10-05T23:59:56Z

When disabling XSK pools, GVE calls the unlocked versions of napi_disable and napi_enable. However, the netdev lock has already been acquired before ndo_bpf is called because GVE supports queue management ops. Calling the unlocked versions of napi_disable/enable results in a deadlock when attempting to disable XSK pools, as the thread attempts to re-acquire a lock it already holds. Update the NAPI calls to use the locked versions. This issue was found in production. Fixes: 606048cbd834 ("net: designate XSK pool pointers in queues as "ops protected"") Cc: stable@vger.kernel.org Reviewed-by: Harshitha Ramamurthy Reviewed-by: Jordan Rhee Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-4-joshwash@google.com Signed-off-by: Jakub Kicinski

gve: fix XSK buffer leak on error descriptor

2026-10-05T23:59:36Z

When the error bit is set in the RX completion descriptor, the buf_state and its attached buffer should be freed. In the case of AF_XDP ZC, the XSK buffer was not freed, leading to a leak. This issue was caught by LLM. Fixes: c1fffc5d66a7 ("gve: implement DQO RX datapath and control path for AF_XDP zero-copy") Cc: stable@vger.kernel.org Reviewed-by: Jordan Rhee Reviewed-by: Tim Hostetler Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-3-joshwash@google.com Signed-off-by: Jakub Kicinski

gve: fix XSK buffer leak when rings are stopped

2026-10-05T23:59:18Z

GVE does not free XSK buffers when resetting ring state as a part of stopping queues. This causes all XSK buffers which are posted to the NIC to be leaked. Free XSK buffers attached to an allocated buf_state when stopping rings. This issue was hit in production. Fixes: c1fffc5d66a7 ("gve: implement DQO RX datapath and control path for AF_XDP zero-copy") Cc: stable@vger.kernel.org Reviewed-by: Tim Hostetler Reviewed-by: Jordan Rhee Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-2-joshwash@google.com Signed-off-by: Jakub Kicinski

Merge branch 'net-stmmac-fix-double-vlan-802-1ad-tag-handling'

2026-10-05T23:36:45Z

Ovidiu Panait says: ==================== net: stmmac: Fix double VLAN 802.1ad tag handling Currently, hardware VLAN stripping is broken for 802.1ad tags. vlan_rx_hw() hardcodes ETH_P_8021Q when putting the hardware tag into the skb, rather than using the actual protocol from the packet. Because of this, packets that contain an 802.1ad outer tag are incorrectly passed up the stack as having an 802.1Q tag. This issue was observed on the Renesas RZ/V2H platform (which has a dwmac4 IP), when testing QinQ ping: # DUT ip link add link end0 name end0.100 type vlan proto 802.1ad id 100 ip link add link end0.100 name end0.100.200 type vlan proto 802.1q id 200 ip addr add 172.16.3.2/24 dev end0.100.200 ip link set end0 up ip link set end0.100 up ip link set end0.100.200 up # Peer ip link add link eth0 name eth0.100 type vlan proto 802.1ad id 100 ip link add link eth0.100 name eth0.100.200 type vlan proto 802.1q id 200 ip addr add 172.16.3.1/24 dev eth0.100.200 ip link set eth0 up ip link set eth0.100 up ip link set eth0.100.200 up ping 172.16.3.2 -- FAIL -- Note that this series only fixes the issue on dwmac4. dwxgmac2 has the same issue but I do not have access to hw to test on. Since dwmac4 does not expose the tag type in the RDES3 descriptor, it cannot support hardware S-Tag stripping correctly. This series disables S-tag stripping for it, so the 802.1ad tags are left in place and are handled by the software VLAN path. ==================== Link: https://patch.msgid.link/20260928203441.34876-1-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski