CVE-2026-98241

What it actually does

Out-of-bounds read in xfrm6_local_rxpmtu() and xfrm6_local_error() when skb->sk points to a request_sock instead of a full inet6_sock during IPv6 XFRM PMTU or error handling on TCP SYN-ACK packets routed through an XFRM tunnel with reduced MTU.

Why it matters to the business

Local users on affected Linux systems can trigger kernel memory corruption leading to crashes, information leaks, or potential privilege escalation; widespread exposure across servers and devices using IPv6 with IPsec or XFRM, though exploitation remains theoretical given low EPSS and no known campaigns 17 days after disclosure.

How an attack unfolds

An attacker with local access crafts or manipulates network traffic that forces rerouting of a TCP SYN-ACK skb through an IPv6 XFRM tunnel route with a lower MTU, causing the error path to invoke the vulnerable callbacks with a mini-socket attached; the code then miscasts the request_sock and reads beyond its allocation into adjacent kernel memory.

How to fix it

Apply the upstream kernel patch that replaces direct skb->sk dereferences with skb_to_full_sk() checks and early returns when no full socket is present; rebuild and deploy updated kernels to all affected systems; monitor vendor backports for distribution-specific packages.

How to confirm the fix worked

Confirm presence of skb_to_full_sk() calls and the early bail-out logic inside xfrm6_local_rxpmtu() and xfrm6_local_error(); run kernel selftests for XFRM IPv6 PMTU handling and verify no crashes or KASAN reports under synthetic SYN-ACK rerouting scenarios.

Typical attack path

1. Obtain local shell or user context on a Linux host
2. Trigger or observe TCP connection setup that generates SYN-ACK skbs
3. Force selection of an IPv6 XFRM tunnel route with reduced MTU via routing manipulation
4. Invoke local PMTU or error handling paths that call xfrm6_local_rxpmtu or xfrm6_local_error
5. Read or corrupt kernel memory via the resulting out-of-bounds access

How to detect it

Search kernel logs for oops or KASAN reports referencing xfrm6_local_rxpmtu, xfrm6_local_error, or skb_to_full_sk; inspect network traces for IPv6 XFRM tunnel usage coinciding with TCP SYN-ACK retransmits; no public exploit artifacts exist.

What your security team should do

• Prioritize kernel updates on any system exposing IPv6 XFRM tunnels
• Restrict untrusted local user access until patches are applied
• Enable kernel hardening features such as KASAN or lockdown mode in test environments to validate fixes
• Review routing configurations that combine TCP and IPv6 XFRM to reduce trigger surface