Re: [PATCH net] udp_tunnel: drop packets when hibernating

[Willem de Bruijn]

On Thu, Oct 8, 2026 at 3:58 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>
> Hi Willem,
>
> On Thu, Oct 8, 2026 at 8:37 PM Willem de Bruijn
> <willemdebruijn.kernel@xxxxxxxxx> wrote:
> > 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.
>
> Because I suppose (4) probably shouldn't be possible after (1). I
> explicitly clear the result of (4) in a PM notifier. It seems wrong
> for that to then be violated after. Similarly, userspace doesn't get
> packets after that point either.

Since this is an issue specific with security protocols and reuse of
their state across freeze and restore, is that the more suitable
location for this check? Drop transmit of packets with that risk
(unique for that connection nonce) only, if freezing.

> > Is this a problem specific to UDP tunnels?
>
> The stateless nature makes it more poignant there.

udp_queue_rcv_one_skb is the UDP hot path. Since it touches all
packets, the last resort for adding checks that are relevant too only
a small subset of packets.