CVE-2026-43139

What it actually does

This is a Linux kernel IPv6 XFRM/IPsec flaw caused by missing error handling in xfrm6_get_saddr(). When ipv6_dev_get_saddr() cannot select a usable IPv6 source address, it returns an error, but the caller previously treated the operation as successful and continued using an uninitialized IPv6 source-address value. That uninitialized value is then consumed during XFRM state lookup, which can lead to undefined kernel behavior, incorrect IPsec policy/state resolution, kernel memory exposure through uninitialized data use, or denial-of-service conditions such as warnings, instability, or crashes on affected systems using IPv6 and XFRM/IPsec paths.

Why it matters to the business

Affected Linux systems may become unstable or mishandle protected IPv6 traffic when specific XFRM/IPsec routing conditions occur. For organizations relying on Linux-based VPN gateways, IPsec tunnels, network appliances, containers, or hosts with IPv6 policy-based encryption, this can translate into service disruption, unreliable network connectivity, and potential exposure of small amounts of kernel memory or sensitive network-state information. The EPSS score is currently low and there is no known KEV listing or public exploit maturity, so this should be prioritized based on exposure of IPv6/XFRM/IPsec functionality rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker needs to cause an affected Linux kernel to enter the IPv6 XFRM route lookup path under conditions where the kernel attempts, and fails, to select an IPv6 source address. This is most relevant on systems with IPv6 enabled and XFRM/IPsec policies or tunnels configured. The attacker can trigger traffic that causes the target to perform an outbound IPv6 send or route lookup, such as by interacting with a service that replies over IPv6 or by influencing traffic through an IPsec-protected path. If ipv6_dev_get_saddr() cannot find a suitable source address, the vulnerable code incorrectly reports success and leaves the source-address field uninitialized. The kernel then uses that uninitialized address while searching for an XFRM state, creating a condition where uninitialized kernel memory influences lookup behavior. Depending on kernel configuration, compiler instrumentation, and runtime state, the result may be a visible KMSAN warning, failed or incorrect IPsec state resolution, network disruption, kernel instability, or limited information exposure.

How to fix it

Upgrade affected Linux kernel packages to a vendor-supported version that includes the xfrm6_get_saddr() fix, which checks the return value of ipv6_dev_get_saddr() and propagates the error instead of using an uninitialized address. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution or appliance vendor. Prioritize systems that use IPv6, IPsec, XFRM policies, VPN gateways, network namespaces, Kubernetes/container hosts with advanced networking, or Linux-based routers/firewalls. If immediate patching is not possible, reduce exposure by disabling unused IPv6, removing unnecessary XFRM/IPsec policies, limiting access to services that cause IPv6 replies through protected paths, and ensuring network interfaces have valid IPv6 source addresses where IPv6/IPsec is required. Mitigations should be treated as temporary because the defect is in kernel error handling.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version is at or above the distribution/vendor version containing the fix, not merely that the package is installed on disk. Reboot into the patched kernel where required and verify with standard platform commands such as uname -r and the vendor package manager. On systems that previously reproduced the issue, exercise IPv6 traffic through the relevant XFRM/IPsec policy path and confirm that kernel logs no longer show KMSAN uninitialized-value reports involving xfrm_state_find, xfrm6_get_saddr, xfrm_lookup_with_ifid, or xfrm_resolve_and_create_bundle. Validate that IPv6/IPsec tunnels and policies still function correctly after patching. For exposure validation, inventory systems with IPv6 enabled and active XFRM/IPsec configuration, including output from ip xfrm state, ip xfrm policy, and IPv6 address/routing configuration.

Typical attack path

1. Identify a Linux system reachable over the network or acting as a router, VPN endpoint, container host, or workload node with IPv6 and XFRM/IPsec functionality enabled.
2. Trigger or influence IPv6 traffic that causes the host to perform an outbound route lookup through the XFRM/IPsec code path.
3. Create conditions where IPv6 source address selection fails, for example through missing, deprecated, unsuitable, or policy-incompatible IPv6 addressing on the egress path.
4. The vulnerable kernel function treats the failed source-address lookup as successful and proceeds with an uninitialized IPv6 source address.
5. The uninitialized value is used during XFRM state lookup, potentially causing incorrect lookup behavior, kernel diagnostic warnings, denial of service, or limited information exposure.
6. The attacker repeats the trigger to increase the chance of service disruption or observable kernel-side failure.

How to detect it

There are no reliable network-only indicators that prove exploitation because the vulnerable behavior occurs inside the kernel during IPv6 XFRM/IPsec source-address selection and state lookup. Detection should focus on host telemetry. Review kernel logs from journald, dmesg, syslog, crash collectors, EDR kernel-event telemetry, and monitoring systems for uninitialized-value warnings or call traces containing xfrm_state_find, xfrm6_get_saddr, xfrm_resolve_and_create_bundle, xfrm_lookup_with_ifid, xfrm_lookup_route, udp_sendmsg, and ipv6_dev_get_saddr. KMSAN warnings are most likely on debug or instrumented kernels, so absence of these messages does not rule out triggering on production kernels. Correlate any such logs with spikes in IPv6 traffic, IPsec/XFRM tunnel failures, EADDRNOTAVAIL errors, service crashes, kernel oops/panic events, or unexplained loss of IPv6 VPN connectivity. On systems with active IPsec/XFRM use, review command history and configuration changes around IPv6 addressing, route policy, network namespaces, and XFRM state/policy manipulation to determine whether the trigger conditions were accidental misconfiguration or attacker-influenced traffic.

• BUG: KMSAN: uninit-value in xfrm_state_find
• xfrm_state_find+
• xfrm_resolve_and_create_bundle+
• xfrm_lookup_with_ifid+
• xfrm_lookup_route+
• xfrm6_get_saddr
• ipv6_dev_get_saddr
• xfrm_tmpl_resolve_one
• udp_sendmsg+
• ip_route_output_flow+
• __sys_sendto+
• EADDRNOTAVAIL
• KMSAN: uninit-value

What your security team should do

• Inventory Linux systems with IPv6 enabled and active XFRM/IPsec/IPsec VPN usage; prioritize those exposed to untrusted networks or providing network edge, VPN, routing, or container networking functions.
• Patch prioritized systems to vendor-fixed kernel builds and reboot into the patched kernel.
• Check kernel logs, SIEM telemetry, and crash/warning reports for KMSAN or kernel warnings involving xfrm_state_find and related XFRM IPv6 functions.
• Where patching is delayed, disable unused IPv6 or unused XFRM/IPsec policy paths and restrict untrusted access to services that generate outbound IPv6 responses.
• Validate that IPv6 interfaces used by IPsec/XFRM have correct and stable source-address configuration to reduce the chance of triggering the vulnerable path before remediation.
• Monitor vendor advisories for exact fixed package versions and backports because Linux distributions may fix this in different kernel release streams.