CVE-2026-46037

What it actually does

This flaw is an out-of-bounds access in the Linux kernel IPv4 ICMP reply path. When handling ICMP extended echo behavior, the kernel can use ICMP_EXT_ECHOREPLY as a reply type and incorrectly consult the icmp_pointers[] table, which is only valid for traditional ICMP types. A remote, unauthenticated sender can potentially trigger invalid kernel memory access through crafted IPv4 ICMP traffic. The most likely impact is kernel instability, crash, or denial of service; the CVSS vector also indicates a possible low-confidence information disclosure impact.

Why it matters to the business

An exposed Linux system could be remotely crashed or destabilized by malicious ICMP traffic, causing service interruptions, node reboots, workload disruption, or degraded network reliability. Internet-facing servers, network appliances, container hosts, and systems that allow inbound ICMP are the highest-priority assets. Although this issue is not currently listed in CISA KEV and has low EPSS at the time of assessment, it is network-reachable, requires no authentication, and affects the kernel, so remediation should be prioritized for exposed and mission-critical Linux systems.

How an attack unfolds

An attacker identifies Linux systems reachable over IPv4 and able to receive ICMP traffic. The attacker sends crafted ICMP extended echo-related packets that cause the vulnerable kernel to prepare an extended echo reply. During reply processing, the kernel uses the extended echo reply type as an index into the icmp_pointers[] array even though that type is outside the valid table range. This can result in an out-of-bounds memory access in kernel context. Depending on memory layout and kernel configuration, exploitation may manifest as a kernel oops, panic, reboot, soft lockup, networking failure, or limited exposure of adjacent kernel memory. Reliable exploitation for code execution is not indicated by the available data; the primary realistic attack outcome is remote denial of service.

How to fix it

Upgrade affected Linux kernel packages to a vendor-supported release that includes the upstream fix for validating ICMP reply types before indexing icmp_pointers[] and applying array_index_nospec() to in-range lookups. Because no universal fixed version is provided, use the fixed kernel version published by the relevant Linux distribution or appliance vendor. After installing the updated kernel, reboot systems so the patched kernel is running. As interim mitigation, restrict inbound IPv4 ICMP from untrusted networks where operationally feasible, especially ICMP extended echo traffic, and apply network-layer filtering or rate limiting at firewalls, routers, host firewalls, or DDoS controls. Avoid fully blocking ICMP without testing, because some ICMP types are important for diagnostics and path MTU discovery.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated to a vendor release containing the ICMP fix. Validate with distribution package metadata, vendor advisories, kernel changelogs, or source patches referencing validation of ICMP reply type before icmp_pointers[] access. Reboot and verify the active kernel version with standard OS tooling. Confirm that perimeter and host firewall policy limits untrusted ICMP exposure where mitigation is required. If using vulnerability scanners, ensure the scanner checks the running kernel version and distribution backport status rather than relying solely on upstream version numbers. In controlled testing only, send benign ICMP extended echo traffic and verify the host remains stable and logs no kernel oops, panic, or ICMP processing errors.

Typical attack path

1. Scan or select IPv4-reachable Linux hosts that accept inbound ICMP traffic.
2. Send crafted ICMP extended echo request traffic, associated with ICMP type 42 / type 43 handling.
3. Trigger the vulnerable kernel ICMP reply path to generate an extended echo reply.
4. Cause the kernel to index icmp_pointers[] with an out-of-range reply type.
5. Induce kernel memory access errors, crash, panic, reboot, or service disruption.
6. Repeat traffic to maintain denial of service if the system automatically recovers.

How to detect it

To determine whether this was already exploited, correlate network telemetry with host stability events. Review firewall, router, IDS/IPS, packet broker, NetFlow, and PCAP data for unusual inbound IPv4 ICMP extended echo traffic, particularly ICMP type 42 and type 43, from external or unexpected sources. On hosts, review kernel logs, system journals, crash dumps, kdump output, console logs, and reboot records for kernel oops, panic, NULL pointer dereference, general protection fault, soft lockup, or watchdog events occurring shortly after ICMP traffic. Look for repeated crashes or reboots with no application-level cause. IDS signatures should focus on unexpected or high-rate ICMP Extended Echo Request/Reply packets and traffic that precedes Linux kernel crash telemetry. Because no public exploit artifacts or malware-specific indicators are provided, detection should emphasize behavioral correlation rather than file-based indicators.

• ICMP type 42
• ICMP type 43
• Extended Echo Request
• Extended Echo Reply
• ICMP_EXT_ECHOREPLY
• icmp_pointers
• kernel NULL pointer dereference
• general protection fault
• Kernel panic
• Oops:
• soft lockup
• watchdog: BUG
• RIP: icmp
• icmp_reply

What your security team should do

• Inventory Linux systems that are IPv4-reachable from untrusted networks and prioritize kernel updates for internet-facing servers, network appliances, virtualization hosts, Kubernetes nodes, and critical infrastructure systems.
• Apply vendor kernel updates that include the ICMP reply-type validation fix, then reboot to activate the patched kernel.
• Where immediate patching is not possible, restrict or rate-limit inbound ICMP from untrusted networks, with particular attention to ICMP extended echo request/reply traffic.
• Monitor kernel logs and centralized logging for crashes, oops messages, panics, reboots, or ICMP-related faults after unusual ICMP traffic.
• Add network detection for spikes in ICMP extended echo request or reply packets, especially ICMP type 42 and type 43 from external sources.
• Review uptime and reboot telemetry for unexplained Linux restarts that coincide with ICMP traffic bursts.
• Track vendor advisories for exact fixed package versions and backported patches, since fixed versions vary by distribution.