From leeloored at gmx.com  Thu Sep  3 18:21:33 2026
From: leeloored at gmx.com (Kent Friis)
Date: Thu, 3 Sep 2026 20:21:33 +0200
Subject: Remove endpoint
Message-ID: <20260903202133.2383ecd75a9b94dec9dc3974@gmx.com>

I can specify a peer with no endpoint in wg0.conf. It will then simply
not have an endpoint until it either receives a packet from the peer,
or one is specified with wg set ... endpoint ip:port.

Now, I'm on a mobile connection, so when I log off, I want to remove
the endpoint ip again so the "server" doesn't transmit stray packets
to a mobile ip address.

I tried

wg set wg0 peer XXX endpoint 0:0
wg set wg0 peer XXX endpoint off
wg set wg0 peer XXX endpoint none
wg set wg0 peer XXX endpoint ""

The first one sets the endpoint to 0.0.0.0 port 0, which is first of
all, usually treated as a broadcast address, and second, AFAIK there is
no port zero.

The other three give errors.

How to remove the endpoint while keeping the rest of the configuration?

/Kent

From max.schulze at online.de  Thu Sep  3 18:32:15 2026
From: max.schulze at online.de (Max Schulze)
Date: Thu, 3 Sep 2026 20:32:15 +0200
Subject: Remove endpoint
In-Reply-To: <20260903202133.2383ecd75a9b94dec9dc3974@gmx.com>
References: <20260903202133.2383ecd75a9b94dec9dc3974@gmx.com>
Message-ID: <721ba96f-b408-4e82-9eec-70df9c29279e@online.de>

Have you seen

wg set wg0 peer XXX remove

?


Am 03.09.26 um 20:21 schrieb Kent Friis:
> I can specify a peer with no endpoint in wg0.conf. It will then simply
> not have an endpoint until it either receives a packet from the peer,
> or one is specified with wg set ... endpoint ip:port.
> 
> Now, I'm on a mobile connection, so when I log off, I want to remove
> the endpoint ip again so the "server" doesn't transmit stray packets
> to a mobile ip address.
> 
> I tried
> 
> wg set wg0 peer XXX endpoint 0:0
> wg set wg0 peer XXX endpoint off
> wg set wg0 peer XXX endpoint none
> wg set wg0 peer XXX endpoint ""
> 
> The first one sets the endpoint to 0.0.0.0 port 0, which is first of
> all, usually treated as a broadcast address, and second, AFAIK there is
> no port zero.
> 
> The other three give errors.
> 
> How to remove the endpoint while keeping the rest of the configuration?
> 
> /Kent


From leeloored at gmx.com  Thu Sep  3 18:40:30 2026
From: leeloored at gmx.com (Kent Friis)
Date: Thu, 3 Sep 2026 20:40:30 +0200
Subject: Remove endpoint
In-Reply-To: <721ba96f-b408-4e82-9eec-70df9c29279e@online.de>
References: <20260903202133.2383ecd75a9b94dec9dc3974@gmx.com>
 <721ba96f-b408-4e82-9eec-70df9c29279e@online.de>
Message-ID: <20260903204030.ee330075df0fba808f1fb065@gmx.com>

That removes the entire peer, not just the endpoint.

On Thu, 3 Sep 2026 20:32:15 +0200
Max Schulze <max.schulze at online.de> wrote:

> Have you seen
> 
> wg set wg0 peer XXX remove
> 
> ?
> 
> 
> Am 03.09.26 um 20:21 schrieb Kent Friis:
> > I can specify a peer with no endpoint in wg0.conf. It will then simply
> > not have an endpoint until it either receives a packet from the peer,
> > or one is specified with wg set ... endpoint ip:port.
> > 
> > Now, I'm on a mobile connection, so when I log off, I want to remove
> > the endpoint ip again so the "server" doesn't transmit stray packets
> > to a mobile ip address.
> > 
> > I tried
> > 
> > wg set wg0 peer XXX endpoint 0:0
> > wg set wg0 peer XXX endpoint off
> > wg set wg0 peer XXX endpoint none
> > wg set wg0 peer XXX endpoint ""
> > 
> > The first one sets the endpoint to 0.0.0.0 port 0, which is first of
> > all, usually treated as a broadcast address, and second, AFAIK there is
> > no port zero.
> > 
> > The other three give errors.
> > 
> > How to remove the endpoint while keeping the rest of the configuration?
> > 
> > /Kent
> 

From netdev-bot+sashiko at kernel.org  Mon Sep  7 06:14:39 2026
From: netdev-bot+sashiko at kernel.org (netdev-bot+sashiko at kernel.org)
Date: Mon, 07 Sep 2026 06:14:39 +0000
Subject: [PATCH net] wireguard: wait for per-peer crypto during removal
In-Reply-To: <20260902-fix-wg-peer-removal-v1-1-7a0190f5cdb1@cloudflare.com>
References: <20260902-fix-wg-peer-removal-v1-1-7a0190f5cdb1@cloudflare.com>
Message-ID: <178876167936.219967.11338017664970925838@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 ? High: 1 ? Medium: 0 ? Low: 0

- [High] Teardown can strand decrypted packets in `peer->rx_queue`,
  permanently leaking the skbs and the peer.

--

wireguard: wait for per-peer crypto during removal

This replaces the two device-wide flush_workqueue(packet_crypt_wq) calls and
the flush_workqueue(handshake_send_wq) call in peer_remove_after_dead() with
a new per-peer packet_crypt_pending counter plus flush_work() on the peer's
own transmit_packet_work and transmit_handshake_work.

> diff --git a/drivers/net/wireguard/peer.c b/drivers/net/wireguard/peer.c
> index 1cb502a932e0..f7a9c437b5b8 100644
> --- a/drivers/net/wireguard/peer.c
> +++ b/drivers/net/wireguard/peer.c

[ ... ]

> @@ -105,28 +108,27 @@ static void peer_remove_after_dead(struct wg_peer *peer)
>  	 */
>  	wg_timers_stop(peer);
>  
> -	/* The transition between packet encryption/decryption queues isn't
> -	 * guarded by is_dead, but each reference's life is strictly bounded by
> -	 * two generations: once for parallel crypto and once for serial
> -	 * ingestion, so we can simply flush twice, and be sure that we no
> -	 * longer have references inside these queues.
> +	/* Lookup removal and is_dead prevent new packets from entering the
> +	 * parallel crypto queues after synchronize_net() waits for pre-existing
> +	 * submission paths. Drop the initial count and wait for existing packets
> +	 * to finish scheduling their serial TX work or RX NAPI processing.
>  	 */
> +	atomic_dec(&peer->packet_crypt_pending);
> +	wait_var_event(&peer->packet_crypt_pending,
> +		       !atomic_read_acquire(&peer->packet_crypt_pending));
> +
> +	flush_work(&peer->transmit_packet_work);
>  
> -	/* a) For encrypt/decrypt. */
> -	flush_workqueue(peer->device->packet_crypt_wq);
> -	/* b.1) For send (but not receive, since that's napi). */
> -	flush_workqueue(peer->device->packet_crypt_wq);
> -	/* b.2.1) For receive (but not send, since that's wq). */
>  	napi_disable(&peer->napi);

[Severity: High]
Can this leave entries in peer->rx_queue when the peer is torn down, and
leak both the skbs and the wg_peer itself?

The new counter is decremented in wg_queue_enqueue_per_peer_rx() only after
the packet has been put on peer->rx_queue and NAPI has been scheduled:

drivers/net/wireguard/queueing.h:wg_queue_enqueue_per_peer_rx() {
	atomic_set_release(&PACKET_CB(skb)->state, state);
	napi_schedule(&peer->napi);
	if (atomic_dec_and_test(&peer->packet_crypt_pending))
		wake_up_var(&peer->packet_crypt_pending);
	wg_peer_put(peer);
}

So packet_crypt_pending reaching zero means "handoff done, NAPI scheduled",
not "rx_queue drained".  For an rx-only peer flush_work(&peer->transmit_packet_work)
is a no-op, so napi_disable() can now run immediately after the last decrypt
handoff while up to MAX_QUEUED_PACKETS entries are still queued.

If wg_packet_rx_poll() consumes exactly budget entries it breaks out without
calling napi_complete_done():

drivers/net/wireguard/receive.c:wg_packet_rx_poll() {
	...
		if (++work_done >= budget)
			break;
	}

	if (work_done < budget)
		napi_complete_done(napi, work_done);

	return work_done;
}

and __napi_poll() then takes the completion path rather than a repoll,
because napi_disable_locked() has already set the disable-pending state:

net/core/dev.c:__napi_poll() {
	...
	if (unlikely(napi_disable_pending(n))) {
		napi_complete(n);
		return work;
	}

so napi_disable()/netif_napi_del() finish with a non-empty rx_queue, and
is_dead plus the completed counter wait mean nothing schedules the NAPI
again.

Each stranded skb still holds the peer reference taken by
wg_peer_get_maybe_zero() in wg_packet_consume_data() and a keypair
reference, and those are only dropped at the next: label of
wg_packet_rx_poll():

next:
		wg_noise_keypair_put(keypair, false);
		wg_peer_put(peer);

Is there any other consumer of peer->rx_queue that could drain it?  If not,
the peer kref never reaches zero, so kref_release()/rcu_release() never run
and the skbs, the wg_peer, its dst_cache and the staged queue are never
freed.  That also means the existing safety net in rcu_release():

	WARN_ON(wg_prev_queue_peek(&peer->tx_queue) || wg_prev_queue_peek(&peer->rx_queue));

can never fire to report it.

The pre-patch code did not strictly guarantee the drain either, but the two
flush_workqueue(peer->device->packet_crypt_wq) calls being removed blocked
for as long as the shared crypt workers kept running, which is exactly the
heavy-traffic case where rx_queue gets deep, and in practice gave the NAPI
softirq time to drain it.  Would it make sense to have the teardown path
wait for the rx_queue to actually empty (or purge it explicitly) rather
than only for the handoff counter?

> -	/* b.2.1) It's now safe to remove the napi struct, which must be done
> +	/* It's now safe to remove the napi struct, which must be done
>  	 * here from process context.
>  	 */
>  	netif_napi_del(&peer->napi);

[ ... ]

> diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
> index 79b6d70de236..fdd34f0f15a6 100644
> --- a/drivers/net/wireguard/queueing.h
> +++ b/drivers/net/wireguard/queueing.h

[ ... ]

> @@ -194,6 +198,8 @@ static inline void wg_queue_enqueue_per_peer_rx(struct sk_buff *skb, enum packet
>  
>  	atomic_set_release(&PACKET_CB(skb)->state, state);
>  	napi_schedule(&peer->napi);
> +	if (atomic_dec_and_test(&peer->packet_crypt_pending))
> +		wake_up_var(&peer->packet_crypt_pending);
>  	wg_peer_put(peer);
>  }

-- 
Sashiko AI review ? https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260902-fix-wg-peer-removal-v1-1-7a0190f5cdb1%40cloudflare.com

From syzbot+ce2a09d03fdc079a46e9 at syzkaller.appspotmail.com  Mon Sep 14 21:27:21 2026
From: syzbot+ce2a09d03fdc079a46e9 at syzkaller.appspotmail.com (syzbot)
Date: Mon, 14 Sep 2026 14:27:21 -0700
Subject: [syzbot] [arm?] BUG: workqueue lockup in wg_packet_encrypt_worker
Message-ID: <6aa866b9.a211d2ce.1a5198.029c.GAE@google.com>

Hello,

syzbot found the following issue on:

HEAD commit:    5445d6419962 arm64: Don't read GMID_EL1 when MTE is disabled
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=17fa6925580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=56ed23170c168d4c
dashboard link: https://syzkaller.appspot.com/bug?extid=ce2a09d03fdc079a46e9
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
userspace arch: arm64

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e8b70e3bd109/disk-5445d641.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/e5227e56ac93/vmlinux-5445d641.xz
kernel image: https://storage.googleapis.com/syzbot-assets/54905f78be59/Image-5445d641.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ce2a09d03fdc079a46e9 at syzkaller.appspotmail.com

BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 47s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x100
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=14 refcnt=15
    pending: 4*nsim_dev_hwstats_traffic_work, vmstat_shepherd, psi_avgs_work, free_obj_work, 3*ovs_dp_masks_rebalance, 4*psi_avgs_work
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=4 refcnt=5
    in-flight: 24:reg_todo for 142s
    pending: 3*nsim_dev_hwstats_traffic_work
workqueue events_unbound: flags=0x2
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=14 refcnt=15
    in-flight: 12:cfg80211_wiphy_work for 140s cfg80211_wiphy_work ,59:cfg80211_wiphy_work for 132s cfg80211_wiphy_work ,42:cfg80211_wiphy_work for 144s cfg80211_wiphy_work ,40:cfg80211_wiphy_work for 125s cfg80211_wiphy_work ,1241:cfg80211_wiphy_work for 145s cfg80211_wiphy_work ,1165:cfg80211_wiphy_work for 145s cfg80211_wiphy_work
    pending: 2*macvlan_process_broadcast
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=10 refcnt=11
    in-flight: 8217:nsim_dev_trap_report_work for 0s
    pending: 2*nsim_dev_trap_report_work, crng_reseed, toggle_allocation_gate, 4*nsim_dev_trap_report_work, flush_memcg_stats_dwork
workqueue events_power_efficient: flags=0x82
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    in-flight: 1425:reg_check_chans_work for 73s
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=9 refcnt=10
    in-flight: 1162:crda_timeout_work for 127s ,1254:check_lifetime for 110s ,8218:gc_worker for 10s
    pending: hash_ipportip4_gc, fb_flashcursor, nf_flow_offload_work_gc, 2*neigh_managed_work, wg_ratelimiter_gc_entries
workqueue events_dfl_long: flags=0x2
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=6 refcnt=7
    pending: 6*defense_work_handler
workqueue rcu_gp: flags=0x108
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: srcu_invoke_callbacks
workqueue netns: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=6 MAYDAY
    in-flight: 8(RESCUER):cleanup_net for 138s
workqueue mm_percpu_wq: flags=0x108
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: vmstat_update
workqueue ipv6_addrconf: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=12 MAYDAY
    in-flight: 2822(RESCUER):addrconf_verify_work for 84s
    inactive: 6*addrconf_verify_work
workqueue bat_events: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=50 MAYDAY
    in-flight: 2854(RESCUER):batadv_tt_purge for 8s
    pending: mayday_cursor_func
    inactive: batadv_dat_purge, 2*batadv_bla_periodic_work, 2*batadv_dat_purge, batadv_bla_periodic_work, 2*batadv_iv_send_outstanding_bat_ogm_packet, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_purge_orig, 2*batadv_iv_send_outstanding_bat_ogm_packet, 6*batadv_mcast_mla_update, 4*batadv_iv_send_outstanding_bat_ogm_packet, batadv_purge_orig, 6*batadv_iv_send_outstanding_bat_ogm_packet, 3*batadv_purge_orig, batadv_iv_send_outstanding_bat_ogm_packet, batadv_purge_orig, batadv_dat_purge, batadv_bla_periodic_work, 5*batadv_tt_purge
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    in-flight: 4710:wg_packet_handshake_receive_worker for 52s
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    in-flight: 8221:wg_packet_handshake_send_worker for 0s
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=5 refcnt=6
    in-flight: 4817:wg_packet_encrypt_worker for 47s ,4306:wg_packet_tx_worker for 47s
    pending: wg_packet_decrypt_worker, wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 8225:wg_packet_handshake_receive_worker for 2s
workqueue wg-kex-wg1: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    in-flight: 14:wg_packet_handshake_send_worker for 20s
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue bond0: flags=0x2000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=5 MAYDAY
    pending: bond_arp_monitor
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    in-flight: 9:wg_packet_handshake_receive_worker for 48s
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    in-flight: 26:wg_packet_handshake_receive_worker for 44s wg_packet_handshake_receive_worker
workqueue wg-kex-wg1: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=2 refcnt=3
    in-flight: 8216:wg_packet_handshake_send_worker for 0s
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg1: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=2 refcnt=3
    pending: 2*wg_packet_handshake_send_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=2 refcnt=3
    pending: 2*wg_packet_handshake_send_worker
workqueue krds_cp_wq#2/0: flags=0x20002
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=4
    in-flight: 8219:rds_connect_worker for 11s
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4902:wg_packet_handshake_receive_worker for 3s
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    in-flight: 865:wg_packet_tx_worker for 53s wg_packet_tx_worker
    pending: wg_packet_encrypt_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    in-flight: 4802:wg_packet_handshake_receive_worker for 51s
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_tx_worker, wg_packet_encrypt_worker
pool 2: cpus=0 node=0 flags=0x0 nice=0 hung=47s workers=10 idle: 10 4809 4898 4708
pool 6: cpus=1 node=0 flags=0x0 nice=0 hung=0s workers=9 idle: 8222 5105 8220 1089 4812
pool 8: cpus=0-1 flags=0x6 nice=0 hung=0s workers=16 manager: 8223
Showing backtraces of busy workers in stalled worker pools:
pool 2:
task:kworker/0:8     state:R  running task     stack:0     pid:4817  tgid:4817  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg0 wg_packet_encrypt_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5520 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7270
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7449
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7473
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:237 [inline]
 _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:245
 spin_unlock_bh include/linux/spinlock.h:407 [inline]
 ptr_ring_consume_bh include/linux/ptr_ring.h:399 [inline]
 wg_packet_encrypt_worker+0x25c/0x1290 drivers/net/wireguard/send.c:293
 process_one_work kernel/workqueue.c:3387 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3470
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3551
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:2     state:R  running task     stack:0     pid:865   tgid:865   ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5520 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7270
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7449
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7473
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 mod_peer_timer+0x21c/0x25c drivers/net/wireguard/timers.c:38
 wg_timers_any_authenticated_packet_traversal+0x98/0xc0 drivers/net/wireguard/timers.c:218
 wg_packet_create_data_done drivers/net/wireguard/send.c:247 [inline]
 wg_packet_tx_worker+0x130/0x75c drivers/net/wireguard/send.c:276
 process_one_work kernel/workqueue.c:3387 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3470
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3551
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:5     state:R  running task     stack:0     pid:4710  tgid:4710  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-kex-wg0 wg_packet_handshake_receive_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5520 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7270
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7449
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7473
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 wg_packet_create_data drivers/net/wireguard/send.c:325 [inline]
 wg_packet_send_staged_packets+0xc34/0x1124 drivers/net/wireguard/send.c:388
 wg_packet_send_keepalive+0x144/0x248 drivers/net/wireguard/send.c:239
 wg_receive_handshake_packet drivers/net/wireguard/receive.c:186 [inline]
 wg_packet_handshake_receive_worker+0x5c8/0xcf8 drivers/net/wireguard/receive.c:213
 process_one_work kernel/workqueue.c:3387 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3470
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3551
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:6     state:R  running task     stack:0     pid:4802  tgid:4802  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-kex-wg1 wg_packet_handshake_receive_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5520 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7270
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7449
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7473
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 mod_peer_timer+0x21c/0x25c drivers/net/wireguard/timers.c:38
 wg_timers_session_derived+0x5c/0x6c drivers/net/wireguard/timers.c:208
 wg_packet_send_handshake_response+0x118/0x264 drivers/net/wireguard/send.c:98
 wg_receive_handshake_packet drivers/net/wireguard/receive.c:154 [inline]
 wg_packet_handshake_receive_worker+0x570/0xcf8 drivers/net/wireguard/receive.c:213
 process_one_work kernel/workqueue.c:3387 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3470
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3551
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:0     state:R  running task     stack:0     pid:9     tgid:9     ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-kex-wg1 wg_packet_handshake_receive_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5520 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7270
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7449
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7473
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 wg_noise_handshake_begin_session+0x698/0x958 drivers/net/wireguard/noise.c:856
 wg_packet_send_handshake_response+0x108/0x264 drivers/net/wireguard/send.c:96
 wg_receive_handshake_packet drivers/net/wireguard/receive.c:154 [inline]
 wg_packet_handshake_receive_worker+0x570/0xcf8 drivers/net/wireguard/receive.c:213
 process_one_work kernel/workqueue.c:3387 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3470
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3551
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:3     state:R  running task     stack:0     pid:4306  tgid:4306  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5520 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7270
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7449
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7473
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 keep_key_fresh drivers/net/wireguard/send.c:135 [inline]
 wg_packet_create_data_done drivers/net/wireguard/send.c:259 [inline]
 wg_packet_tx_worker+0x6bc/0x75c drivers/net/wireguard/send.c:276
 process_one_work kernel/workqueue.c:3387 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3470
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3551
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller at googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

From syzbot+d0d2f1a65f45b319d25d at syzkaller.appspotmail.com  Tue Sep 15 21:33:43 2026
From: syzbot+d0d2f1a65f45b319d25d at syzkaller.appspotmail.com (syzbot)
Date: Tue, 15 Sep 2026 14:33:43 -0700
Subject: [syzbot] [wireguard?] BUG: workqueue lockup in
 wg_packet_decrypt_worker
Message-ID: <6aa9b9b7.f81106d8.2ab401.006f.GAE@google.com>

Hello,

syzbot found the following issue on:

HEAD commit:    5445d6419962 arm64: Don't read GMID_EL1 when MTE is disabled
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=1114c2d1580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=56ed23170c168d4c
dashboard link: https://syzkaller.appspot.com/bug?extid=d0d2f1a65f45b319d25d
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
userspace arch: arm64

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e8b70e3bd109/disk-5445d641.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/e5227e56ac93/vmlinux-5445d641.xz
kernel image: https://storage.googleapis.com/syzbot-assets/54905f78be59/Image-5445d641.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d0d2f1a65f45b319d25d at syzkaller.appspotmail.com

BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 45s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x100
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=6 refcnt=7
    pending: vmstat_shepherd, 2*psi_avgs_work, 3*ovs_dp_masks_rebalance
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=18 refcnt=19
    pending: 2*psi_avgs_work, 3*ovs_dp_masks_rebalance, xfrm_state_gc_task, psi_avgs_work, delayed_vfree_work, 8*nsim_dev_hwstats_traffic_work, psi_avgs_work, free_obj_work
workqueue events_unbound: flags=0x2
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=20 refcnt=21
    in-flight: 3055:cfg80211_wiphy_work for 75s cfg80211_wiphy_work ,54:nsim_dev_trap_report_work for 6s ,431:cfg80211_wiphy_work for 73s cfg80211_wiphy_work ,348:cfg80211_wiphy_work for 91s cfg80211_wiphy_work ,1617:cfg80211_wiphy_work for 76s cfg80211_wiphy_work ,12:cfg80211_wiphy_work for 93s cfg80211_wiphy_work ,1777:nsim_dev_trap_report_work for 11s ,40:cfg80211_wiphy_work for 92s cfg80211_wiphy_work ,3203:nsim_dev_trap_report_work for 1s
    pending: nsim_dev_trap_report_work, toggle_allocation_gate, 2*nsim_dev_trap_report_work, cfg80211_wiphy_work
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=7 refcnt=8
    in-flight: 13:linkwatch_event for 95s ,3020:cfg80211_wiphy_work for 89s cfg80211_wiphy_work ,3157:cfg80211_wiphy_work for 60s cfg80211_wiphy_work
    pending: 2*nsim_dev_trap_report_work
workqueue events_power_efficient: flags=0x82
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=6 refcnt=7
    in-flight: 1756:neigh_periodic_work for 6s ,284:reg_check_chans_work for 75s
    pending: neigh_periodic_work, wg_ratelimiter_gc_entries, 2*neigh_managed_work
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: gc_worker
workqueue events_dfl_long: flags=0x2
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=6 refcnt=7
    pending: 6*defense_work_handler
workqueue mm_percpu_wq: flags=0x108
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: vmstat_update
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: vmstat_update
workqueue ipv6_addrconf: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=9
    in-flight: 59:addrconf_verify_work for 78s
    inactive: 5*addrconf_verify_work
workqueue bat_events: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=45 MAYDAY
    in-flight: 2855(RESCUER):batadv_tt_purge for 18s
    inactive: batadv_tt_purge, batadv_mcast_mla_update, batadv_tt_purge, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, 2*batadv_bla_periodic_work, batadv_dat_purge, batadv_mcast_mla_update, batadv_bla_periodic_work, batadv_dat_purge, 2*batadv_mcast_mla_update, 2*batadv_iv_send_outstanding_bat_ogm_packet, batadv_purge_orig, 3*batadv_iv_send_outstanding_bat_ogm_packet, 2*batadv_purge_orig, 5*batadv_iv_send_outstanding_bat_ogm_packet, batadv_purge_orig, batadv_iv_send_outstanding_bat_ogm_packet, batadv_mcast_mla_update, 4*batadv_iv_send_outstanding_bat_ogm_packet, batadv_purge_orig, batadv_bla_periodic_work, batadv_dat_purge, 2*batadv_tt_purge
workqueue wg-kex-wg0: flags=0x124
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    in-flight: 10:wg_packet_handshake_receive_worker for 46s
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg1: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker, wg_packet_decrypt_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    in-flight: 3495:wg_packet_handshake_send_worker for 4s
workqueue wg-crypt-wg0: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4477:wg_packet_handshake_receive_worker for 12s
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=2 refcnt=3
    pending: 2*wg_packet_handshake_send_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_encrypt_worker, wg_packet_decrypt_worker, wg_packet_tx_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 9:wg_packet_handshake_receive_worker for 20s
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=4 refcnt=5
    in-flight: 4889:wg_packet_decrypt_worker for 45s
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker, wg_packet_decrypt_worker
workqueue hci0: flags=0x20012
  pwq 9: cpus=0-1 node=0 flags=0x4 nice=-20 active=1 refcnt=4
    in-flight: 4723:hci_cmd_sync_work for 84s
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    in-flight: 24:wg_packet_tx_worker for 45s
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4799:wg_packet_handshake_receive_worker for 17s
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_encrypt_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker, wg_packet_decrypt_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=2 refcnt=3
    pending: 2*wg_packet_handshake_send_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue hci3: flags=0x20012
  pwq 9: cpus=0-1 node=0 flags=0x4 nice=-20 active=1 refcnt=4
    in-flight: 4726:hci_cmd_sync_work for 78s
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4840:wg_packet_handshake_receive_worker for 11s
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4806:wg_packet_handshake_receive_worker for 19s
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker, wg_packet_decrypt_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4827:wg_packet_handshake_receive_worker for 6s
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_decrypt_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker, wg_packet_decrypt_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 1159:wg_packet_handshake_receive_worker for 23s
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_tx_worker, wg_packet_decrypt_worker, wg_packet_encrypt_worker
pool 2: cpus=0 node=0 flags=0x0 nice=0 hung=6s workers=10 idle: 4820 4807
pool 6: cpus=1 node=0 flags=0x0 nice=0 hung=45s workers=8 idle: 5732 5459 26 4798 868 5730
pool 8: cpus=0-1 flags=0x6 nice=0 hung=1s workers=17 manager: 6529
pool 9: cpus=0-1 node=0 flags=0x4 nice=-20 hung=0s workers=8 idle: 4721 4713 4718 4717 50 4720
Showing backtraces of busy workers in stalled worker pools:
pool 6:
task:kworker/1:4     state:R  running task     stack:0     pid:4889  tgid:4889  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg2 wg_packet_decrypt_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5520 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7270
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7449
 preempt_schedule kernel/sched/core.c:7473 [inline]
 class_preempt_destructor include/linux/preempt.h:500 [inline]
 try_to_wake_up+0x5f8/0xdc4 kernel/sched/core.c:4432
 wake_up_process+0x18/0x24 kernel/sched/core.c:4557
 process_one_work kernel/workqueue.c:3355 [inline]
 process_scheduled_works+0x744/0x1250 kernel/workqueue.c:3470
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3551
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 6:
task:kworker/1:0     state:R  running task     stack:0     pid:24    tgid:24    ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5520 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7270
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7449
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7473
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 keep_key_fresh drivers/net/wireguard/send.c:135 [inline]
 wg_packet_create_data_done drivers/net/wireguard/send.c:259 [inline]
 wg_packet_tx_worker+0x520/0x75c drivers/net/wireguard/send.c:276
 process_one_work kernel/workqueue.c:3387 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3470
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3551
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller at googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

From Jason at zx2c4.com  Wed Sep 16 09:26:19 2026
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 16 Sep 2026 11:26:19 +0200
Subject: [PATCH net] wireguard: queueing: preserve tstamp_type in
 wg_reset_packet()
In-Reply-To: <P0MLDmd--F-9@well-founded.dev>
References: <20260827-wg-tstamp-v1-1-4acfebb855ef@well-founded.dev>
 <apT0H7qIwFW-JCLn@zx2c4.com> <P0MLDmd--F-9@well-founded.dev>
Message-ID: <aqpgu23iotZeyGgv@zx2c4.com>

On Mon, Aug 31, 2026 at 12:24:15PM +0200, Ramses wrote:
> Aug 31, 2026, 05:25 by Jason at zx2c4.com:
> 
> > Hi Ramses,
> >
> > On Thu, Aug 27, 2026 at 01:52:56PM +0200, Ramses de Norre via B4 Relay wrote:
> >
> >> From: Ramses de Norre <ramses at 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: de799101519a ("net: Add skb_clear_tstamp() to keep the mono delivery_time")
> >> Signed-off-by: Ramses de Norre <ramses at well-founded.dev>
> >>
> >
> > Thanks for this. I've queued this up in the wireguard tree.
> >
> > One thing I'm wondering is whether your Fixes: line is correct. Would
> > c4f796c4f16b be a better candidate than de799101519a? Or maybe even
> > 4d25ca2d6801 is best?
> >
> > Jason
> >
> Hi Jason
> 
> I think you are right, but I think d98d58a00261 is actually the commit that introduced the issue then (but no warnings were logged yet at that point).
> The patch doesn't apply cleanly to that version though, I think it only applies starting from 6.11 because of a rename, so we can't backport all the way back. It's probably fine though, since the warnings weren't being logged yet at that point.
> Do you want me to send an updated patch, or will you just fix this up in your tree?

I'll fix it in my tree to be:
   Fixes: d98d58a00261 ("net: Set skb->mono_delivery_time and clear it after sch_handle_ingress()")


From Jason at zx2c4.com  Wed Sep 16 10:06:08 2026
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 16 Sep 2026 12:06:08 +0200
Subject: [PATCH net v2] wireguard: wait for per-peer crypto during removal
In-Reply-To: <20260913-fix-wg-peer-removal-v2-1-0cade985245a@cloudflare.com>
References: <20260913-fix-wg-peer-removal-v2-1-0cade985245a@cloudflare.com>
Message-ID: <aqpqEIy_h0DIywRy@zx2c4.com>

On Sun, Sep 13, 2026 at 07:19:08AM -0500, Chris J Arges wrote:
> Calling peer_remove_after_dead() currently flushes device-wide packet
> crypto and handshake workqueues while holding RTNL. This is problematic as
> unrelated peers can continue adding work to those queues, blocking other
> tasks that want to take the RTNL lock.
> 
> Instead, this patch tracks pending crypto handoffs for each peer using a
> counter. After marking the peer dead, synchronize_net() prevents new
> submissions. Next, wait for pending crypto workers to schedule TX work and
> for RX NAPI to drain the peer's RX queue. Then flush only the peer's TX
> packet and handshake work.
> 
> This scopes teardown synchronization to the removed peer and prevents
> unrelated peers from extending the RTNL hold time.
>  struct wg_device;
> @@ -161,6 +162,7 @@ static inline int wg_queue_enqueue_per_device_and_peer(
>  	 */
>  	if (unlikely(!wg_prev_queue_enqueue(peer_queue, skb)))
>  		return -ENOSPC;
> +	atomic_inc(&PACKET_PEER(skb)->packet_crypt_pending);
>  
>  	/* Then we queue it up in the device queue, which consumes the
>  	 * packet as soon as it can.
> @@ -182,6 +184,8 @@ static inline void wg_queue_enqueue_per_peer_tx(struct sk_buff *skb, enum packet
>  	atomic_set_release(&PACKET_CB(skb)->state, state);
>  	queue_work_on(wg_cpumask_choose_online(&peer->serial_work_cpu, peer->internal_id),
>  		      peer->device->packet_crypt_wq, &peer->transmit_packet_work);
> +	if (atomic_dec_and_test(&peer->packet_crypt_pending))
> +		wake_up_var(&peer->packet_crypt_pending);
>  	wg_peer_put(peer);
>  }
>  
> diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c
> index 824bbefce61c..bb35e3205491 100644
> --- a/drivers/net/wireguard/receive.c
> +++ b/drivers/net/wireguard/receive.c
> @@ -476,9 +476,11 @@ int wg_packet_rx_poll(struct napi_struct *napi, int budget)
>  
>  next:
>  		wg_noise_keypair_put(keypair, false);
> -		wg_peer_put(peer);
>  		if (unlikely(free))
>  			dev_kfree_skb(skb);
> +		if (atomic_dec_and_test(&peer->packet_crypt_pending))
> +			wake_up_var(&peer->packet_crypt_pending);
> +		wg_peer_put(peer);

This adds two atomic updates to a per-peer counter for every RX packet
and TX batch. That could introduce contention across crypto workers. I
suppose it'd be good to see some measurements in if this changes
anything. Certainly it should change _something_. Question is by how
much.

Jason

From segev at swimm.io  Thu Sep 17 07:59:39 2026
From: segev at swimm.io (Segev Finer)
Date: Thu, 17 Sep 2026 10:59:39 +0300
Subject: Add support for setting proxy settings
 (NETunnelNetworkSettings.proxySettings) in wireguard-apple
Message-ID: <CAEFWZ+MH3vtg5i1Tb0Poac_xc0ufFUQMcxcKx6kzKd0347trJA@mail.gmail.com>

When using NEPacketTunnelProvider, you can also specify proxy
settings, those are used by programs that query for the system proxy
settings while connected to the WireGuard VPN, for example,
Chromium/Chrome uses that (scutil --proxy shows the settings AFAIK),
there is currently no way to set those settings in wireguard-apple,
and the GUI for setting them, as available in builtin VPN providers in
macOS is not available for the WireGuard VPN interface in the macOS
GUI, so you are stuck with the default proxy settings, where some
networks do require proxy settings, be it enabling auto-discovery, PAC
URL, HTTP proxy URL, etc. like the default proxy settings GUI in macOS
allows you to set. You can currently still use wireguard-tools/wg-quick
which still uses, what I think is an undocumented interface?, to
create a tun device, which doesn't affect those settings, but that's
not as convenient or nice as using wireguard-apple.

Another thing that I noticed is that wireguard-apple seems to always
use the default internet gateway, ignoring routing rules that say
otherwise which prevent using it nested, or with other custom network
interfaces, it would be nice to be able to control the outgoing
interface in wireguard-apple. wireguard-tools/wg-quick adds a route
that uses the default gateway which you can simply remove or modify
manually if needed (Though a setting would be nicer of course), but
wireguard-apple seems to somehow go through the default interface and
ignores the routing rules.

I would have tried to contribute but Apple requires a paid developer
account to develop network extensions.

From syzbot+d0d2f1a65f45b319d25d at syzkaller.appspotmail.com  Mon Sep 21 11:47:30 2026
From: syzbot+d0d2f1a65f45b319d25d at syzkaller.appspotmail.com (syzbot)
Date: Mon, 21 Sep 2026 04:47:30 -0700
Subject: [syzbot] [wireguard?] BUG: workqueue lockup in
 wg_packet_decrypt_worker
In-Reply-To: <6aa9b9b7.f81106d8.2ab401.006f.GAE@google.com>
Message-ID: <6ab11952.514bccd6.255447.0012.GAE@google.com>

syzbot has found a reproducer for the following issue on:

HEAD commit:    38872197cae2 Merge branch 'for-next/fixes' into for-kernelci
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=17567005580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=56ed23170c168d4c
dashboard link: https://syzkaller.appspot.com/bug?extid=d0d2f1a65f45b319d25d
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1606a805580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c5963fdd6790/disk-38872197.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a8c2cab00c45/vmlinux-38872197.xz
kernel image: https://storage.googleapis.com/syzbot-assets/bde15d173380/Image-38872197.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d0d2f1a65f45b319d25d at syzkaller.appspotmail.com

BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 38s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x100
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=16 refcnt=17
    in-flight: 4858:nsim_fib_event_work for 39s ,4830:nsim_fib_event_work for 40s
    pending: 3*nsim_dev_hwstats_traffic_work, 2*psi_avgs_work, vmstat_shepherd, rht_deferred_worker, free_obj_work, 3*ovs_dp_masks_rebalance, drm_fb_helper_damage_work, 2*nsim_fib_event_work
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=11 refcnt=12
    in-flight: 869:nsim_fib_event_work for 44s nsim_fib_event_work ,4806:nsim_fib_event_work for 41s nsim_fib_event_work
    pending: psi_avgs_work, 6*ovs_dp_masks_rebalance
workqueue events_unbound: flags=0x2
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=22 refcnt=23
    in-flight: 1472:cfg80211_wiphy_work for 41s cfg80211_wiphy_work ,1438:cfg80211_wiphy_work for 43s cfg80211_wiphy_work ,1295:cfg80211_wiphy_work for 43s cfg80211_wiphy_work ,14:cfg80211_wiphy_work for 36s ,79:cfg80211_wiphy_work for 43s cfg80211_wiphy_work ,1486:cfg80211_wiphy_work for 42s cfg80211_wiphy_work ,12:cfg80211_wiphy_work for 39s
    pending: 2*cfg80211_wiphy_work, nsim_dev_trap_report_work, toggle_allocation_gate, macvlan_process_broadcast, 3*nsim_dev_trap_report_work, flush_memcg_stats_dwork, macvlan_process_broadcast
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=7 refcnt=8
    in-flight: 1234:cfg80211_wiphy_work for 43s cfg80211_wiphy_work
    pending: macvlan_process_broadcast, crng_reseed, 3*macvlan_process_broadcast
workqueue events_power_efficient: flags=0x82
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=5 refcnt=6
    in-flight: 50:neigh_periodic_work for 33s
    pending: neigh_managed_work, fb_flashcursor, wg_ratelimiter_gc_entries, neigh_managed_work
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=2 refcnt=3
    pending: neigh_periodic_work, do_cache_clean
workqueue events_dfl_long: flags=0x2
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=9 refcnt=10
    pending: 9*defense_work_handler
workqueue netns: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=4
    in-flight: 1183:cleanup_net for 45s
workqueue mm_percpu_wq: flags=0x108
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: vmstat_update
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: vmstat_update
workqueue mld: flags=0x40108
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=73
    pending: mld_ifc_work
    inactive: 2*mld_ifc_work, mld_dad_work, mld_ifc_work, mld_dad_work, mld_ifc_work, mld_dad_work, 4*mld_ifc_work, 2*mld_dad_work, mld_ifc_work, mld_dad_work, 3*mld_ifc_work, 2*mld_dad_work, 5*mld_ifc_work, mld_dad_work, mld_ifc_work, mld_dad_work, 3*mld_ifc_work, 3*mld_dad_work, mld_ifc_work, 2*mld_dad_work, 3*mld_ifc_work, mld_dad_work, 2*mld_ifc_work, mld_dad_work, 6*mld_ifc_work, mld_dad_work, mld_ifc_work, 2*mld_dad_work, 3*mld_ifc_work, 2*mld_dad_work, mld_ifc_work, 2*mld_dad_work, mld_ifc_work, 8*mld_dad_work
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=95
    pending: mld_ifc_work
    inactive: mld_ifc_work, mld_dad_work, mld_ifc_work, mld_dad_work, 9*mld_ifc_work, 2*mld_dad_work, 6*mld_ifc_work, mld_dad_work, 4*mld_ifc_work, mld_dad_work, 4*mld_ifc_work, 62*mld_dad_work
workqueue ipv6_addrconf: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=178 MAYDAY
    in-flight: 2825(RESCUER):addrconf_dad_work for 0s
    pending: mayday_cursor_func
    inactive: 172*addrconf_dad_work
workqueue bat_events: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=51 MAYDAY
    in-flight: 2857(RESCUER):batadv_tt_purge for 11s
    pending: mayday_cursor_func
    inactive: 4*batadv_tt_purge, batadv_dat_purge, batadv_bla_periodic_work, 6*batadv_mcast_mla_update, 5*batadv_iv_send_outstanding_bat_ogm_packet, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, 5*batadv_iv_send_outstanding_bat_ogm_packet, 6*batadv_purge_orig, 6*batadv_iv_send_outstanding_bat_ogm_packet, batadv_tt_purge
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker, wg_packet_decrypt_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=4 refcnt=5
    in-flight: 9:wg_packet_decrypt_worker for 40s wg_packet_decrypt_worker
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=4 refcnt=5
    in-flight: 10:wg_packet_decrypt_worker for 41s wg_packet_decrypt_worker
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_decrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg1: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    in-flight: 1115:wg_packet_decrypt_worker for 41s wg_packet_decrypt_worker
    pending: wg_packet_encrypt_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4356:wg_packet_handshake_receive_worker for 41s
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=2 refcnt=3
    pending: 2*wg_packet_handshake_send_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_tx_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=2 refcnt=3
    pending: 2*wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_decrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_tx_worker
workqueue wg-kex-wg1: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg2: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    in-flight: 40:wg_packet_handshake_send_worker for 6s
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
pool 2: cpus=0 node=0 flags=0x0 nice=0 hung=38s workers=8 idle: 5002 4997
pool 6: cpus=1 node=0 flags=0x0 nice=0 hung=21s workers=7 idle: 26 24 4967 5000 4999
pool 8: cpus=0-1 flags=0x6 nice=0 hung=0s workers=12 manager: 5001
Showing backtraces of busy workers in stalled worker pools:
pool 2:
task:kworker/0:1     state:R  running task     stack:0     pid:10    tgid:10    ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg2 wg_packet_decrypt_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5526 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7277
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7456
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7480
 __kunmap_atomic include/linux/highmem-internal.h:247 [inline]
 sg_miter_stop+0x220/0x2cc lib/scatterlist.c:941
 chacha20poly1305_crypt_sg_inplace+0x75c/0xc30 lib/crypto/chacha20poly1305.c:319
 chacha20poly1305_decrypt_sg_inplace+0x6c/0x94 lib/crypto/chacha20poly1305.c:353
 decrypt_packet drivers/net/wireguard/receive.c:278 [inline]
 wg_packet_decrypt_worker+0x490/0xa00 drivers/net/wireguard/receive.c:501
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:5     state:R  running task     stack:0     pid:4858  tgid:4858  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: events nsim_fib_event_work
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5526 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7277
 __schedule_loop kernel/sched/core.c:7354 [inline]
 schedule+0x13c/0x20c kernel/sched/core.c:7369
 schedule_timeout+0x13c/0x28c kernel/time/sleep_timeout.c:99
 schedule_timeout_uninterruptible+0x78/0xbc kernel/time/sleep_timeout.c:158
 msleep+0x3c/0x68 kernel/time/sleep_timeout.c:318
 nsim_fib6_rt_add drivers/net/netdevsim/fib.c:693 [inline]
 nsim_fib6_rt_insert drivers/net/netdevsim/fib.c:759 [inline]
 nsim_fib6_event drivers/net/netdevsim/fib.c:856 [inline]
 nsim_fib_event+0x57a0/0x60c4 drivers/net/netdevsim/fib.c:889
 nsim_fib_event_work+0x1d8/0x320 drivers/net/netdevsim/fib.c:1493
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:4     state:R  running task     stack:0     pid:4830  tgid:4830  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: events nsim_fib_event_work
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5526 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7277
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7456
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7480
 irq_work_queue+0xa0/0xa4 kernel/irq_work.c:125
 __rhashtable_insert_fast include/linux/rhashtable.h:852 [inline]
 rhashtable_insert_fast include/linux/rhashtable.h:886 [inline]
 nsim_fib6_rt_add drivers/net/netdevsim/fib.c:686 [inline]
 nsim_fib6_rt_insert drivers/net/netdevsim/fib.c:759 [inline]
 nsim_fib6_event drivers/net/netdevsim/fib.c:856 [inline]
 nsim_fib_event+0x4f5c/0x60c4 drivers/net/netdevsim/fib.c:889
 nsim_fib_event_work+0x1d8/0x320 drivers/net/netdevsim/fib.c:1493
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:3     state:R  running task     stack:0     pid:4356  tgid:4356  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-kex-wg2 wg_packet_handshake_receive_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5526 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7277
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7456
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7480
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 mod_peer_timer+0x21c/0x25c drivers/net/wireguard/timers.c:38
 wg_timers_session_derived+0x5c/0x6c drivers/net/wireguard/timers.c:208
 wg_receive_handshake_packet drivers/net/wireguard/receive.c:178 [inline]
 wg_packet_handshake_receive_worker+0x5b8/0xcf8 drivers/net/wireguard/receive.c:213
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:0     state:R  running task     stack:0     pid:9     tgid:9     ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg1 wg_packet_decrypt_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5526 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7277
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7456
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7480
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:237 [inline]
 _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:245
 spin_unlock_bh include/linux/spinlock.h:407 [inline]
 ptr_ring_consume_bh include/linux/ptr_ring.h:399 [inline]
 wg_packet_decrypt_worker+0x980/0xa00 drivers/net/wireguard/receive.c:499
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

From syzbot+list3508dff347594ebfd49c at syzkaller.appspotmail.com  Mon Sep 21 12:33:37 2026
From: syzbot+list3508dff347594ebfd49c at syzkaller.appspotmail.com (syzbot)
Date: Mon, 21 Sep 2026 05:33:37 -0700
Subject: [syzbot] Monthly wireguard report (Sep 2026)
Message-ID: <6ab12421.3179f8cd.1e36b2.001f.GAE@google.com>

Hello wireguard maintainers/developers,

This is a 31-day syzbot report for the wireguard subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/wireguard

During the period, 1 new issues were detected and 0 were fixed.
In total, 5 issues are still open and 21 have already been fixed.

Some of the still happening issues:

Ref Crashes Repro Title
<1> 9       Yes   BUG: workqueue lockup in wg_packet_decrypt_worker
                  https://syzkaller.appspot.com/bug?extid=d0d2f1a65f45b319d25d
<2> 3       No    BUG: soft lockup in wg_packet_decrypt_worker
                  https://syzkaller.appspot.com/bug?extid=27a6e390f71f14f4fecf
<3> 20      Yes   INFO: rcu detected stall in wg_packet_handshake_receive_worker (3)
                  https://syzkaller.appspot.com/bug?extid=48f45f6dd79ca20c3283

---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller at googlegroups.com.

To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders

To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem

You may send multiple commands in a single email message.

From calestyo at scientia.org  Mon Sep 21 22:29:27 2026
From: calestyo at scientia.org (Christoph Anton Mitterer)
Date: Tue, 22 Sep 2026 00:29:27 +0200
Subject: bug: wg-quick fails to set up working connection
Message-ID: <a3bedeb141086893ad0b4d4cc418e9ca2585cbfb.camel@scientia.org>

Hey.


When taking a config provided for example via eduVPN:
[Interface]
PrivateKey = ***
MTU = 1320
Address = 10.153.38.15/24,2001:4ca0:4fff:2:3::f/96
DNS =
10.156.33.53,129.187.5.1,2001:4ca0::53:1,2001:4ca0::53:2,lmu.de,uni-
muenchen.de,mwn.de

[Peer]
PublicKey = ***
PresharedKey = ***
AllowedIPs =
10.0.0.0/8,85.208.24.0/22,129.187.0.0/16,131.159.0.0/16,132.199.106.6/3
1,138.244.0.0/15,138.246.0.0/16,141.39.128.0/18,141.39.240.0/20,141.40.
0.0/16,141.84.0.0/16,172.16.0.0/12,192.54.42.0/24,192.55.197.0/24,192.6
8.211.0/24,192.68.212.0/24,192.168.0.0/16,193.174.96.0/23,194.94.155.22
4/28,2001:4ca0::/29,2a09:80c0::/29
Endpoint = eduvpn-n13.srv.lrz.de:51820



starting it via:
# wg-quick up ./wg.conf
[#] ip link add dev wg type wireguard
[#] wg addconf wg /dev/fd/63
[#] ip -4 address add 10.153.38.15/24 dev wg
[#] ip -6 address add 2001:4ca0:4fff:2:3::f/96 dev wg
[#] ip link set mtu 1320 up dev wg
[#] resolvconf -a tun.wg -m 0 -x
[#] ip -4 route add 132.199.106.6/31 dev wg
[#] ip -6 route add 2a09:80c0::/29 dev wg
[#] ip -6 route add 2001:4ca0::/29 dev wg
[#] ip -4 route add 194.94.155.224/28 dev wg
[#] ip -4 route add 192.68.212.0/24 dev wg
[#] ip -4 route add 192.68.211.0/24 dev wg
[#] ip -4 route add 192.55.197.0/24 dev wg
[#] ip -4 route add 192.54.42.0/24 dev wg
[#] ip -4 route add 193.174.96.0/23 dev wg
[#] ip -4 route add 85.208.24.0/22 dev wg
[#] ip -4 route add 141.39.240.0/20 dev wg
[#] ip -4 route add 141.39.128.0/18 dev wg
[#] ip -4 route add 192.168.0.0/16 dev wg
[#] ip -4 route add 141.84.0.0/16 dev wg
[#] ip -4 route add 141.40.0.0/16 dev wg
[#] ip -4 route add 138.246.0.0/16 dev wg
[#] ip -4 route add 131.159.0.0/16 dev wg
[#] ip -4 route add 129.187.0.0/16 dev wg
[#] ip -4 route add 138.244.0.0/15 dev wg
[#] ip -4 route add 172.16.0.0/12 dev wg
[#] ip -4 route add 10.0.0.0/8 dev wg

leads to a dead connection.

The reason apparently being often the endpoint named in provided WG
configs is part of the AllowedIPs and thus nothing actually goes
through.

eduvpn-n13.srv.lrz.de.	273	IN	A	129.187.7.162
eduvpn-n13.srv.lrz.de.	273	IN	AAAA	2001:4ca0:0:123::81bb:7a2

If I  manually subtract the two endpoint IPs from the AllowedIPs, the
very same config gives a working connection.


Given that the Endpoints are allowed to use hostnames and thus things
like round robin DNS, it doesn't feel as if the configs should be
provided already excluding the (current) endpoint IP, but rather that
it should be wg-quick who does this somehow.


Cheers,
Chris.

From syzbot+ce2a09d03fdc079a46e9 at syzkaller.appspotmail.com  Wed Sep 23 23:36:28 2026
From: syzbot+ce2a09d03fdc079a46e9 at syzkaller.appspotmail.com (syzbot)
Date: Wed, 23 Sep 2026 16:36:28 -0700
Subject: [syzbot] [wireguard?] [arm?] BUG: workqueue lockup in
 wg_packet_encrypt_worker
In-Reply-To: <6aa866b9.a211d2ce.1a5198.029c.GAE@google.com>
Message-ID: <6ab4627c.80e1c6cc.1e8e5f.0006.GAE@google.com>

syzbot has found a reproducer for the following issue on:

HEAD commit:    7dc79bb50ab6 Merge branch 'for-next/core' into for-kernelci
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=13047405580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d8d86a9855667113
dashboard link: https://syzkaller.appspot.com/bug?extid=ce2a09d03fdc079a46e9
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17c5cd25580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4b09bb2b5517/disk-7dc79bb5.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9e8dab043921/vmlinux-7dc79bb5.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2151d5f44d15/Image-7dc79bb5.gz.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ce2a09d03fdc079a46e9 at syzkaller.appspotmail.com

BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 38s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x100
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=18 refcnt=19
    in-flight: 4789:nsim_fib_event_work for 36s ,9:nsim_fib_event_work for 41s nsim_fib_event_work
    pending: 2*nsim_dev_hwstats_traffic_work, 3*psi_avgs_work, vmstat_shepherd, 2*rht_deferred_worker, psi_avgs_work, free_obj_work, drm_fb_helper_damage_work, 4*ovs_dp_masks_rebalance
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=8 refcnt=9
    pending: 2*nsim_dev_hwstats_traffic_work, 6*ovs_dp_masks_rebalance
workqueue events_unbound: flags=0x2
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=20 refcnt=21
    in-flight: 93:cfg80211_wiphy_work for 40s cfg80211_wiphy_work ,12:nsim_dev_trap_report_work for 3s ,5000:nsim_dev_trap_report_work for 5s ,3177:cfg80211_wiphy_work for 40s cfg80211_wiphy_work ,13:cfg80211_wiphy_work for 40s cfg80211_wiphy_work ,3281:cfg80211_wiphy_work for 40s cfg80211_wiphy_work ,3390:cfg80211_wiphy_work for 40s cfg80211_wiphy_work ,1148:linkwatch_event for 39s ,2981:cfg80211_wiphy_work for 35s cfg80211_wiphy_work
    pending: nsim_dev_trap_report_work, toggle_allocation_gate, nsim_dev_trap_report_work, flush_memcg_stats_dwork, macvlan_process_broadcast
workqueue events_power_efficient: flags=0x82
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=7 refcnt=8
    in-flight: 845:neigh_periodic_work for 2s ,40:gc_worker for 21s
    pending: wg_ratelimiter_gc_entries, 2*neigh_managed_work, do_cache_clean, fb_flashcursor
workqueue events_dfl_long: flags=0x2
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=10 refcnt=11
    in-flight: 4998:defense_work_handler for 7s
    pending: 9*defense_work_handler
workqueue netns: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=4
    in-flight: 3525:cleanup_net for 42s
workqueue mm_percpu_wq: flags=0x108
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: vmstat_update
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: vmstat_update
workqueue writeback: flags=0x4a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=4 MAYDAY
    in-flight: 33(RESCUER):wb_workfn for 32s
workqueue mld: flags=0x40108
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=51
    in-flight: 4966:mld_ifc_work for 38s
    inactive: mld_ifc_work, mld_dad_work, 2*mld_ifc_work, mld_dad_work, mld_ifc_work, 2*mld_dad_work, 7*mld_ifc_work, 2*mld_dad_work, 4*mld_ifc_work, mld_dad_work, 6*mld_ifc_work, 4*mld_dad_work, 4*mld_ifc_work, mld_dad_work, 8*mld_ifc_work, mld_dad_work, mld_ifc_work, mld_dad_work, mld_ifc_work
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=83
    pending: mld_dad_work
    inactive: 3*mld_dad_work, 7*mld_ifc_work, 3*mld_dad_work, 3*mld_ifc_work, mld_dad_work, 9*mld_ifc_work, mld_dad_work, mld_ifc_work, mld_dad_work, 4*mld_ifc_work, mld_dad_work, 3*mld_ifc_work, 2*mld_dad_work, 4*mld_ifc_work, mld_dad_work, mld_ifc_work, 4*mld_dad_work, 4*mld_ifc_work, 2*mld_dad_work, 6*mld_ifc_work, mld_dad_work, 6*mld_ifc_work, 2*mld_dad_work, 3*mld_ifc_work, mld_dad_work, 2*mld_ifc_work, mld_dad_work, 2*mld_ifc_work, mld_dad_work, mld_ifc_work
workqueue ipv6_addrconf: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=282
    in-flight: 1446:addrconf_dad_work for 41s
    inactive: 277*addrconf_dad_work, addrconf_verify_work
workqueue bat_events: flags=0x6000a
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=51 MAYDAY
    in-flight: 2854(RESCUER):batadv_tt_purge for 15s
    inactive: 4*batadv_tt_purge, 6*batadv_iv_send_outstanding_bat_ogm_packet, 6*batadv_mcast_mla_update, 6*batadv_iv_send_outstanding_bat_ogm_packet, 6*batadv_purge_orig, 4*batadv_iv_send_outstanding_bat_ogm_packet, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_dat_purge, batadv_bla_periodic_work, batadv_tt_purge
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=4 refcnt=5
    in-flight: 4953:wg_packet_encrypt_worker for 38s ,10:wg_packet_tx_worker for 38s
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_encrypt_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_tx_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_tx_worker
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_decrypt_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    in-flight: 866:wg_packet_handshake_receive_worker for 41s
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4476:wg_packet_handshake_receive_worker for 0s
workqueue wg-kex-wg1: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    in-flight: 4997:wg_packet_handshake_send_worker for 3s
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_encrypt_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_tx_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_encrypt_worker
workqueue wg-kex-wg0: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4960:wg_packet_handshake_receive_worker for 8s
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_tx_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_tx_worker, wg_packet_encrypt_worker
workqueue wg-kex-wg0: flags=0x6
  pwq 8: cpus=0-1 flags=0x6 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_send_worker
workqueue wg-crypt-wg0: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker, wg_packet_decrypt_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 4835:wg_packet_encrypt_worker for 11s
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    in-flight: 26:wg_packet_handshake_receive_worker for 0s
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg1: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=2 refcnt=3
    in-flight: 4999:wg_packet_handshake_receive_worker for 5s
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg1: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=3 refcnt=4
    pending: wg_packet_decrypt_worker, wg_packet_encrypt_worker, wg_packet_tx_worker
workqueue wg-kex-wg2: flags=0x124
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_handshake_receive_worker
workqueue wg-crypt-wg2: flags=0x128
  pwq 2: cpus=0 node=0 flags=0x0 nice=0 active=2 refcnt=3
    pending: wg_packet_encrypt_worker, wg_packet_tx_worker
  pwq 6: cpus=1 node=0 flags=0x0 nice=0 active=1 refcnt=2
    pending: wg_packet_tx_worker
pool 2: cpus=0 node=0 flags=0x0 nice=0 hung=38s workers=7 idle: 4996
pool 6: cpus=1 node=0 flags=0x0 nice=0 hung=0s workers=7 idle: 1091 24
pool 8: cpus=0-1 flags=0x6 nice=0 hung=2s workers=16 manager: 54
Showing backtraces of busy workers in stalled worker pools:
pool 2:
task:kworker/0:4     state:R  running task     stack:0     pid:4953  tgid:4953  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg0 wg_packet_encrypt_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5533 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7284
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7463
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7487
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:237 [inline]
 _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:245
 spin_unlock_bh include/linux/spinlock.h:407 [inline]
 ptr_ring_consume_bh include/linux/ptr_ring.h:399 [inline]
 wg_packet_encrypt_worker+0x25c/0x1290 drivers/net/wireguard/send.c:293
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:3     state:R  running task     stack:0     pid:4789  tgid:4789  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: events nsim_fib_event_work
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5533 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7284
 __schedule_loop kernel/sched/core.c:7361 [inline]
 schedule+0x13c/0x20c kernel/sched/core.c:7376
 schedule_timeout+0x13c/0x28c kernel/time/sleep_timeout.c:99
 schedule_timeout_uninterruptible+0x78/0xbc kernel/time/sleep_timeout.c:158
 msleep+0x3c/0x68 kernel/time/sleep_timeout.c:318
 nsim_fib4_rt_add drivers/net/netdevsim/fib.c:369 [inline]
 nsim_fib4_rt_insert drivers/net/netdevsim/fib.c:432 [inline]
 nsim_fib4_event drivers/net/netdevsim/fib.c:464 [inline]
 nsim_fib_event+0x5564/0x60c4 drivers/net/netdevsim/fib.c:884
 nsim_fib_event_work+0x1d8/0x320 drivers/net/netdevsim/fib.c:1493
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:5     state:R  running task     stack:0     pid:4966  tgid:4966  ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: mld mld_ifc_work
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5533 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7284
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7463
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7487
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 __dev_queue_xmit+0x14d4/0x2bc0 net/core/dev.c:4961
 dev_queue_xmit include/linux/netdevice.h:3461 [inline]
 neigh_hh_output include/net/neighbour.h:544 [inline]
 neigh_output include/net/neighbour.h:558 [inline]
 ip6_finish_output2+0xd24/0x1b68 net/ipv6/ip6_output.c:138
 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]
 ip6_finish_output+0x230/0x618 net/ipv6/ip6_output.c:221
 NF_HOOK_COND include/linux/netfilter.h:314 [inline]
 ip6_output+0x2d0/0x644 net/ipv6/ip6_output.c:248
 dst_output include/net/dst.h:470 [inline]
 NF_HOOK+0x14c/0x464 include/linux/netfilter.h:325
 mld_sendpack+0x7f4/0xfec net/ipv6/mcast.c:1890
 mld_send_cr net/ipv6/mcast.c:2191 [inline]
 mld_ifc_work+0x76c/0x9e4 net/ipv6/mcast.c:2739
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:1     state:R  running task     stack:0     pid:10    tgid:10    ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5533 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7284
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7463
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7487
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:923 [inline]
 mod_peer_timer+0x21c/0x25c drivers/net/wireguard/timers.c:38
 wg_timers_data_sent+0xb4/0xc8 drivers/net/wireguard/timers.c:151
 wg_packet_create_data_done drivers/net/wireguard/send.c:257 [inline]
 wg_packet_tx_worker+0x204/0x75c drivers/net/wireguard/send.c:276
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:0     state:R  running task     stack:0     pid:9     tgid:9     ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: events nsim_fib_event_work
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5533 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7284
 __schedule_loop kernel/sched/core.c:7361 [inline]
 schedule+0x13c/0x20c kernel/sched/core.c:7376
 schedule_timeout+0x13c/0x28c kernel/time/sleep_timeout.c:99
 schedule_timeout_uninterruptible+0x78/0xbc kernel/time/sleep_timeout.c:158
 msleep+0x3c/0x68 kernel/time/sleep_timeout.c:318
 nsim_fib4_rt_add drivers/net/netdevsim/fib.c:369 [inline]
 nsim_fib4_rt_insert drivers/net/netdevsim/fib.c:432 [inline]
 nsim_fib4_event drivers/net/netdevsim/fib.c:464 [inline]
 nsim_fib_event+0x5564/0x60c4 drivers/net/netdevsim/fib.c:884
 nsim_fib_event_work+0x1d8/0x320 drivers/net/netdevsim/fib.c:1493
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
pool 2:
task:kworker/0:2     state:R  running task     stack:0     pid:866   tgid:866   ppid:2      task_flags:0x4208060 flags:0x00000010
Workqueue: wg-kex-wg1 wg_packet_handshake_receive_worker
Call trace:
 __switch_to+0x2b4/0x6e4 arch/arm64/kernel/process.c:775 (T)
 context_switch kernel/sched/core.c:5533 [inline]
 __schedule+0x1370/0x2d80 kernel/sched/core.c:7284
 preempt_schedule_common+0xd4/0x190 kernel/sched/core.c:7463
 preempt_schedule+0x60/0x78 kernel/sched/core.c:7487
 __local_bh_enable_ip+0x20c/0x35c kernel/softirq.c:480
 local_bh_enable include/linux/bottom_half.h:33 [inline]
 __alloc_skb+0x1c8/0x610 net/core/skbuff.c:699
 alloc_skb include/linux/skbuff.h:1384 [inline]
 wg_socket_send_buffer_to_peer+0x44/0x174 drivers/net/wireguard/socket.c:191
 wg_packet_send_handshake_response+0x168/0x264 drivers/net/wireguard/send.c:103
 wg_receive_handshake_packet drivers/net/wireguard/receive.c:154 [inline]
 wg_packet_handshake_receive_worker+0x570/0xcf8 drivers/net/wireguard/receive.c:213
 process_one_work kernel/workqueue.c:3396 [inline]
 process_scheduled_works+0x91c/0x1250 kernel/workqueue.c:3479
 worker_thread+0x798/0xbd0 kernel/workqueue.c:3560
 kthread+0x304/0x3d4 kernel/kthread.c:436
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

From carges at cloudflare.com  Wed Sep  2 15:11:37 2026
From: carges at cloudflare.com (Chris J Arges)
Date: Wed, 02 Sep 2026 15:11:37 -0000
Subject: [PATCH net] wireguard: wait for per-peer crypto during removal
Message-ID: <20260902-fix-wg-peer-removal-v1-1-7a0190f5cdb1@cloudflare.com>

Calling peer_remove_after_dead() currently flushes device-wide packet
crypto and handshake workqueues while holding RTNL. This is problematic as
unrelated peers can continue adding work onto those queues blocking other
tasks that want to take the RTNL lock.

Instead, this patch proposes tracking pending crypto handoffs for each
peer using a counter. After marking the peer dead, synchronize_net()
prevents new submissions; wait for pending crypto workers to schedule TX
work or RX NAPI. Then flush only the peer's transmit packet and handshake
work.

This scopes teardown synchronization to the removed peer and prevents
unrelated peers from extending the RTNL hold time.

Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Chris J Arges <carges at cloudflare.com>
---
 drivers/net/wireguard/peer.c     | 30 ++++++++++++++++--------------
 drivers/net/wireguard/peer.h     |  1 +
 drivers/net/wireguard/queueing.h |  6 ++++++
 3 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireguard/peer.c b/drivers/net/wireguard/peer.c
index 1cb502a932e0..f7a9c437b5b8 100644
--- a/drivers/net/wireguard/peer.c
+++ b/drivers/net/wireguard/peer.c
@@ -14,6 +14,7 @@
 #include <linux/lockdep.h>
 #include <linux/rcupdate.h>
 #include <linux/list.h>
+#include <linux/wait_bit.h>
 
 static struct kmem_cache *peer_cache;
 static atomic64_t peer_counter = ATOMIC64_INIT(0);
@@ -49,6 +50,8 @@ struct wg_peer *wg_peer_create(struct wg_device *wg,
 	INIT_WORK(&peer->transmit_packet_work, wg_packet_tx_worker);
 	wg_prev_queue_init(&peer->tx_queue);
 	wg_prev_queue_init(&peer->rx_queue);
+	/* Keep this above zero until teardown prevents new packet handoffs. */
+	atomic_set(&peer->packet_crypt_pending, 1);
 	rwlock_init(&peer->endpoint_lock);
 	kref_init(&peer->refcount);
 	skb_queue_head_init(&peer->staged_packet_queue);
@@ -105,28 +108,27 @@ static void peer_remove_after_dead(struct wg_peer *peer)
 	 */
 	wg_timers_stop(peer);
 
-	/* The transition between packet encryption/decryption queues isn't
-	 * guarded by is_dead, but each reference's life is strictly bounded by
-	 * two generations: once for parallel crypto and once for serial
-	 * ingestion, so we can simply flush twice, and be sure that we no
-	 * longer have references inside these queues.
+	/* Lookup removal and is_dead prevent new packets from entering the
+	 * parallel crypto queues after synchronize_net() waits for pre-existing
+	 * submission paths. Drop the initial count and wait for existing packets
+	 * to finish scheduling their serial TX work or RX NAPI processing.
 	 */
+	atomic_dec(&peer->packet_crypt_pending);
+	wait_var_event(&peer->packet_crypt_pending,
+		       !atomic_read_acquire(&peer->packet_crypt_pending));
+
+	flush_work(&peer->transmit_packet_work);
 
-	/* a) For encrypt/decrypt. */
-	flush_workqueue(peer->device->packet_crypt_wq);
-	/* b.1) For send (but not receive, since that's napi). */
-	flush_workqueue(peer->device->packet_crypt_wq);
-	/* b.2.1) For receive (but not send, since that's wq). */
 	napi_disable(&peer->napi);
-	/* b.2.1) It's now safe to remove the napi struct, which must be done
+	/* It's now safe to remove the napi struct, which must be done
 	 * here from process context.
 	 */
 	netif_napi_del(&peer->napi);
 
-	/* Ensure any workstructs we own (like transmit_handshake_work or
-	 * clear_peer_work) no longer are in use.
+	/* clear_peer_work was flushed by wg_timers_stop(). Ensure the remaining
+	 * peer-owned handshake work is no longer in use.
 	 */
-	flush_workqueue(peer->device->handshake_send_wq);
+	flush_work(&peer->transmit_handshake_work);
 
 	/* After the above flushes, a peer might still be active in a few
 	 * different contexts: 1) from xmit(), before hitting is_dead and
diff --git a/drivers/net/wireguard/peer.h b/drivers/net/wireguard/peer.h
index 718fb42bdac7..64412c67f413 100644
--- a/drivers/net/wireguard/peer.h
+++ b/drivers/net/wireguard/peer.h
@@ -37,6 +37,7 @@ struct endpoint {
 struct wg_peer {
 	struct wg_device *device;
 	struct prev_queue tx_queue, rx_queue;
+	atomic_t packet_crypt_pending;
 	struct sk_buff_head staged_packet_queue;
 	int serial_work_cpu;
 	bool is_dead;
diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 79b6d70de236..fdd34f0f15a6 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -11,6 +11,7 @@
 #include <linux/skbuff.h>
 #include <linux/ip.h>
 #include <linux/ipv6.h>
+#include <linux/wait_bit.h>
 #include <net/ip_tunnels.h>
 
 struct wg_device;
@@ -161,6 +162,7 @@ static inline int wg_queue_enqueue_per_device_and_peer(
 	 */
 	if (unlikely(!wg_prev_queue_enqueue(peer_queue, skb)))
 		return -ENOSPC;
+	atomic_inc(&PACKET_PEER(skb)->packet_crypt_pending);
 
 	/* Then we queue it up in the device queue, which consumes the
 	 * packet as soon as it can.
@@ -182,6 +184,8 @@ static inline void wg_queue_enqueue_per_peer_tx(struct sk_buff *skb, enum packet
 	atomic_set_release(&PACKET_CB(skb)->state, state);
 	queue_work_on(wg_cpumask_choose_online(&peer->serial_work_cpu, peer->internal_id),
 		      peer->device->packet_crypt_wq, &peer->transmit_packet_work);
+	if (atomic_dec_and_test(&peer->packet_crypt_pending))
+		wake_up_var(&peer->packet_crypt_pending);
 	wg_peer_put(peer);
 }
 
@@ -194,6 +198,8 @@ static inline void wg_queue_enqueue_per_peer_rx(struct sk_buff *skb, enum packet
 
 	atomic_set_release(&PACKET_CB(skb)->state, state);
 	napi_schedule(&peer->napi);
+	if (atomic_dec_and_test(&peer->packet_crypt_pending))
+		wake_up_var(&peer->packet_crypt_pending);
 	wg_peer_put(peer);
 }
 

---
base-commit: 70f3995830d3f1e79faa14eb0605914f778feca9
change-id: 20260901-fix-wg-peer-removal-43fc390d0311

Best regards,
--  
Chris J Arges <carges at cloudflare.com>


From carges at cloudflare.com  Sun Sep 13 12:19:24 2026
From: carges at cloudflare.com (Chris J Arges)
Date: Sun, 13 Sep 2026 12:19:24 -0000
Subject: [PATCH net v2] wireguard: wait for per-peer crypto during removal
Message-ID: <20260913-fix-wg-peer-removal-v2-1-0cade985245a@cloudflare.com>

Calling peer_remove_after_dead() currently flushes device-wide packet
crypto and handshake workqueues while holding RTNL. This is problematic as
unrelated peers can continue adding work to those queues, blocking other
tasks that want to take the RTNL lock.

Instead, this patch tracks pending crypto handoffs for each peer using a
counter. After marking the peer dead, synchronize_net() prevents new
submissions. Next, wait for pending crypto workers to schedule TX work and
for RX NAPI to drain the peer's RX queue. Then flush only the peer's TX
packet and handshake work.

This scopes teardown synchronization to the removed peer and prevents
unrelated peers from extending the RTNL hold time.

Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Chris J Arges <carges at cloudflare.com>
---
Changes in v2:
- wait for RX packets to drain from peer?s NAPI queue
- Link to v1: https://patch.msgid.link/20260902-fix-wg-peer-removal-v1-1-7a0190f5cdb1 at cloudflare.com

To: "Jason A. Donenfeld" <Jason at zx2c4.com>
To: Andrew Lunn <andrew+netdev at lunn.ch>
To: "David S. Miller" <davem at davemloft.net>
To: Eric Dumazet <edumazet at google.com>
To: Jakub Kicinski <kuba at kernel.org>
To: Paolo Abeni <pabeni at redhat.com>
Cc: wireguard at lists.zx2c4.com
Cc: netdev at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/net/wireguard/peer.c     | 30 ++++++++++++++++--------------
 drivers/net/wireguard/peer.h     |  1 +
 drivers/net/wireguard/queueing.h |  4 ++++
 drivers/net/wireguard/receive.c  |  4 +++-
 4 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireguard/peer.c b/drivers/net/wireguard/peer.c
index 1cb502a932e0..34842b33b28a 100644
--- a/drivers/net/wireguard/peer.c
+++ b/drivers/net/wireguard/peer.c
@@ -14,6 +14,7 @@
 #include <linux/lockdep.h>
 #include <linux/rcupdate.h>
 #include <linux/list.h>
+#include <linux/wait_bit.h>
 
 static struct kmem_cache *peer_cache;
 static atomic64_t peer_counter = ATOMIC64_INIT(0);
@@ -49,6 +50,8 @@ struct wg_peer *wg_peer_create(struct wg_device *wg,
 	INIT_WORK(&peer->transmit_packet_work, wg_packet_tx_worker);
 	wg_prev_queue_init(&peer->tx_queue);
 	wg_prev_queue_init(&peer->rx_queue);
+	/* Keep this above zero until teardown prevents new packet handoffs. */
+	atomic_set(&peer->packet_crypt_pending, 1);
 	rwlock_init(&peer->endpoint_lock);
 	kref_init(&peer->refcount);
 	skb_queue_head_init(&peer->staged_packet_queue);
@@ -105,28 +108,27 @@ static void peer_remove_after_dead(struct wg_peer *peer)
 	 */
 	wg_timers_stop(peer);
 
-	/* The transition between packet encryption/decryption queues isn't
-	 * guarded by is_dead, but each reference's life is strictly bounded by
-	 * two generations: once for parallel crypto and once for serial
-	 * ingestion, so we can simply flush twice, and be sure that we no
-	 * longer have references inside these queues.
+	/* Lookup removal and is_dead prevent new packets from entering the
+	 * parallel crypto queues after synchronize_net() waits for pre-existing
+	 * submission paths. Drop the initial count and wait for existing TX
+	 * packets to schedule their serial work and RX packets to leave rx_queue.
 	 */
+	atomic_dec(&peer->packet_crypt_pending);
+	wait_var_event(&peer->packet_crypt_pending,
+		       !atomic_read_acquire(&peer->packet_crypt_pending));
+
+	flush_work(&peer->transmit_packet_work);
 
-	/* a) For encrypt/decrypt. */
-	flush_workqueue(peer->device->packet_crypt_wq);
-	/* b.1) For send (but not receive, since that's napi). */
-	flush_workqueue(peer->device->packet_crypt_wq);
-	/* b.2.1) For receive (but not send, since that's wq). */
 	napi_disable(&peer->napi);
-	/* b.2.1) It's now safe to remove the napi struct, which must be done
+	/* It's now safe to remove the napi struct, which must be done
 	 * here from process context.
 	 */
 	netif_napi_del(&peer->napi);
 
-	/* Ensure any workstructs we own (like transmit_handshake_work or
-	 * clear_peer_work) no longer are in use.
+	/* clear_peer_work was flushed by wg_timers_stop(). Ensure the remaining
+	 * peer-owned handshake work is no longer in use.
 	 */
-	flush_workqueue(peer->device->handshake_send_wq);
+	flush_work(&peer->transmit_handshake_work);
 
 	/* After the above flushes, a peer might still be active in a few
 	 * different contexts: 1) from xmit(), before hitting is_dead and
diff --git a/drivers/net/wireguard/peer.h b/drivers/net/wireguard/peer.h
index 718fb42bdac7..64412c67f413 100644
--- a/drivers/net/wireguard/peer.h
+++ b/drivers/net/wireguard/peer.h
@@ -37,6 +37,7 @@ struct endpoint {
 struct wg_peer {
 	struct wg_device *device;
 	struct prev_queue tx_queue, rx_queue;
+	atomic_t packet_crypt_pending;
 	struct sk_buff_head staged_packet_queue;
 	int serial_work_cpu;
 	bool is_dead;
diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 79b6d70de236..5ce57565c8ff 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -11,6 +11,7 @@
 #include <linux/skbuff.h>
 #include <linux/ip.h>
 #include <linux/ipv6.h>
+#include <linux/wait_bit.h>
 #include <net/ip_tunnels.h>
 
 struct wg_device;
@@ -161,6 +162,7 @@ static inline int wg_queue_enqueue_per_device_and_peer(
 	 */
 	if (unlikely(!wg_prev_queue_enqueue(peer_queue, skb)))
 		return -ENOSPC;
+	atomic_inc(&PACKET_PEER(skb)->packet_crypt_pending);
 
 	/* Then we queue it up in the device queue, which consumes the
 	 * packet as soon as it can.
@@ -182,6 +184,8 @@ static inline void wg_queue_enqueue_per_peer_tx(struct sk_buff *skb, enum packet
 	atomic_set_release(&PACKET_CB(skb)->state, state);
 	queue_work_on(wg_cpumask_choose_online(&peer->serial_work_cpu, peer->internal_id),
 		      peer->device->packet_crypt_wq, &peer->transmit_packet_work);
+	if (atomic_dec_and_test(&peer->packet_crypt_pending))
+		wake_up_var(&peer->packet_crypt_pending);
 	wg_peer_put(peer);
 }
 
diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c
index 824bbefce61c..bb35e3205491 100644
--- a/drivers/net/wireguard/receive.c
+++ b/drivers/net/wireguard/receive.c
@@ -476,9 +476,11 @@ int wg_packet_rx_poll(struct napi_struct *napi, int budget)
 
 next:
 		wg_noise_keypair_put(keypair, false);
-		wg_peer_put(peer);
 		if (unlikely(free))
 			dev_kfree_skb(skb);
+		if (atomic_dec_and_test(&peer->packet_crypt_pending))
+			wake_up_var(&peer->packet_crypt_pending);
+		wg_peer_put(peer);
 
 		if (++work_done >= budget)
 			break;

---
base-commit: 70f3995830d3f1e79faa14eb0605914f778feca9
change-id: 20260901-fix-wg-peer-removal-43fc390d0311

Best regards,
--  
Chris J Arges <carges at cloudflare.com>


From carges at cloudflare.com  Wed Sep 16 16:40:28 2026
From: carges at cloudflare.com (Chris Arges)
Date: Wed, 16 Sep 2026 16:40:28 -0000
Subject: [PATCH net v2] wireguard: wait for per-peer crypto during removal
In-Reply-To: <aqpqEIy_h0DIywRy@zx2c4.com>
References: <20260913-fix-wg-peer-removal-v2-1-0cade985245a@cloudflare.com>
 <aqpqEIy_h0DIywRy@zx2c4.com>
Message-ID: <aqrGeOpbu_u-CBes@20HS2G4>

On 2026-09-16 12:06:08, Jason A. Donenfeld wrote:
> On Sun, Sep 13, 2026 at 07:19:08AM -0500, Chris J Arges wrote:
> > Calling peer_remove_after_dead() currently flushes device-wide packet
> > crypto and handshake workqueues while holding RTNL. This is problematic as
> > unrelated peers can continue adding work to those queues, blocking other
> > tasks that want to take the RTNL lock.
> > 
> > Instead, this patch tracks pending crypto handoffs for each peer using a
> > counter. After marking the peer dead, synchronize_net() prevents new
> > submissions. Next, wait for pending crypto workers to schedule TX work and
> > for RX NAPI to drain the peer's RX queue. Then flush only the peer's TX
> > packet and handshake work.
> > 
> > This scopes teardown synchronization to the removed peer and prevents
> > unrelated peers from extending the RTNL hold time.
> >  struct wg_device;
> > @@ -161,6 +162,7 @@ static inline int wg_queue_enqueue_per_device_and_peer(
> >  	 */
> >  	if (unlikely(!wg_prev_queue_enqueue(peer_queue, skb)))
> >  		return -ENOSPC;
> > +	atomic_inc(&PACKET_PEER(skb)->packet_crypt_pending);
> >  
> >  	/* Then we queue it up in the device queue, which consumes the
> >  	 * packet as soon as it can.
> > @@ -182,6 +184,8 @@ static inline void wg_queue_enqueue_per_peer_tx(struct sk_buff *skb, enum packet
> >  	atomic_set_release(&PACKET_CB(skb)->state, state);
> >  	queue_work_on(wg_cpumask_choose_online(&peer->serial_work_cpu, peer->internal_id),
> >  		      peer->device->packet_crypt_wq, &peer->transmit_packet_work);
> > +	if (atomic_dec_and_test(&peer->packet_crypt_pending))
> > +		wake_up_var(&peer->packet_crypt_pending);
> >  	wg_peer_put(peer);
> >  }
> >  
> > diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c
> > index 824bbefce61c..bb35e3205491 100644
> > --- a/drivers/net/wireguard/receive.c
> > +++ b/drivers/net/wireguard/receive.c
> > @@ -476,9 +476,11 @@ int wg_packet_rx_poll(struct napi_struct *napi, int budget)
> >  
> >  next:
> >  		wg_noise_keypair_put(keypair, false);
> > -		wg_peer_put(peer);
> >  		if (unlikely(free))
> >  			dev_kfree_skb(skb);
> > +		if (atomic_dec_and_test(&peer->packet_crypt_pending))
> > +			wake_up_var(&peer->packet_crypt_pending);
> > +		wg_peer_put(peer);
> 
> This adds two atomic updates to a per-peer counter for every RX packet
> and TX batch. That could introduce contention across crypto workers. I
> suppose it'd be good to see some measurements in if this changes
> anything. Certainly it should change _something_. Question is by how
> much.
> 
> Jason

Thanks, I'll get some numbers here and share. We're testing this on some
production machines now. In addition I'll get numbers from my synthetic testing
and report back.

--chris

From d at ilvokhin.com  Fri Sep 18 17:36:41 2026
From: d at ilvokhin.com (Dmitry Ilvokhin)
Date: Fri, 18 Sep 2026 17:36:41 -0000
Subject: [PATCH] wg-quick: darwin: fix set_dns() and del_dns() race
Message-ID: <20260918173616.358826-1-d@ilvokhin.com>

The monitor deamon restores the DNS servers by running del_dns() from
its INT, TERM and EXIT trap. Every route event also schedules an ALRM 2
seconds later, and the ALRM trap runs set_dns().

If ALRM arrives during cleanup, set_dns() can run in the middle of
del_dns(), and the DNS servers may not be restored after the WireGuard
interface is removed.

Ignore ALRM in cleanup signal handler to avoid this race.

Signed-off-by: Dmitry Ilvokhin <d at ilvokhin.com>
---
 src/wg-quick/darwin.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wg-quick/darwin.bash b/src/wg-quick/darwin.bash
index 0179afb..20a21ce 100755
--- a/src/wg-quick/darwin.bash
+++ b/src/wg-quick/darwin.bash
@@ -323,7 +323,7 @@ del_dns() {
 
 monitor_daemon() {
 	echo "[+] Backgrounding route monitor" >&2
-	(trap 'del_routes; del_dns; exit 0' INT TERM EXIT
+	(trap 'trap "" ALRM; del_routes; del_dns; exit 0' INT TERM EXIT
 	exec >/dev/null 2>&1
 	exec 19< <(exec route -n monitor)
 	local event bpid=$BASHPID mpid=$!
-- 
2.54.0 (Apple Git-157)


From carges at cloudflare.com  Fri Sep 18 20:48:48 2026
From: carges at cloudflare.com (Chris Arges)
Date: Fri, 18 Sep 2026 20:48:48 -0000
Subject: [PATCH net v2] wireguard: wait for per-peer crypto during removal
In-Reply-To: <aqpqEIy_h0DIywRy@zx2c4.com>
References: <20260913-fix-wg-peer-removal-v2-1-0cade985245a@cloudflare.com>
 <aqpqEIy_h0DIywRy@zx2c4.com>
Message-ID: <aq2jp8lXwSIqihaj@20HS2G4>

On 2026-09-16 12:06:08, Jason A. Donenfeld wrote:
> On Sun, Sep 13, 2026 at 07:19:08AM -0500, Chris J Arges wrote:
> > Calling peer_remove_after_dead() currently flushes device-wide packet
> > crypto and handshake workqueues while holding RTNL. This is problematic as
> > unrelated peers can continue adding work to those queues, blocking other
> > tasks that want to take the RTNL lock.
> > 
> > Instead, this patch tracks pending crypto handoffs for each peer using a
> > counter. After marking the peer dead, synchronize_net() prevents new
> > submissions. Next, wait for pending crypto workers to schedule TX work and
> > for RX NAPI to drain the peer's RX queue. Then flush only the peer's TX
> > packet and handshake work.
> > 
> > This scopes teardown synchronization to the removed peer and prevents
> > unrelated peers from extending the RTNL hold time.
> >  struct wg_device;
> > @@ -161,6 +162,7 @@ static inline int wg_queue_enqueue_per_device_and_peer(
> >  	 */
> >  	if (unlikely(!wg_prev_queue_enqueue(peer_queue, skb)))
> >  		return -ENOSPC;
> > +	atomic_inc(&PACKET_PEER(skb)->packet_crypt_pending);
> >  
> >  	/* Then we queue it up in the device queue, which consumes the
> >  	 * packet as soon as it can.
> > @@ -182,6 +184,8 @@ static inline void wg_queue_enqueue_per_peer_tx(struct sk_buff *skb, enum packet
> >  	atomic_set_release(&PACKET_CB(skb)->state, state);
> >  	queue_work_on(wg_cpumask_choose_online(&peer->serial_work_cpu, peer->internal_id),
> >  		      peer->device->packet_crypt_wq, &peer->transmit_packet_work);
> > +	if (atomic_dec_and_test(&peer->packet_crypt_pending))
> > +		wake_up_var(&peer->packet_crypt_pending);
> >  	wg_peer_put(peer);
> >  }
> >  
> > diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c
> > index 824bbefce61c..bb35e3205491 100644
> > --- a/drivers/net/wireguard/receive.c
> > +++ b/drivers/net/wireguard/receive.c
> > @@ -476,9 +476,11 @@ int wg_packet_rx_poll(struct napi_struct *napi, int budget)
> >  
> >  next:
> >  		wg_noise_keypair_put(keypair, false);
> > -		wg_peer_put(peer);
> >  		if (unlikely(free))
> >  			dev_kfree_skb(skb);
> > +		if (atomic_dec_and_test(&peer->packet_crypt_pending))
> > +			wake_up_var(&peer->packet_crypt_pending);
> > +		wg_peer_put(peer);
> 
> This adds two atomic updates to a per-peer counter for every RX packet
> and TX batch. That could introduce contention across crypto workers. I
> suppose it'd be good to see some measurements in if this changes
> anything. Certainly it should change _something_. Question is by how
> much.
> 
> Jason

Jason,

I benchmarked a wg peer on a 2 vCPU and 8 vCPU setup with 1200 byte
UDP payloads. Goal was stressing the path where these atomics are getting
incremented.
- patched 2 vCPU test showed ~1-2% reduction in throughput
- patched 8 vCPU test showed ~6% reduction in throughput (more contention)

My main goal is reducing the amount of time holding rtnl_lock when we remove a
peer. In our systems we frequently get hangs due to workloads bringing up and
tearing down wg peers. So perhaps I'll need to look into another approach
where we're not introducing something like a counter into the hotpath.

Thanks,
--chris

From alex at kearnsapuya.com  Thu Sep 24 16:21:36 2026
From: alex at kearnsapuya.com (Alex Kearns-Apuya)
Date: Thu, 24 Sep 2026 09:21:36 -0700 (PDT)
Subject: [PATCH] wg-quick: darwin: ignore pending SIGALRM during monitor
 teardown
Message-ID: <2d6f.6f3e213e1d9e4196.m1.039e1d20-b834-11f1-b1cb-525400b938ca.1a0d438eff2@bounce-zem.kearnsapuya.com>

When DNS is configured, the route monitor subshell traps ALRM to
set_dns and, after every route event it handles, schedules
`sleep 2 && kill -ALRM $bpid` in the background. Its INT/TERM/EXIT trap
runs del_routes and del_dns but never disarms the ALRM handler, so if
the monitor handled a route event in the two seconds before teardown
(removing the interface generates route events of its own), the pending
ALRM is delivered while del_dns is restoring the network services.
set_dns then runs from the trap and re-pins every service to the
tunnel's DNS servers, leaving them pinned after the interface is gone.

Observed on macOS 27.2 with Homebrew wireguard-tools (the same code is
at current master) and a config with a DNS= line, sampling the
SystemConfiguration preferences at 10 Hz during `wg-quick down`: pinned
services went 6 -> 1 as del_dns ran, then back to 6 in set_dns order,
and 5 stayed pinned after the teardown finished. It reproduced on 1 of
2 controlled downs, plus one unprompted occurrence, and does not depend
on how `down` is invoked.

Ignore ALRM first thing in the exit trap. Resetting it with
`trap - ALRM` is not enough: SIGALRM's default action terminates the
subshell, which would abort the restore instead. With this change, 6 of
6 up/down cycles restored DNS, with the monitor still lingering
1.2-5.4 s past the interface teardown each time (the triggering
condition).

Configs without DNS= never install the ALRM trap and are unaffected.

Signed-off-by: Alex Kearns-Apuya <alex at kearnsapuya.com>
---
 src/wg-quick/darwin.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wg-quick/darwin.bash b/src/wg-quick/darwin.bash
index 0179afb..20a21ce 100755
--- a/src/wg-quick/darwin.bash
+++ b/src/wg-quick/darwin.bash
@@ -323,7 +323,7 @@ del_dns() {
 
 monitor_daemon() {
 	echo "[+] Backgrounding route monitor" >&2
-	(trap 'del_routes; del_dns; exit 0' INT TERM EXIT
+	(trap 'trap "" ALRM; del_routes; del_dns; exit 0' INT TERM EXIT
 	exec >/dev/null 2>&1
 	exec 19< <(exec route -n monitor)
 	local event bpid=$BASHPID mpid=$!
-- 
2.54.0 (Apple Git-157)


From d at ilvokhin.com  Wed Sep 30 10:30:41 2026
From: d at ilvokhin.com (Dmitry Ilvokhin)
Date: Wed, 30 Sep 2026 10:30:41 +0000
Subject: [PATCH] wg-quick: darwin: fix set_dns() and del_dns() race
Message-ID: <20260930103041.102065-1-d@ilvokhin.com>

The monitor deamon restores the DNS servers by running del_dns() from
its INT, TERM and EXIT trap. Every route event also schedules an ALRM 2
seconds later, and the ALRM trap runs set_dns().

If ALRM arrives during cleanup, set_dns() can run in the middle of
del_dns(), and the DNS servers may not be restored after the WireGuard
interface is removed.

Ignore ALRM in cleanup signal handler to avoid this race.

Signed-off-by: Dmitry Ilvokhin <d at ilvokhin.com>
---
Resending the patch, since mailing list didn't accept it first time,
because I was not a member of the list.

 src/wg-quick/darwin.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wg-quick/darwin.bash b/src/wg-quick/darwin.bash
index 0179afb..20a21ce 100755
--- a/src/wg-quick/darwin.bash
+++ b/src/wg-quick/darwin.bash
@@ -323,7 +323,7 @@ del_dns() {
 
 monitor_daemon() {
 	echo "[+] Backgrounding route monitor" >&2
-	(trap 'del_routes; del_dns; exit 0' INT TERM EXIT
+	(trap 'trap "" ALRM; del_routes; del_dns; exit 0' INT TERM EXIT
 	exec >/dev/null 2>&1
 	exec 19< <(exec route -n monitor)
 	local event bpid=$BASHPID mpid=$!
-- 
2.54.0 (Apple Git-157)


From frank.martino1 at protonmail.com  Wed Sep 30 17:04:42 2026
From: frank.martino1 at protonmail.com (frank.martino1)
Date: Wed, 30 Sep 2026 17:04:42 +0000
Subject: wg-quick fails with RTNETLINK: Invalid argument
Message-ID: <fJAqhQFnI1Mw3nbgZZmCgA99Pdg7wdkUNp9n8MGFPCb0sJQxcDPkAvF3XemLHS7DsEDCS2dg5DiwpXvxN-SIVyVUY7Q3SUK_Ecbj-bi4Qjk=@protonmail.com>



### Description of the Bug
When switching WireGuard servers using `wg-quick` on a configuration file that specifies `Table = off`, the initialization fails during the IP address assignment phase, throwing the following error:
`RTNETLINK answers: Invalid argument`

### Steps to Reproduce

1. Create two WireGuard configuration files (`serverA.conf` and `serverB.conf`) with `Table = off` and different `Endpoint` IPs.
2. Connect to the first server: `sudo wg-quick up serverA`
3. Implement manual host routes to the endpoint via your physical gateway.
4. Switch to the second server in a single sequence:
? ?```bash
? ?sudo wg-quick down serverA && sudo wg-quick up serverB
? ?```
5. Observe the `RTNETLINK answers: Invalid argument` failure printing out during the execution trace of `serverB`.

### Expected Behavior

`wg-quick` should cleanly tear down all interface states from the previous execution, allowing the kernel network namespace to settle so that the newly spawned interface can bind its IP address and configuration parameters successfully on the first attempt.

### Actual Behavior / Execution Trace

The script wrapper executes its hardcoded command sequence:
1. `ip link add wg0 type wireguard`
2. `wg setconf wg0 /dev/fd/63`
3. `ip -4 address add <ip>/32 dev wg0` ?<-- **CRASHES HERE with EINVAL**

### Root Cause Analysis

This bug is a timing and state synchronization race condition between `iproute2`, the `wireguard` kernel module, and Netfilter:

1. **Asynchronous Deletion Delay:** When `wg-quick down` deletes the virtual device link, the namespace unregistration and hook flushes happen asynchronously in the background.
2. **Socket Cache Pollution:** Because `wg-quick up` instantly creates a new interface container (`add_if`) and populates keys/endpoints (`set_config`), the module instantiates UDP sockets while the background cleanup is still running. The new socket structure inherits a dirty socket destination cache (`sk_dst_cache`) pointing to the *old* server IP.
3. **Netlink Veto:** When `wg-quick` subsequently tries to execute `ip address add`, the Netlink engine evaluates the active routing layout, detects an structural paradox (a new interface instance whose sockets are tied to an un-flushed legacy routing table index), and rejects the address assignment with `EINVAL`.
4. **Cascading Deadlock:** The failed state causes the kernel to loop handshake traffic destined for the old server into `OUT=wg0`, deadlocking local socket queues and freezing local DNS proxies.

### Environment & Configuration

* **OS / Kernel:** Linux Kernel (Stateful tracking via `nf_conntrack` enabled)
* **Tools:** `wg-quick` from `wireguard-tools`
* **Relevant Config Snippet:**
? ```ini
? [Interface]
? Address = 10.67.57.124/32
? Table = off
? ```

### Workaround / Possible Fix

The failure can be avoided entirely by performing an explicit, native protocol routing flush **prior** to initializing the new interface container. Adding the following block to the teardown sequence clears the routing indices from live memory, ensuring Netlink encounters a pristine workspace:

```bash
# Force the kernel to drop sticky server routing mappings before regenerating the link
sudo ip route flush dev <physical_interface> proto boot
sudo ip route flush cache
```

From nat.gist at gmail.com  Tue Sep  1 20:53:07 2026
From: nat.gist at gmail.com (Nat Gist)
Date: Tue, 01 Sep 2026 20:53:07 -0000
Subject: Windows App is unable to resolve DNS for IPv6 only endpoints.
Message-ID: <CABzftJ5vMrTQni1ouLVt=5jcZNQtTF_NKR7swmJhtHp98BEBGw@mail.gmail.com>

Problem description:
When using an ipv6 only endpoint the DNS resolution in windows app fails.

Steps to reproduce:
Using the windows app try to connect to an endpoint using it's
hostname where there is only an AAAA record and no A record.

Root Cause:
Trying to connect produces the following error
"Unable to resolve one or more DNS hostname endpoints: The requested
name is valid, but no data of the requested type was found."

The first half of the error message(before the :?) comes from ErrorDNSLookup
https://github.com/WireGuard/wireguard-windows/blob/4e6726c23ae9c5cb58e0c9910f3b7515621d133d/tunnel/service.go#L150

The second half(after the :) comes from WSANO_DATA documented here:
https://learn.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfow

Looking at the implementation of
resolveHostnameOnce(https://github.com/WireGuard/wireguard-windows/blob/4e6726c23ae9c5cb58e0c9910f3b7515621d133d/conf/dnsresolver_windows.go#L46)
The hints specify "Family: windows.AF_UNSPEC" which causes windows to
try and resolve both A and AAAA records, and it returns the error
WSANO_DATA when no IPv4 address is found. Somewhat oddly though not
too surprising the behavior for IPv4 only results seems to be no
error.

I'd suggest either querying each family separately and only failing
when both fail, or keep the existing AF_UNSPEC call and then doing a
subsequent AF_INET6 call if err WSANO_DATA is returned by the first
call to allow IPv6 only hosts to work.

Here's the redacted config I'm using for reference.
The endpoint only has an AAAA record. It doesn't have a public IPv4 address.

[Interface]
PrivateKey = [redacted]
Address = 10.10.10.3/32, fddd:28fa:bc9a::3/128
DNS = 192.168.10.1, fddd:28fa:bc9a::1
MTU = 1328

[Peer]
PublicKey = [redacted]
PresharedKey = [redacted]
AllowedIPs = 10.10.10.0/24, fddd:28fa:bc9a::/64, 192.168.10.0/24,
192.168.20.0/24, fda2:369:f8ec::/60, fda2:369:f8ec:10::/64
Endpoint = myhost.example.com:12345

From nat.gist at gmail.com  Wed Sep  2 13:42:48 2026
From: nat.gist at gmail.com (Nat Gist)
Date: Wed, 02 Sep 2026 13:42:48 -0000
Subject: Windows App is unable to resolve DNS for IPv6 only endpoints.
In-Reply-To: <CABzftJ5vMrTQni1ouLVt=5jcZNQtTF_NKR7swmJhtHp98BEBGw@mail.gmail.com>
References: <CABzftJ5vMrTQni1ouLVt=5jcZNQtTF_NKR7swmJhtHp98BEBGw@mail.gmail.com>
Message-ID: <CABzftJ6FnmmAXrqH0MT175XA5PT=ExNtvQfN43fvaHUSwkLGMg@mail.gmail.com>

So this issue is a little more subtle than I thought, I had some
configuration issues with my local IPv6 setup such that I wasn't
getting a global IPv6 address when testing this, but I did have a
local IPv6 address. If there's a valid global IPv6 address everything
works fine and the IPv6 endpoint is resolved. With AF_UNSPEC
presumably if there's no IPv6 address windows only tries to resolve
the A record since it assumes you don't have a global IPv6 address
anyway, this seems like a bad design decision in windows but it is
what it is.

In any case I think DNS resolution failure isn't the right error
message to have happen when the actual issue is a non-existent route
to the endpoint. So I think my suggestion of explicitly querying
AF_INT6 would still be worthwhile to implement even though there's no
issue in a properly configured IPv6 network.

I guess if you wanted to tunnel using local IPv6 addresses it'd fail
but I'm not sure why anyone would want to do that(other than for
testing).

Thanks,
Nat

On Tuesday, September 1st, 2026 at 4:53 PM, Nat Gist <nat.gist at gmail.com> wrote:

> Problem description:
> When using an ipv6 only endpoint the DNS resolution in windows app fails.
>
> Steps to reproduce:
> Using the windows app try to connect to an endpoint using it's hostname where there is only an AAAA record and no A record.
>
> Root Cause:
> Trying to connect produces the following error
> "Unable to resolve one or more DNS hostname endpoints: The requested name is valid, but no data of the requested type was found."
>
> The first half of the error message(before the : ) comes from ErrorDNSLookup
> https://github.com/WireGuard/wireguard-windows/blob/4e6726c23ae9c5cb58e0c9910f3b7515621d133d/tunnel/service.go#L150
>
> The second half(after the :) comes from WSANO_DATA documented here:
> https://learn.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfow
>
> Looking at the implementation of resolveHostnameOnce(https://github.com/WireGuard/wireguard-windows/blob/4e6726c23ae9c5cb58e0c9910f3b7515621d133d/conf/dnsresolver_windows.go#L46)
> The hints specify "Family: windows.AF_UNSPEC" which causes windows to try and resolve both A and AAAA records, and it returns the error WSANO_DATA when no IPv4 address is found. Somewhat oddly though not too surprising the behavior for IPv4 only results seems to be no error.
>
> I'd suggest either querying each family separately and only failing when both fail, or keep the existing AF_UNSPEC call and then doing a subsequent AF_INET6 call if err WSANO_DATA is returned by the first call to allow IPv6 only hosts to work.
>
> Here's the redacted config I'm using for reference.
> The endpoint only has an AAAA record. It doesn't have a public IPv4 address.
>
> [Interface]
> PrivateKey = [redacted]
> Address = 10.10.10.3/32, fddd:28fa:bc9a::3/128
> DNS = 192.168.10.1, fddd:28fa:bc9a::1
> MTU = 1328
>
> [Peer]
> PublicKey = [redacted]
> PresharedKey = [redacted]
> AllowedIPs = 10.10.10.0/24, fddd:28fa:bc9a::/64, 192.168.10.0/24, 192.168.20.0/24, fda2:369:f8ec::/60, fda2:369:f8ec:10::/64
> Endpoint = myhost.example.com:12345
>
>

From wireguard at noci-ict.nl  Thu Sep  3 20:19:59 2026
From: wireguard at noci-ict.nl (wireguard at noci-ict.nl)
Date: Thu, 03 Sep 2026 20:19:59 -0000
Subject: Remove endpoint
In-Reply-To: <20260903202133.2383ecd75a9b94dec9dc3974@gmx.com>
References: <20260903202133.2383ecd75a9b94dec9dc3974@gmx.com>
Message-ID: <sRq6ygV7STOqiux06SNsXw@noci-ict.nl>

Why would you want that.....

If the endpoint (your mobile) stops transmitting then after the timeout time 
there will be no more packets....  from anywhere.
Mostly the clients will be on the mobile,
so after stopping sessions packets should stop.
And the system will ONLY respond to valid packets, port scanning will be hard 
to do. No response until a valid packet arrives to setup a connection.

So if you setup timeout to be a low value (10-20 seconds or so, assuming your 
regular roundtrip time would be <5 seconds)  there at most 10 seconds of traffic 
left.

Kind regards.

On Thursday, 3 September 2026 20:21:33 CEST Kent Friis wrote:
> I can specify a peer with no endpoint in wg0.conf. It will then simply
> not have an endpoint until it either receives a packet from the peer,
> or one is specified with wg set ... endpoint ip:port.
> 
> Now, I'm on a mobile connection, so when I log off, I want to remove
> the endpoint ip again so the "server" doesn't transmit stray packets
> to a mobile ip address.
> 
> I tried
> 
> wg set wg0 peer XXX endpoint 0:0
> wg set wg0 peer XXX endpoint off
> wg set wg0 peer XXX endpoint none
> wg set wg0 peer XXX endpoint ""
> 
> The first one sets the endpoint to 0.0.0.0 port 0, which is first of
> all, usually treated as a broadcast address, and second, AFAIK there is
> no port zero.
> 
> The other three give errors.
> 
> How to remove the endpoint while keeping the rest of the configuration?
> 
> /Kent






From zack at philomathiclife.com  Tue Sep 15 20:23:43 2026
From: zack at philomathiclife.com (Zack Newman)
Date: Tue, 15 Sep 2026 20:23:43 -0000
Subject: OpenBSD collaboration/peer-review request
Message-ID: <188dc861-f452-4830-9b47-e51c15faf41d@philomathiclife.com>

Unlike the fiasco that occurred with FreeBSD when WireGuard was attempted
to be implemented in the kernel, Matt Dunwoodie collaborated with Jason
A. Donenfeld with the OpenBSD-kernel implementation. Code is of course
rarely static but more of a "living thing". Over the past five years,
wireguard-openbsd[^1] has substantially deviated from the actual
OpenBSD code[^2]. This suggests that repository may actually be
"Abandoned" and should not be classified as "Active".

Without continued collaboration or at least periodic passive review, this
means the actual code in the kernel may no longer conform to the
WireGuard protocol. In the best case, reliability or compatibility issues
exist; in the worst case, a reduction in the cryptographic security
potentially to the point of exploitation exists.

Over the past five years, issues allegedly from the WireGuard
implementation have required changes to the code. One the more "recent"
commits[^3] has introduced mishandling of the MTU[^4] at least when vio(4)
is used for the underlying connection and IPv6 is used to establish the
VPN tunnel.

Would Jason or anyone from the WireGuard team be willing to collaborate
again with the OpenBSD developers even if that means a passive audit? I
realize Jason and probably most of the team are far more familiar with
Linux, so it will likely require communication with at least one active
OpenBSD kernel developer.

To be clear, I'm not pointing fingers at the WireGuard team nor OpenBSD
developers. I'm merely an "innocent" bystander that is mildly concerned
about the WireGuard implementation in OpenBSD. Note I'm _not_ an OpenBSD
developer myself; otherwise I'd offer my own services. Because I'm not a
developer, I decided to not CC an OpenBSD developer.

Thanks for your time,
Zack

[^1]: https://git.zx2c4.com/wireguard-openbsd/
[^2]: https://cvsweb.openbsd.org/log/src/sys/net/if_wg.c
[^3]: https://github.com/openbsd/src/commit/c06199859734d958552a581d72b4c0f910e68d7c
[^4]: https://marc.info/?l=openbsd-bugs&m=178935440057111&w=2

From razvan.cremenescu at gmail.com  Thu Sep 17 12:17:20 2026
From: razvan.cremenescu at gmail.com (Razvan Cremenescu)
Date: Thu, 17 Sep 2026 12:17:20 -0000
Subject: Add support for setting proxy settings
 (NETunnelNetworkSettings.proxySettings) in wireguard-apple
In-Reply-To: <CAEFWZ+MH3vtg5i1Tb0Poac_xc0ufFUQMcxcKx6kzKd0347trJA@mail.gmail.com>
References: <CAEFWZ+MH3vtg5i1Tb0Poac_xc0ufFUQMcxcKx6kzKd0347trJA@mail.gmail.com>
Message-ID: <D31D1D56-5BD9-47E3-9084-C192624C2CD2@gmail.com>

hi, i sent some patches some time ago .. why nobody bothers to even answer?

multumesc,
razvan

---
Razvan Cremenescu
razvan.cremenescu at gmail.com




> On 17 Sep 2026, at 10:59, Segev Finer <segev at swimm.io> wrote:
> 
> When using NEPacketTunnelProvider, you can also specify proxy
> settings, those are used by programs that query for the system proxy
> settings while connected to the WireGuard VPN, for example,
> Chromium/Chrome uses that (scutil --proxy shows the settings AFAIK),
> there is currently no way to set those settings in wireguard-apple,
> and the GUI for setting them, as available in builtin VPN providers in
> macOS is not available for the WireGuard VPN interface in the macOS
> GUI, so you are stuck with the default proxy settings, where some
> networks do require proxy settings, be it enabling auto-discovery, PAC
> URL, HTTP proxy URL, etc. like the default proxy settings GUI in macOS
> allows you to set. You can currently still use wireguard-tools/wg-quick
> which still uses, what I think is an undocumented interface?, to
> create a tun device, which doesn't affect those settings, but that's
> not as convenient or nice as using wireguard-apple.
> 
> Another thing that I noticed is that wireguard-apple seems to always
> use the default internet gateway, ignoring routing rules that say
> otherwise which prevent using it nested, or with other custom network
> interfaces, it would be nice to be able to control the outgoing
> interface in wireguard-apple. wireguard-tools/wg-quick adds a route
> that uses the default gateway which you can simply remove or modify
> manually if needed (Though a setting would be nicer of course), but
> wireguard-apple seems to somehow go through the default interface and
> ignores the routing rules.
> 
> I would have tried to contribute but Apple requires a paid developer
> account to develop network extensions.