CVE-2026-43198

What it actually does

This is a race condition in the Linux kernel TCP/IPv6 connection setup path, specifically in tcp_v6_syn_recv_sock() handling of IPv4-mapped IPv6 child sockets. The child socket can become visible in the TCP established-hash table before its IPv6-related state is fully initialized, meaning another CPU may access the partially initialized socket while newinet->pinet6 still references listener state. In the worst case, that can lead to memory corruption, kernel crash, or other undefined kernel behavior reachable over the network during TCP connection establishment. The CVSS vector indicates unauthenticated, network-reachable exploitation with potential full confidentiality, integrity, and availability impact, although no public exploit maturity is reported and EPSS is currently low and flat.

Why it matters to the business

Systems running affected Linux kernel versions may be exposed to a remotely triggerable kernel flaw in the TCP stack. Operationally, the most likely visible outcome is service disruption or host instability if an attacker can trigger a crash or network-stack corruption. Because the flaw is in the kernel, successful exploitation could also threaten system integrity and confidentiality, depending on exploitability on a given kernel build and configuration. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low, stable EPSS score, but the high CVSS score and network attack surface make it important for internet-facing Linux servers, load balancers, container hosts, Kubernetes nodes, and infrastructure appliances that rely on the Linux kernel TCP/IP stack.

How an attack unfolds

An attacker targets a Linux system that accepts TCP connections over IPv6 or IPv4-mapped IPv6 paths. By rapidly initiating specially timed TCP connection attempts, the attacker attempts to win a race during child socket creation. The vulnerable sequence occurs after tcp_v4_syn_recv_sock() creates a child socket and makes it visible through the TCP ehash table, but before tcp_v6_syn_recv_sock() completes IPv6-specific initialization. If another CPU processes or looks up that socket during the window where newinet->pinet6 still points at listener IPv6 state, the kernel may operate on inconsistent socket state. A practical exploit would likely require high-volume or carefully timed connection attempts to increase the chance of triggering the race. Depending on kernel memory layout, hardening, and timing, the result may range from no visible effect, to kernel warning/oops, to denial of service, and potentially more severe kernel memory corruption effects.

How to fix it

Apply vendor-provided Linux kernel updates that include the upstream fix for the tcp_v6_syn_recv_sock() race. The fix moves the IPv6 child socket initialization into tcp_v6_mapped_child_init() and invokes it from tcp_v4_syn_recv_sock() before ehash insertion, preventing other CPUs from observing the child socket in the inconsistent state. No exact fixed package versions were provided in the input, so use distribution security advisories for the affected kernel branch and install the latest patched kernel available from the OS vendor. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting inbound TCP access to trusted sources, disabling or restricting unnecessary IPv6 services, reviewing use of IPv4-mapped IPv6 listeners, and applying network-layer rate limiting for untrusted connection floods. Mitigations should be treated as temporary because the vulnerability is in core kernel networking code.

How to confirm the fix worked

Confirm the system is running—not just has installed—a kernel build that includes the tcp_v6_syn_recv_sock()/tcp_v6_mapped_child_init() fix from the relevant distribution or upstream stable branch. Validate with commands such as uname -r, package manager kernel version checks, and vendor advisory mapping for the running kernel. For source-built kernels, verify the patch is present by checking that IPv6 mapped-child initialization occurs before TCP ehash insertion and that tcp_v6_mapped_child_init() or the equivalent fix is included. Confirm a reboot occurred after patch installation. Exposure validation should include inventorying Linux systems that accept inbound TCP connections, especially those listening on IPv6 addresses or dual-stack sockets. Where feasible in a staging environment, run regression tests for IPv6, IPv4, and IPv4-mapped IPv6 TCP services to confirm normal connection handling after upgrade.

Typical attack path

1. Identify Linux hosts or appliances exposing TCP services reachable over IPv6 or IPv4-mapped IPv6 listener configurations.
2. Send repeated TCP SYN connection attempts designed to exercise the IPv6/IPv4-mapped child socket creation path.
3. Increase concurrency and timing pressure so multiple CPUs can interact with newly created child sockets during the vulnerable initialization window.
4. Trigger the race where the child socket is visible in the TCP ehash table before its IPv6 socket state is fully corrected.
5. Cause kernel instability, crash, or potentially manipulate resulting memory corruption behavior if the target kernel and environment are exploitable.

How to detect it

Look for evidence of attempted race triggering and resulting kernel instability rather than a single definitive exploit signature. Relevant log sources include kernel logs, system journal, crash dumps, netconsole output, hypervisor console logs, network flow records, firewall logs, load balancer logs, and IDS/IPS telemetry. Search for kernel oops, panic, BUG, WARNING, general protection fault, KASAN, or lockdep messages around TCP, IPv6, inet6, tcp_v6_syn_recv_sock, tcp_v4_syn_recv_sock, tcp_v6_mapped_child_init, inet_ehash, or socket allocation paths. Correlate any kernel instability with bursts of inbound TCP SYNs, especially to IPv6 or dual-stack listeners, from one or many external sources. In forensic review, examine vmcore/kdump artifacts for stack traces involving TCP child socket creation or IPv6 socket state. Because this is a kernel race condition and no public exploit pattern is provided, network payload signatures are unlikely to be reliable; behavioral indicators such as connection floods followed by kernel faults are more useful.

• tcp_v6_syn_recv_sock
• tcp_v4_syn_recv_sock
• tcp_v6_mapped_child_init
• inet_ehash
• newinet->pinet6
• IPv6:
• TCP:
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• KASAN:
• WARNING: CPU
• BUG: kernel NULL pointer dereference
• RCU stall
• soft lockup
• hard lockup
• SYN flood
• Possible SYN flooding

What your security team should do

• Prioritize patching internet-facing Linux systems, network appliances, container hosts, Kubernetes nodes, and high-availability infrastructure that accept inbound TCP connections.
• Map affected assets by running kernel version and distribution advisory status; do not rely solely on package installation state because a reboot is required to activate a patched kernel.
• Review dual-stack and IPv6-exposed services, including sockets that may accept IPv4-mapped IPv6 connections, and reduce unnecessary exposure.
• Apply temporary network controls such as allowlisting, firewall restrictions, SYN rate limiting, and DDoS protections where patching must be delayed.
• Monitor for kernel crashes, oops/panic messages, TCP stack warnings, and abnormal bursts of TCP SYN traffic against IPv6 or dual-stack services.
• Because no KEV listing, ransomware linkage, or public exploit maturity is currently reported and EPSS is low and stable, treat this as high technical severity but prioritize based on internet exposure and service criticality rather than confirmed active exploitation.