CVE-2026-43036

What it actually does

CVE-2026-43036 is a Linux kernel networking flaw in the TCPv4 Generic Segmentation Offload feature-check path. The vulnerable code reads the IPv4 frag_off field through direct header access in gso_features_check(), but packets injected through PF_PACKET paths can have header layout or linearization conditions where that direct dereference is unsafe. This can lead to use of uninitialized or invalid packet-header data during transmit feature evaluation. The resolved behavior uses skb_header_pointer() so the kernel safely reads the header whether the data is already linear or must be copied. The primary impact is local availability degradation, potentially including kernel warnings, networking instability, or a kernel crash depending on build configuration, memory-sanitizer behavior, and runtime conditions.

Why it matters to the business

A local user or compromised low-privilege workload with the ability to inject crafted packets through Linux packet-socket paths may be able to disrupt a system’s networking stack or cause host instability. For servers running multi-user workloads, containers, packet capture/traffic generation tools, or untrusted local code, the operational risk is service interruption rather than data theft. The issue is not listed in CISA KEV, has very low EPSS, no known mature exploit, and no reported ransomware use, so remediation should be prioritized as part of normal kernel maintenance unless the environment exposes PF_PACKET or CAP_NET_RAW capabilities to untrusted users or containers.

How an attack unfolds

An attacker first needs local execution on an affected Linux system and sufficient permission to create or use packet-socket based traffic injection, commonly through PF_PACKET or capabilities such as CAP_NET_RAW. The attacker then crafts network packets whose skb header offsets and linearization state cause the kernel’s TCPv4 GSO feature-check logic to evaluate the IPv4 fragmentation field through an unsafe direct header read. When the packet traverses netif_skb_features() and gso_features_check(), the vulnerable kernel may read uninitialized or otherwise unsafe header data. In practical terms, this is expected to manifest as kernel sanitizer warnings, networking instability, or a denial-of-service condition rather than code execution. There is currently no public evidence of active exploitation, named threat actor use, or ransomware adoption.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix changing the TCPv4 GSO frag_off check to use skb_header_pointer(). Because no exact fixed package versions were provided, use the fixed kernel packages supplied by the operating system or distribution vendor once available, or backport the upstream patch for maintained custom kernels. Where immediate patching is not possible, reduce exposure by limiting local raw-packet capabilities: restrict CAP_NET_RAW, avoid granting privileged or host-network containers unnecessary packet-socket access, disable or constrain untrusted packet generation tools, and apply least-privilege controls for local users. Kernel hardening and rapid reboot/failover procedures can reduce operational impact but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm exposure by identifying affected Linux kernel versions and checking whether the vendor kernel changelog or source tree contains the fix for the TCPv4 GSO frag_off read using skb_header_pointer(). Validate remediation by installing the patched kernel, rebooting into it, and confirming the running kernel with uname -r and package-manager metadata. For custom kernels, inspect the relevant networking source to verify that the TCPv4 GSO frag_off check no longer directly dereferences ip_hdr() or inner_ip_hdr() for this path and instead uses skb_header_pointer(). If feasible in a test environment, run regression traffic tests involving PF_PACKET injection and GSO-enabled TCP/IPv4 traffic while monitoring dmesg or journal logs for KMSAN, KASAN, kernel WARN, BUG, or panic output related to gso_features_check() or netif_skb_features().

Typical attack path

1. Gain local code execution on an affected Linux system.
2. Obtain or abuse permission to inject crafted packets through PF_PACKET or equivalent raw-packet mechanisms.
3. Construct TCP/IPv4 packet data with header layout conditions that make direct skb header dereference unsafe during GSO feature checks.
4. Send the crafted packet so it enters the transmit feature evaluation path.
5. Trigger gso_features_check() through netif_skb_features(), causing an unsafe read of the IPv4 frag_off field.
6. Cause kernel warnings, networking disruption, or a host availability impact depending on kernel configuration and runtime conditions.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel and system logs rather than network perimeter logs, because exploitation requires local packet injection and the visible impact is inside the kernel networking stack. Useful sources include dmesg, journald/kern.log/messages, auditd logs for raw socket or capability use, container runtime logs, EDR process telemetry, and crash dump systems such as kdump, apport, ABRT, or systemd-coredump metadata. Search for kernel warnings, panics, KMSAN reports, or call traces involving gso_features_check(), netif_skb_features(), PF_PACKET, TCPv4 GSO, IPv4 frag_off, or skb header access. Correlate these events with local processes that recently opened AF_PACKET/PF_PACKET sockets, used CAP_NET_RAW, ran packet crafting tools, or executed inside privileged or host-network containers. Because no public exploit-specific payload or stable network signature is known, detection should focus on anomalous local raw-packet activity followed by kernel networking faults or sanitizer messages.

• KMSAN: uninit-value in gso_features_check
• gso_features_check
• netif_skb_features
• PF_PACKET
• AF_PACKET
• CAP_NET_RAW
• frag_off
• skb_header_pointer
• ip_hdr
• inner_ip_hdr
• BUG: kernel NULL pointer dereference
• kernel panic
• WARNING: CPU:
• Call Trace:
• packet socket
• socket(AF_PACKET
• socket(PF_PACKET

What your security team should do

• Inventory Linux systems and prioritize patching for hosts where untrusted local users, containers, CI jobs, traffic generators, packet capture tools, or network test utilities can use PF_PACKET or CAP_NET_RAW.
• Apply vendor kernel updates that include the fix, then reboot systems to ensure the patched kernel is running.
• Restrict CAP_NET_RAW and raw packet socket access for non-administrative users and containers, especially on shared compute and container platforms.
• Review container runtime, Kubernetes, and workload policies for privileged containers, hostNetwork usage, and added Linux capabilities that permit raw packet injection.
• Monitor kernel logs for warnings, BUG messages, panics, or sanitizer reports referencing gso_features_check(), netif_skb_features(), skb header access, or uninitialized values.
• Treat repeated local kernel networking crashes or sanitizer findings as potential exploitation attempts and preserve kernel logs, audit records, and workload execution history for investigation.
• Track distribution advisories because exact fixed package versions may vary by vendor and maintained kernel branch.