From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
rafael@kernel.org, lenb@kernel.org, pavel@kernel.org,
willemdebruijn.kernel@gmail.com, kuba@kernel.org,
pabeni@redhat.com, linux-pm@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
stable@vger.kernel.org,
"Jérémy Jean" <jeremy.jean@oss.cyber.gouv.fr>
Subject: Re: [PATCH net] udp_tunnel: drop packets when hibernating
Date: Thu, 08 Oct 2026 14:37:24 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.cf8fec88827c@gmail.com> (raw)
In-Reply-To: <20261008124106.665014-1-Jason@zx2c4.com>
Jason A. Donenfeld wrote:
> The kernel's various networking applications keep churning away after
> userspace is frozen during hibernation, even as a memory snapshot is
> being made. This can lead many network applications to an inconsistent
> state, replaying packets and cryptographic state changes. For example,
> on wireguard, there's the possibility of this sequence:
>
> 1) hibernating begins
> 2) handshake state cleared
> 3) keypairs cleared
> 4) new handshake round trip completes
> 5) machine memory is snapshotted
> 6) packet is sent using new keypair
> 7) machine is restored to state (5)
> 8) packet is sent using new keypair
>
> The idea is to prevent (6) from happening, especially if (6) and (8)
> contain different data, but the same key and nonce. Presumably the same
> issue applies to other users of udp_tunnel too.
>
> Fix this by just dropping sending and receiving packets during the
> hibernation sequence.
A few high level questions:
If the issue is reuse of key + nonce during send, why include receive
side functions? Specifically tunnel (encap_rcv) functions.
Is this a problem specific to UDP tunnels?
> Cc: stable@vger.kernel.org
> Reported-by: Jérémy Jean <jeremy.jean@oss.cyber.gouv.fr>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> I wrote this patch in response to the issue Jérémy raised, but I'm not
> actually super familiar with all of the hibernation mechanics. If
> somebody working on PM would think about this matter too, I'd be much
> obliged.
>
> include/linux/freezer.h | 1 +
> net/ipv4/udp.c | 5 +++++
> net/ipv4/udp_tunnel_core.c | 5 +++++
> net/ipv6/ip6_udp_tunnel.c | 5 +++++
> net/ipv6/udp.c | 5 +++++
> 5 files changed, 21 insertions(+)
>
> diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> index 0a8c6c4d1a82..21d708dc4092 100644
> --- a/include/linux/freezer.h
> +++ b/include/linux/freezer.h
> @@ -76,6 +76,7 @@ static inline bool cgroup1_freezing(struct task_struct *task)
> #endif /* !CONFIG_CGROUP_FREEZER */
>
> #else /* !CONFIG_FREEZER */
> +#define pm_freezing (false)
> static inline bool frozen(struct task_struct *p) { return false; }
> static inline bool freezing(struct task_struct *p) { return false; }
> static inline void __thaw_task(struct task_struct *t) {}
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index b090bd1f59e8..5021932ad9f1 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -95,6 +95,7 @@
> #include <linux/netdevice.h>
> #include <linux/slab.h>
> #include <linux/sock_diag.h>
> +#include <linux/freezer.h>
> #include <net/tcp_states.h>
> #include <linux/skbuff.h>
> #include <linux/proc_fs.h>
> @@ -2425,6 +2426,10 @@ static int udp_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
> if (encap_rcv) {
> int ret;
>
> + /* Drop if we're hibernating */
> + if (unlikely(pm_freezing))
> + goto drop;
> +
> /* Verify checksum before giving to encap */
> if (udp_lib_checksum_complete(skb))
> goto csum_error;
> diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c
> index a128fe85620d..e3666ed96af7 100644
> --- a/net/ipv4/udp_tunnel_core.c
> +++ b/net/ipv4/udp_tunnel_core.c
> @@ -3,6 +3,7 @@
> #include <linux/errno.h>
> #include <linux/socket.h>
> #include <linux/kernel.h>
> +#include <linux/freezer.h>
> #include <net/dst_metadata.h>
> #include <net/flow.h>
> #include <net/udp.h>
> @@ -172,6 +173,10 @@ void udp_tunnel_xmit_skb(struct rtable *rt, struct sock *sk, struct sk_buff *skb
> {
> struct udphdr *uh;
>
> + /* Drop if we're hibernating */
> + if (unlikely(pm_freezing))
> + return;
> +
> __skb_push(skb, sizeof(*uh));
> skb_reset_transport_header(skb);
> uh = udp_hdr(skb);
> diff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c
> index 32525a051a6f..4a31e8cc8887 100644
> --- a/net/ipv6/ip6_udp_tunnel.c
> +++ b/net/ipv6/ip6_udp_tunnel.c
> @@ -7,6 +7,7 @@
> #include <linux/types.h>
> #include <linux/kernel.h>
> #include <linux/in6.h>
> +#include <linux/freezer.h>
> #include <net/udp.h>
> #include <net/udp_tunnel.h>
> #include <net/net_namespace.h>
> @@ -86,6 +87,10 @@ void udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sock *sk,
> struct udphdr *uh;
> struct ipv6hdr *ip6h;
>
> + /* Drop if we're hibernating */
> + if (unlikely(pm_freezing))
> + return;
> +
> __skb_push(skb, sizeof(*uh));
> skb_reset_transport_header(skb);
> uh = udp_hdr(skb);
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 93478d1ad576..db9c2050887d 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -34,6 +34,7 @@
> #include <linux/slab.h>
> #include <linux/uaccess.h>
> #include <linux/indirect_call_wrapper.h>
> +#include <linux/freezer.h>
> #include <trace/events/udp.h>
>
> #include <net/addrconf.h>
> @@ -848,6 +849,10 @@ static int udpv6_queue_rcv_one_skb(struct sock *sk, struct sk_buff *skb)
> if (encap_rcv) {
> int ret;
>
> + /* Drop if we're hibernating */
> + if (unlikely(pm_freezing))
> + goto drop;
> +
> /* Verify checksum before giving to encap */
> if (udp_lib_checksum_complete(skb))
> goto csum_error;
> --
> 2.56.0
>
next prev parent reply other threads:[~2026-10-08 18:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 12:40 [PATCH net] udp_tunnel: drop packets when hibernating Jason A. Donenfeld
2026-10-08 12:46 ` netdev-bot+sinfo
2026-10-08 12:47 ` Jason A. Donenfeld
2026-10-08 16:26 ` Jérémy Jean
2026-10-08 18:37 ` Willem de Bruijn [this message]
2026-10-08 19:58 ` Jason A. Donenfeld
2026-10-08 21:03 ` Willem de Bruijn
2026-10-10 21:49 ` Jason A. Donenfeld
2026-10-11 16:28 ` Willem de Bruijn
2026-10-09 1:57 ` kernel test robot
2026-10-09 4:06 ` kernel test robot
2026-10-09 23:47 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=willemdebruijn.kernel.cf8fec88827c@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=Jason@zx2c4.com \
--cc=jeremy.jean@oss.cyber.gouv.fr \
--cc=kuba@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.