CVE-2026-63912

What it actually does

This is a Linux kernel memory-corruption vulnerability in the XFRM/IPsec ESP output path. When ESP out-of-place processing appends the ESP trailer before allocating the destination page fragment, the code could validate skb data length and trailer length separately instead of validating the combined aligned length. If that combined length exceeds a page, the destination scatter-gather mapping can span more memory than the single allocated page fragment can safely back, creating an out-of-bounds memory access condition in kernel context. Successful exploitation could cause kernel memory corruption, system crash, or potentially arbitrary code execution with kernel privileges, depending on kernel build, memory layout, and reachable traffic conditions.

Why it matters to the business

Systems acting as Linux IPsec/VPN gateways, routers, firewalls, hosts with XFRM ESP policies, or appliances built on affected Linux kernels may be exposed to remote traffic that can destabilize or compromise the kernel. The main operational risks are service outages, VPN or site-to-site connectivity disruption, host crashes, and in the worst case full system compromise. The CVSS score is critical, but the vulnerability is not currently listed in CISA KEV, is not marked as ransomware-used, has low EPSS at the time of reporting, and has no stated public exploit maturity; organizations should still prioritize remediation for internet-facing or untrusted-traffic-facing IPsec deployments because kernel memory corruption has high blast radius.

How an attack unfolds

An attacker first needs a path that causes crafted network traffic to be processed through a vulnerable Linux XFRM ESP outbound path, such as traffic entering a VPN gateway and being encapsulated into an IPsec ESP tunnel. The attacker sends traffic with sizes and alignment characteristics that cause ESP trailer handling to produce a combined post-trailer data length larger than one page while still passing the flawed separate length checks. The vulnerable kernel then takes the ESP out-of-place fast path and allocates a destination page fragment that is too small for the scatter-gather span implied by the combined skb data length. Subsequent ESP output processing can read or write outside the intended page-backed buffer, corrupting kernel memory. Observable outcomes may include a kernel oops, panic, packet-processing failure, VPN disruption, or, under favorable conditions for the attacker, controlled memory corruption leading to privilege escalation or remote code execution in kernel context.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix restoring the combined single-fragment length gate for both IPv4 and IPv6 ESP output paths. Because no affected product list or exact fixed package versions were provided, use distribution and vendor advisories to identify the patched kernel package for each platform, then reboot into the fixed kernel and remove or de-prioritize older vulnerable kernels. For systems that cannot be patched immediately, reduce exposure by limiting IPsec endpoints to trusted peers, blocking untrusted traffic from being forwarded into ESP tunnels, disabling unnecessary XFRM/IPsec ESP configurations, applying conservative MTU/MSS clamping for VPN paths where feasible, and monitoring for kernel instability. Mitigations should be treated as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated by checking kernel release and build metadata after reboot. Validate that vendor advisory status for the installed kernel includes the XFRM ESP combined-length gate fix for this vulnerability. On systems using IPsec, confirm XFRM state and policy are still functioning normally after the upgrade with representative IPv4 and IPv6 ESP traffic. Review booted kernel package versions, verify old kernels are not selected by default in the bootloader, and ensure live-patching status if used explicitly covers this XFRM ESP fix. Exposure can be assessed by checking whether the system has active XFRM policies or IPsec SAs and whether untrusted traffic can be encapsulated through those policies.

Typical attack path

1. Identify a Linux system or appliance using XFRM/IPsec ESP, especially a VPN gateway or host that encapsulates attacker-influenced traffic.
2. Send network traffic that will be forwarded or originated through the vulnerable ESP outbound processing path.
3. Shape packet size, fragmentation, and alignment so ESP trailer addition makes the combined aligned skb data length exceed a page.
4. Trigger the out-of-place ESP fast path where the vulnerable separate length checks allow processing to continue.
5. Cause the kernel to allocate an insufficient single page fragment while the destination scatter-gather mapping spans the larger combined length.
6. Leverage the resulting kernel memory corruption to crash the system, disrupt IPsec service, or attempt further exploitation for code execution.

How to detect it

There is no reliable network-only indicator that proves exploitation, and successful kernel memory corruption may leave only a crash or no durable artifact. Review kernel logs, system journals, crash dumps, kdump/vmcore data, IPsec daemon logs, VPN gateway telemetry, firewall logs, and NetFlow around any unexplained VPN disruption or host reboot. Focus on kernel oops, BUG, panic, slab corruption, page-fragment, skb, scatter-gather, ESP, or XFRM stack traces occurring during ESP traffic handling. Correlate crashes with bursts of large, fragmented, or boundary-sized packets entering traffic flows that are encapsulated into IPsec tunnels. For strong evidence, preserve vmcore files and analyze stack traces for functions in the ESP output path such as esp_output_head, esp_output_tail, esp4_output, esp6_output, skb_page_frag_refill, and XFRM output handling.

• esp_output_head
• esp_output_tail
• esp4_output
• esp6_output
• skb_page_frag_refill
• xfrm_output
• xfrm: esp
• BUG: kernel
• kernel BUG
• Oops:
• Kernel panic
• general protection fault
• BUG: unable to handle page fault
• skb_over_panic
• skb_under_panic
• corrupted page table
• slab-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• /var/crash/
• /var/lib/systemd/coredump/
• /proc/net/xfrm_stat
• ip xfrm state
• ip xfrm policy

What your security team should do

• Prioritize patching Linux IPsec/VPN gateways, perimeter routers, firewalls, and appliances that process untrusted traffic through XFRM ESP.
• Inventory systems with active XFRM policies or IPsec security associations, including containers or appliances that bundle their own kernels.
• Use vendor advisories to map the fix to exact distribution kernel packages and reboot systems into the patched kernel.
• If immediate patching is not possible, restrict IPsec peers and traffic sources, reduce exposure of VPN gateways, and consider disabling nonessential ESP tunnels until patched.
• Enable or verify kernel crash logging, kdump, and centralized collection of kernel logs for high-value VPN and network infrastructure.
• Search recent kernel logs and crash dumps for ESP, XFRM, skb, scatter-gather, or page-fragment related crashes that may indicate attempted triggering.
• Track exploit availability despite the current low EPSS and no known KEV status, because reliable exploitation of kernel network paths can change risk quickly.