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

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Jason A. Donenfeld wrote:
> On Thu, Oct 8, 2026 at 11:03 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> > 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.
> 
> I was thinking this is a pretty common problem to UDP apps in general,
> and it's confusing to have these sorts of replays due to hibernation
> that userspace doesn't have. It's an odd problem to expect every
> in-kernel user to fix independently, so maybe it'd be more clever to
> do this all in one place. I can put it in only wireguard, instead, if
> you feel really strongly about it. But I was thinking this just seemed
> like an odd behavior difference that could be easily fixed for
> everyone.

When it comes to security protocols, this does not cover many of them,
such as IPSec, MACSec, kTLS or PSP.

Independent of security protocols, is there a replay on thaw issue?
Your example points out that 6 and 8 can have different data, so this
is not a replay because of thaw, but a second transmission by the
security protocol, correct? If so, then other UDP protocols are not
necessarily affected: only the nonce reuse is the problematic aspect.

To avoid across UDP, udp_tunnel_xmit_skb would also be too narrow,
capturing only tunnel packets. Blocking transmission post snapshot
entirely may require quiescing at the device layer, something like
QUEUE_STATE_STACK_XOFF (if that isn't done yet, I don't know this
freeze process well).

> > 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.
> 
> Is there another way you'd suggest doing this? Some other trick for
> disabling the socket? I also am not keen on adding branches to hot
> paths.

At this layer or another, making pm_freezing a static_branch toggled
by freeze_processes() / thaw_processes() would make the branch a
NOOP in het hot path.

So far, most promising I see is blocking the new handshake in
Wireguard itself to avoid this from being possible. But that would
indeed require all other protocols to be warned and review for
individual fixes. A single choke point would be preferable, but I
do not think they share a single such code path.