wireguard-linux/drivers/net, 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

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

net: stmmac: Disable S-Tag processing on dwmac4

2026-10-05T23:36:45Z

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 a 802.1ad outer tag are incorrectly passed up the stack as having an 802.1Q tag. This causes QinQ ping between two hosts to fail. vlan_rx_hw() is shared by dwxgmac2 and dwmac4: on dwxgmac2 the tag type is available in the RDES3 write-back descriptor (the ET_LT field), so the outer tag type can be determined based on that info. However, dwmac4 doesn't seem to provide the tag type. The Length/Type field in RDES3 only indicates whether the packet is single or double-tagged, not which tag type was stripped. Since dwmac4 cannot report the stripped tag type, it cannot support hardware S-Tag stripping correctly. Therefore, restrict the NETIF_F_HW_VLAN_STAG_RX and NETIF_F_HW_VLAN_STAG_FILTER advertisement to dwxgmac2 only. With this, 802.1ad tags are left in place and handled by the software VLAN path. Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping") Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-6-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski

net: stmmac: Do not advertise S-VLAN stripping when it is disabled

2026-10-05T23:36:45Z

C-VLAN and S-VLAN tag stripping are both controlled by the EVLS bit, so disabling rx-vlan-offload also disables S-VLAN tag stripping. However, rx-vlan-stag-hw-parse keeps being advertised as enabled: root@rzv2h-evk:~# ethtool -K end1 rx-vlan-offload off root@rzv2h-evk:~# ethtool -k end1 | grep -i vlan rx-vlan-offload: off tx-vlan-offload: off [fixed] rx-vlan-filter: on [fixed] vlan-challenged: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: on [fixed] rx-vlan-stag-filter: on [fixed] Fix this inconsistency by making NETIF_F_HW_VLAN_STAG_RX follow NETIF_F_HW_VLAN_CTAG_RX. Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping") Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-5-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski