CVE-2026-68127

What it actually does

This is a Linux kernel use-after-free in the IPv6 Identifier Locator Addressing (ILA) code path. When an IPv6 packet traverses a configured ILA route or receive-side mapping that uses transport checksum adjustment, the kernel may cache a pointer to the IPv6 header, call skb pull/expansion logic that can reallocate or free the original skb head, and then continue reading from or writing through the stale pointer. A remote IPv6 packet can therefore trigger a slab use-after-free in kernel context. The vulnerable path requires ILA configuration by a privileged local administrator or management plane with CAP_NET_ADMIN, but once such a route or mapping exists, trigger traffic does not require authentication.

Why it matters to the business

Systems using Linux IPv6 ILA with checksum-adjusting routes or mappings may be exposed to remote kernel memory corruption from network traffic. The most likely operational consequence is a kernel crash or service disruption on routers, gateways, hosts, containers, or network appliances that rely on this feature. Because the flaw is newly published, not listed in CISA KEV, not known to be used in ransomware, and has no reported exploit maturity in the provided data, broad opportunistic exploitation is not currently indicated; however, affected internet- or network-facing IPv6 routing infrastructure should still be prioritized because kernel memory corruption bugs can have high availability impact and may become more severe if weaponized.

How an attack unfolds

An attacker first needs a target where Linux ILA is configured for IPv6 locator translation using the transport checksum adjustment mode. The attacker does not need to configure ILA themselves; that setup only needs to already exist through legitimate administration, orchestration, or a network function. The attacker then sends crafted or suitably structured IPv6 traffic through the affected ILA route or receive-side mapping, especially traffic that causes the socket buffer to be non-linear so the transport header resides outside the linear skb head. During packet processing, the kernel enters the ILA checksum-adjustment path, stores a pointer to the IPv6 header, and calls pskb_may_pull(). If that call expands or replaces the skb head, the saved IPv6-header pointer can refer to freed slab memory. The kernel subsequently calculates checksum differences and updates the IPv6 destination locator using that stale pointer, causing a slab use-after-free. In practice, exploitation is expected to present first as kernel warnings, KASAN reports, packet-processing instability, or a crash; reliable code execution is not established from the provided information.

How to fix it

Apply a Linux kernel update that includes the fix for the ILA IPv6 header reload issue in ila_csum_adjust_transport() and ila_update_ipv6_locator(). No exact fixed package versions were provided, so use the corrected kernel packages from the operating system, appliance, container host, or kernel vendor once available. Where immediate patching is not possible, reduce exposure by disabling or removing ILA routes and receive-side mappings that use checksum-adjust-transport, limiting IPv6 traffic that can reach ILA-processing interfaces, and restricting CAP_NET_ADMIN to only trusted administrative components. If ILA is not required, disable the feature or remove the related configuration entirely. Because the vulnerable condition depends on a specific configured ILA path, asset owners should prioritize systems acting as IPv6 routers, gateways, network appliances, Kubernetes/container hosts with advanced networking, and hosts where privileged orchestration can create ILA mappings.

How to confirm the fix worked

Confirm the running kernel is at or above the vendor-fixed build that contains the ILA pointer reload changes. Validate that the patched source or package includes logic that reloads ipv6_hdr(skb) after pskb_may_pull() in the ILA checksum-adjustment path and reloads the IPv6 header/address before destination-address updates in the affected case. Check for active exposure by reviewing ILA configuration with Linux networking tools and confirming whether checksum-adjusting ILA routes or mappings exist. After patching or mitigation, verify that no vulnerable ILA checksum-adjust-transport mappings remain unless the kernel is fixed, then exercise representative IPv6 traffic through the path while monitoring dmesg, journal logs, KASAN output, and kernel oops reports for use-after-free messages involving ILA functions.

Typical attack path

1. Identify or reach a Linux system processing IPv6 traffic through configured ILA routes or receive-side mappings.
2. Confirm, infer, or brute-force traffic patterns that traverse an ILA checksum-adjust-transport path.
3. Send IPv6 packets that are routed through the affected ILA path and can produce non-linear skb handling with the transport header in a page fragment.
4. Trigger pskb_may_pull() so the skb head may be reallocated or freed while the ILA code still holds a cached IPv6-header pointer.
5. Cause the kernel to read from and later write through the stale pointer during checksum adjustment and locator update.
6. Observe service interruption, kernel error logs, packet forwarding disruption, or host crash as the likely exploitation outcome.

How to detect it

To determine whether this was already exploited or triggered, examine kernel and system logs from Linux hosts that have ILA enabled or that route IPv6 traffic. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, appliance support bundles, and SIEM-ingested kernel logs. Look for KASAN, kernel oops, panic, BUG, general protection fault, page fault, or slab-use-after-free reports with stack frames or symbols related to ila_update_ipv6_locator, ila_csum_adjust_transport, pskb_may_pull, __pskb_pull_tail, pskb_expand_head, or get_csum_diff. Correlate such events with IPv6 traffic traversing ILA routes, unexpected host reboots, forwarding outages, and bursts of external or untrusted IPv6 packets. Also review administrative logs for recent changes to ILA routes or mappings, because the vulnerable path must be configured before unauthenticated packets can trigger it. Absence of these logs is not proof of non-exploitation, particularly on production kernels without KASAN or persistent crash logging.

• slab-use-after-free
• KASAN: slab-use-after-free
• BUG: KASAN
• ila_update_ipv6_locator
• ila_csum_adjust_transport
• pskb_may_pull
• __pskb_pull_tail
• pskb_expand_head
• get_csum_diff
• ila: reload IPv6 header
• BUG: unable to handle page fault
• general protection fault
• kernel BUG
• Kernel panic
• Oops:
• ila_xlat
• ILA_CSUM_ADJUST_TRANSPORT

What your security team should do

• Inventory Linux systems that process IPv6 routing, tunneling, locator translation, or network-function workloads and determine whether ILA is enabled or configured.
• Prioritize patching any system with active ILA checksum-adjust-transport routes or receive-side mappings, especially network-facing routers, gateways, appliances, and container hosts.
• If patching is delayed, remove or disable ILA checksum-adjust-transport configurations where operationally feasible.
• Restrict CAP_NET_ADMIN and privileged container/network orchestration permissions to prevent unauthorized creation of vulnerable ILA mappings.
• Monitor kernel logs for crashes, KASAN reports, slab use-after-free messages, and stack traces mentioning ILA functions.
• Review recent IPv6 traffic spikes or malformed packet activity against systems with ILA enabled, especially shortly before kernel instability or reboots.
• Track vendor advisories for exact fixed kernel versions because no per-package fixed versions were provided in the input.