[PATCH net 0/3] WireGuard fixes for 7.3-rc7

[PATCH net 0/3] WireGuard fixes for 7.3-rc7

[Jason A. Donenfeld]

Hi Jakub,

This series contains two important WireGuard fixes and one trivial
cleanup.

1) Remove an unused variable.

2) Stop zeroing out skb->tstamp_type when encapsulating packets, so that
   fq behaves correctly, from Ramses de Norre.

3) Make sure handshake state isn't swapped out while locks are
   released, reported by Jérémy Jean.

Please apply these.

Thanks,
Jason


Jason A. Donenfeld (2):
  wireguard: noise: remove unused variable
  wireguard: noise: reject response consumption after intermediate
    initiation

Ramses de Norre (1):
  wireguard: queueing: preserve tstamp_type when encapsulating packet

 drivers/net/wireguard/noise.c    | 9 ++++-----
 drivers/net/wireguard/queueing.h | 2 ++
 2 files changed, 6 insertions(+), 5 deletions(-)

-- 
2.56.0

[PATCH net 1/3] wireguard: noise: remove unused variable

[Jason A. Donenfeld]

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 <Jason@zx2c4.com>
---
 drivers/net/wireguard/noise.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireguard/noise.c b/drivers/net/wireguard/noise.c
index 9c0a09bf6c95..63f41836ebd5 100644
--- a/drivers/net/wireguard/noise.c
+++ b/drivers/net/wireguard/noise.c
@@ -736,7 +736,6 @@ wg_noise_handshake_consume_response(struct message_handshake_response *src,
 	u8 chaining_key[NOISE_HASH_LEN];
 	u8 e[NOISE_PUBLIC_KEY_LEN];
 	u8 ephemeral_private[NOISE_PUBLIC_KEY_LEN];
-	u8 static_private[NOISE_PUBLIC_KEY_LEN];
 	u8 preshared_key[NOISE_SYMMETRIC_KEY_LEN];
 
 	down_read(&wg->static_identity.lock);
@@ -807,7 +806,6 @@ wg_noise_handshake_consume_response(struct message_handshake_response *src,
 	memzero_explicit(hash, NOISE_HASH_LEN);
 	memzero_explicit(chaining_key, NOISE_HASH_LEN);
 	memzero_explicit(ephemeral_private, NOISE_PUBLIC_KEY_LEN);
-	memzero_explicit(static_private, NOISE_PUBLIC_KEY_LEN);
 	memzero_explicit(preshared_key, NOISE_SYMMETRIC_KEY_LEN);
 	up_read(&wg->static_identity.lock);
 	return ret_peer;
-- 
2.56.0

[PATCH net 2/3] wireguard: queueing: preserve tstamp_type when encapsulating packet

[Jason A. Donenfeld]

From: Ramses de Norre <ramses@well-founded.dev>

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 <ramses@well-founded.dev>
Reviewed-by: Toke Høiland-Jørgensen <toke@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
 drivers/net/wireguard/queueing.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 79b6d70de236..663b19b78395 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -78,12 +78,14 @@ static inline void wg_reset_packet(struct sk_buff *skb, bool encapsulating)
 	u8 l4_hash = skb->l4_hash;
 	u8 sw_hash = skb->sw_hash;
 	u32 hash = skb->hash;
+	u8 tstamp_type = skb->tstamp_type;
 	skb_scrub_packet(skb, true);
 	memset(&skb->headers, 0, sizeof(skb->headers));
 	if (encapsulating) {
 		skb->l4_hash = l4_hash;
 		skb->sw_hash = sw_hash;
 		skb->hash = hash;
+		skb->tstamp_type = tstamp_type;
 	}
 	skb->queue_mapping = 0;
 	skb->nohdr = 0;
-- 
2.56.0

[PATCH net 3/3] wireguard: noise: reject response consumption after intermediate initiation

[Jason A. Donenfeld]

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 <Jeremy.Jean@oss.cyber.gouv.fr>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
 drivers/net/wireguard/noise.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireguard/noise.c b/drivers/net/wireguard/noise.c
index 63f41836ebd5..428d3afe3ce4 100644
--- a/drivers/net/wireguard/noise.c
+++ b/drivers/net/wireguard/noise.c
@@ -783,10 +783,11 @@ wg_noise_handshake_consume_response(struct message_handshake_response *src,
 
 	/* Success! Copy everything to peer */
 	down_write(&handshake->lock);
-	/* It's important to check that the state is still the same, while we
-	 * have an exclusive lock.
+	/* Check that the state is the same and that this is still the
+	 * initiation we started with, while we have an exclusive lock.
 	 */
-	if (handshake->state != state) {
+	if (handshake->state != state ||
+	    crypto_memneq(handshake->ephemeral_private, ephemeral_private, NOISE_PUBLIC_KEY_LEN)) {
 		up_write(&handshake->lock);
 		goto fail;
 	}
-- 
2.56.0

Re: [PATCH net 0/3] WireGuard fixes for 7.3-rc7

[Jakub Kicinski]

On Thu,  8 Oct 2026 14:59:13 +0200 Jason A. Donenfeld wrote:
> 1) Remove an unused variable.
> 
> 2) Stop zeroing out skb->tstamp_type when encapsulating packets, so that
>    fq behaves correctly, from Ramses de Norre.
> 
> 3) Make sure handshake state isn't swapped out while locks are
>    released, reported by Jérémy Jean.

Ima sort these to trees, Linus's been onto us.

Re: [PATCH net 0/3] WireGuard fixes for 7.3-rc7

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu,  8 Oct 2026 14:59:13 +0200 you wrote:
> Hi Jakub,
> 
> This series contains two important WireGuard fixes and one trivial
> cleanup.
> 
> 1) Remove an unused variable.
> 
> [...]

Here is the summary with links:
  - [net,1/3] wireguard: noise: remove unused variable
    (no matching commit)
  - [net,2/3] wireguard: queueing: preserve tstamp_type when encapsulating packet
    https://git.kernel.org/netdev/net/c/65ab9de4bdd4
  - [net,3/3] wireguard: noise: reject response consumption after intermediate initiation
    https://git.kernel.org/netdev/net/c/d0305f8d9002

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net 0/3] WireGuard fixes for 7.3-rc7

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu,  8 Oct 2026 14:59:13 +0200 you wrote:
> Hi Jakub,
> 
> This series contains two important WireGuard fixes and one trivial
> cleanup.
> 
> 1) Remove an unused variable.
> 
> [...]

Here is the summary with links:
  - [net,1/3] wireguard: noise: remove unused variable
    https://git.kernel.org/netdev/net-next/c/3f65f6ff8594
  - [net,2/3] wireguard: queueing: preserve tstamp_type when encapsulating packet
    (no matching commit)
  - [net,3/3] wireguard: noise: reject response consumption after intermediate initiation
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html