CVE-2026-64009

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Check for underflow in xfrm_state_mtu<br /> <br /> Leo Lin reported OOB write issue in esp component:<br /> <br /> xfrm_state_mtu() returns u32 but performs its arithmetic in unsigned<br /> modulo-2^32 space using an attacker-influenced "header_len + authsize +<br /> net_adj" subtracted from a small "mtu" argument. A nobody user can<br /> install an IPv4 ESP tunnel SA with a large authentication key<br /> (XFRMA_ALG_AUTH_TRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc),<br /> configure a small interface MTU (68 bytes), and set XFRMA_TFCPAD to a<br /> large value. When a single UDP datagram is then sent through the<br /> tunnel, xfrm_state_mtu() underflows to a near-2^32 value, and<br /> esp_output() consumes it as a signed int via:<br /> <br /> padto = min(x-&gt;tfcpad, xfrm_state_mtu(x, mtu_cached))<br /> esp.tfclen = padto - skb-&gt;len (assigned to int)<br /> <br /> esp.tfclen ends up negative (e.g. -207). It is sign-extended to size_t<br /> when passed to memset() inside esp_output_fill_trailer(), producing a<br /> ~16 EB write of zeroes at skb_tail_pointer(skb). KASAN logs it as<br /> "Write of size 18446744073709551537 at addr ffff888...".<br /> <br /> Check for underflow and return 1. This causes the sendmsg attempt to<br /> fail with ENETUNREACH.