CVE-2026-80792
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A flaw in how Linux handles certain IPv6 network forwarding operations can let attackers crash machines or steal internal system information.
- Exploitation
- Other
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free read in ip6_finish_output2() where a cached daddr pointer becomes invalid after lwtunnel_xmit() reallocates the skb head on LWTUNNEL_XMIT_CONTINUE return, allowing subsequent nexthop computation and neighbor lookup on freed memory.
Why it matters to the business
Linux systems processing IPv6 traffic through lightweight tunnels or BPF encapsulation may experience crashes, kernel memory disclosure, corrupted neighbor tables, or traffic redirection that disrupts network operations.
How an attack unfolds
An attacker sends specially crafted IPv6 packets that invoke the LWT-BPF transmit path or other encapsulation within lwtunnel_xmit(), triggering skb head reallocation; on return the stale daddr is dereferenced for neighbor operations, enabling data leaks or table poisoning.
How to fix it
Apply the upstream kernel patch that re-fetches the IPv6 header and destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE; rebuild and deploy the updated kernel across all affected systems.
How to confirm the fix worked
Inspect the patched ip6_finish_output2() source to confirm the header re-fetch after LWTUNNEL_XMIT_CONTINUE; test with IPv6 packets that exercise LWT-BPF paths and verify absence of use-after-free reports in kernel logs or KASAN output.
Typical attack path
- Send IPv6 packets that match LWT tunnel or BPF encapsulation rules
- Force skb head reallocation inside lwtunnel_xmit()
- Return LWTUNNEL_XMIT_CONTINUE to resume ip6_finish_output2()
- Dereference freed daddr for nexthop and neighbor lookup
How to detect it
Examine kernel crash dumps and dmesg for references to ip6_finish_output2 or neighbor table operations; correlate with IPv6 traffic logs showing LWT or encapsulation activity; watch for anomalous neighbor table growth or entries containing invalid data.
What your security team should do
- Prioritize kernel updates on all IPv6-enabled systems that use lightweight tunnels or BPF encapsulation
- Review and minimize use of LWT-BPF configurations where feasible until patched
- Monitor kernel update channels for the specific fix commit
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|