KernelScan.io

HIGH

ipv6 LwtunnelXmit UAF

CVE-2026-80792

CVSS 7.8 / 10.0 KernelScan AI

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

01

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.

02

Engine v0.6.0

Risk summary

A use-after-free read in the IPv6 output path allows a local attacker to leak kernel memory, corrupt the neighbour table, misdirect network traffic, or crash the system. The bug is reachable by any local process that can send IPv6 traffic through a route configured with a lightweight tunnel (lwtunnel) encap, which an unprivileged user can set up inside a user network namespace. Products with IPv6 enabled and unprivileged user-namespace access are most exposed.

Affectednet/ipv6/ip6_output.c (ipv6 output path)

Vulnerability analysis

When the IPv6 output path sends a packet through a lightweight tunnel, it caches a pointer to the destination address in the IPv6 header before calling the tunnel transmit function. The tunnel transmit path (LWT-BPF or other encapsulation) can reallocate the packet buffer to add encapsulation headers, freeing the memory the cached pointer references. After the tunnel function signals that the packet should continue through normal output processing, the code still uses the stale pointer to compute the next hop and look up the neighbour entry, resulting in a use-after-free read. The fix re-reads the IPv6 header pointer from the potentially reallocated packet after the tunnel transmit function returns, so all subsequent next-hop and neighbour operations reference valid memory. An unprivileged local user can trigger this by creating a user network namespace where they hold CAP_NET_ADMIN, configuring a lightweight tunnel route, and sending IPv6 traffic through it; the stale read can disclose kernel data, corrupt the neighbour cache, or panic the kernel.

03

BranchIntroducedFixed inPatch commit
5.105.10.2335.10.26775e0a544ebe9
5.15—5.15.218d960881b9312
5.45.4.2895.5c95f01b78266
6.1—6.1.185087ee0d914aa
6.12—6.12.1063dc98e5fe82d
6.18—6.18.4799219c82804f
6.6—6.6.1543c770ac4e6f0
7.1—7.1.1173a187384a8c
7.2—7.2.1d0d48d999b0e
mainline—7.3—
cip/5.10—5.10.268-cip7775e0a544ebe9
cip/5.10-rt—5.10.268-cip77-rt3475e0a544ebe9
cip/6.1—6.1.187-cip60d960881b9312
cip/6.1-rt—6.1.189-cip61-rt32d960881b9312
cip/6.12—6.12.108-cip313c770ac4e6f0

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.108-cip31
cip/6.1Fixed in 6.1.187-cip60
cip/6.1-rtFixed in 6.1.189-cip61-rt32
cip/5.10Fixed in 5.10.268-cip77
cip/5.10-rtFixed in 5.10.268-cip77-rt34