Re: [PATCH net] xfrm: Check for underflow in xfrm_state_mtu

[Steffen Klassert <steffen.klassert@secunet.com>]

On Wed, May 13, 2026 at 10:49:14AM -0600, David Ahern wrote:
> From: David Ahern <dahern@nvidia.com>
> 
> Leo Lin reported OOB write issue in esp component:
> 
>   xfrm_state_mtu() returns u32 but performs its arithmetic in unsigned
>   modulo-2^32 space using an attacker-influenced "header_len + authsize +
>   net_adj" subtracted from a small "mtu" argument. A nobody user can
>   install an IPv4 ESP tunnel SA with a large authentication key
>   (XFRMA_ALG_AUTH_TRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc),
>   configure a small interface MTU (68 bytes), and set XFRMA_TFCPAD to a
>   large value. When a single UDP datagram is then sent through the
>   tunnel, xfrm_state_mtu() underflows to a near-2^32 value, and
>   esp_output() consumes it as a signed int via:
> 
>         padto      = min(x->tfcpad, xfrm_state_mtu(x, mtu_cached))
>         esp.tfclen = padto - skb->len   (assigned to int)
> 
>   esp.tfclen ends up negative (e.g. -207). It is sign-extended to size_t
>   when passed to memset() inside esp_output_fill_trailer(), producing a
>   ~16 EB write of zeroes at skb_tail_pointer(skb). KASAN logs it as
>   "Write of size 18446744073709551537 at addr ffff888...".
> 
> Check for underflow and return 1. This causes the sendmsg attempt to
> fail with ENETUNREACH.
> 
> Fixes: c5c252389374 ("[XFRM]: Optimize MTU calculation")
> Reported-by: Leo Lin <leo@depthfirst.com>
> Assisted-by: Codex:26.506.31004
> Signed-off-by: David Ahern <dahern@nvidia.com>

Applied, thanks a lot David!