CVE-2026-43099

What it actually does

CVE-2026-43099 is a remotely reachable Linux kernel denial-of-service flaw in IPv4 ICMP probe handling. When the kernel processes a specific ICMP probe path, icmp_build_probe() may call ipv6_stub->ipv6_dev_find() while the IPv6 stack is unavailable, such as when IPv6 is built as a loadable module and not loaded. In that condition, the lookup can return an error pointer, ERR_PTR(-EAFNOSUPPORT), which is then mishandled as if it were a valid network device pointer and passed into dev_hold(). The result is a kernel null-pointer dereference or invalid pointer dereference leading to a kernel crash/panic. The impact is availability-only: it does not directly provide code execution, privilege escalation, or data disclosure, but it can allow unauthenticated network-triggered crashes on affected configurations.

Why it matters to the business

Successful exploitation can crash vulnerable Linux systems, causing service interruption, node reboot, application downtime, failed connections, and potential cascading availability issues in clustered or load-balanced environments. The CVSS score of 7.5 reflects high availability impact and low attack complexity, but the current EPSS score is low at 0.0049 and has been flat over 30 days, there is no known CISA KEV listing, no ransomware association, and no reported public exploit maturity in the provided data. Organizations should still prioritize remediation for internet-facing, high-availability, or packet-processing Linux systems because the flaw is network-reachable and requires no authentication.

How an attack unfolds

An attacker identifies a Linux host that is reachable over the network and running an affected kernel configuration where IPv6 support is compiled as a module but the IPv6 stack is not active. The attacker sends specially crafted ICMP traffic that causes the kernel to enter the ICMP probe response-building path in icmp_build_probe(). During processing, the kernel attempts to resolve an IPv6-related interface identifier through ipv6_stub->ipv6_dev_find(). Because IPv6 is unavailable at runtime, the lookup returns an error pointer rather than a valid network device. The vulnerable kernel path fails to properly reject that error pointer and passes it to dev_hold(), triggering a kernel fault. The system may panic, reboot, or become unavailable, resulting in denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for icmp_build_probe() error-pointer handling. Because no fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution, vendor, cloud image provider, appliance vendor, or long-term stable kernel branch once available. Prioritize systems that are network-facing or have strict uptime requirements. If immediate patching is not possible, reduce exposure by filtering unnecessary ICMP traffic at network boundaries, limiting inbound ICMP probe traffic to trusted sources where operationally feasible, and ensuring high-availability services can tolerate node loss. As a configuration-oriented mitigation, organizations should evaluate whether IPv6 should be consistently enabled and loaded or explicitly disabled according to vendor guidance; avoid unsupported partial configurations where IPv6 is built as a module but unavailable at runtime if affected kernel behavior remains present.

How to confirm the fix worked

Confirm remediation by verifying that each system is running a vendor kernel build that includes the fix for the Linux kernel IPv4 ICMP icmp_build_probe() null-pointer dereference. Check the active kernel version with standard platform tooling such as uname -r and compare it against the vendor security advisory or changelog for this issue. Review distribution package metadata to confirm the installed kernel package contains the patch. Validate that any temporary network controls for ICMP filtering are applied at host firewalls, perimeter firewalls, cloud security groups, or network ACLs as intended. For exposure assessment, identify systems with IPv6 built as a module and not loaded, and verify whether they run affected kernel versions. In controlled test environments only, defensive teams may use safe packet-generation testing to confirm that malformed or edge-case ICMP probe traffic no longer causes kernel warnings, oopses, panics, or reboots.

Typical attack path

1. Discover Linux systems exposed to network traffic, especially internet-facing servers, appliances, routers, VPN endpoints, container hosts, or load balancers.
2. Send ICMP traffic crafted to exercise the ICMP probe response path associated with RFC 8335-style probe handling.
3. Trigger icmp_build_probe() on a system where IPv6 is not active despite relevant IPv6 lookup hooks being present.
4. Cause ipv6_stub->ipv6_dev_find() to return ERR_PTR(-EAFNOSUPPORT).
5. Exploit the kernel’s failure to reject the error pointer before dev_hold() is called.
6. Crash or panic the kernel, causing service disruption or reboot.

How to detect it

Look for evidence of unexplained Linux kernel crashes, oops messages, panics, or reboots around periods of unusual ICMP traffic. Useful log sources include kernel logs from journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, netconsole, crash dump infrastructure such as kdump/vmcore, hypervisor reset events, cloud instance system logs, firewall logs, IDS/NSM telemetry, and packet captures. Correlate host crashes with inbound ICMP traffic from the same source addresses or bursts of ICMP probe-like packets shortly before the crash. On affected systems, kernel logs may reference icmp_build_probe, ipv6_dev_find, dev_hold, null pointer dereference, general protection fault, BUG, Oops, panic, or EAFNOSUPPORT-related IPv6 lookup failures. Because exploitation causes a crash rather than reliable post-exploitation activity, persistent file, process, registry, or account artifacts are not expected. Absence of logs is not conclusive because a sudden kernel panic may prevent local log flushing; use remote logging, netflow, firewall telemetry, and crash dumps where available.

• icmp_build_probe
• ipv6_dev_find
• dev_hold
• NULL pointer dereference
• null-ptr-deref
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• general protection fault
• ERR_PTR(-EAFNOSUPPORT)
• EAFNOSUPPORT
• ipv6_stub
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash/
• vmcore
• kdump

What your security team should do

• Inventory Linux systems running affected kernel versions, prioritizing internet-facing and high-availability assets.
• Track the relevant Linux distribution, appliance, and cloud image advisories and deploy kernel updates containing the icmp_build_probe() fix as soon as available.
• Prioritize patching despite low EPSS where systems are exposed to untrusted network traffic, because exploitation requires no authentication and can cause a full kernel crash.
• Apply temporary ICMP filtering or rate limiting at network boundaries where operationally acceptable, especially for unnecessary inbound ICMP probe traffic.
• Review kernel crash, reboot, and network logs for unexplained crashes associated with ICMP traffic before patching.
• Ensure monitoring alerts on kernel oops, panic, unexpected reboot, and repeated host availability loss are routed to the SOC or infrastructure operations teams.
• Validate IPv6 configuration consistency across Linux fleets and avoid unsupported or unintended partial IPv6 runtime states.
• After patching, reboot systems into the fixed kernel and verify the active running kernel, not only the installed package version.