CVE-2026-23398: Linux Kernel ICMP DoS Vulnerability

CVE-2026-23398 Overview

A NULL pointer dereference vulnerability has been identified in the Linux kernel's ICMP handling code within the icmp_tag_validation() function. The vulnerability occurs when the function unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. Since the inet_protos[] array is sparse (only approximately 15 of 256 protocol numbers have registered handlers), receiving an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number can trigger a kernel panic in softirq context.

Critical Impact

When ip_no_pmtu_disc is set to 3 (hardened PMTU mode), a remote attacker can send crafted ICMP packets to cause a kernel panic, resulting in complete denial of service of the affected Linux system.

Affected Products

• Linux kernel (versions with vulnerable icmp_tag_validation() implementation)
• Systems configured with ip_no_pmtu_disc=3 (hardened PMTU mode)
• Network-exposed Linux servers and infrastructure

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-23398 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-23398

Vulnerability Analysis

This vulnerability represents a Null Pointer Dereference condition in the Linux kernel's IPv4 ICMP error handling path. The root issue lies in the icmp_tag_validation() function, which is called during processing of ICMP error messages such as "Fragmentation Needed" (ICMP Type 3, Code 4).

The function retrieves a protocol handler using rcu_dereference(inet_protos[proto]) but fails to validate the result before attempting to access the icmp_strict_tag_validation field. When the kernel operates in hardened PMTU discovery mode (ip_no_pmtu_disc=3), it performs additional validation on received ICMP error messages.

An attacker can exploit this vulnerability remotely by crafting ICMP Fragmentation Needed packets that contain an inner IP header with an unregistered protocol number (any protocol not in the ~15 registered handlers). When the kernel processes such a packet, the NULL pointer dereference occurs in softirq context, causing a kernel panic and complete system denial of service.

Root Cause

The vulnerability stems from a missing NULL check in icmp_tag_validation() located in net/ipv4/icmp.c. The code assumes that every protocol number will have a registered handler in the inet_protos[] array, but this assumption is incorrect. The array is sparse by design, with only a small subset of the 256 possible protocol numbers having registered handlers. When ip_no_pmtu_disc=3 is enabled, the code path that accesses icmp_strict_tag_validation is triggered, and attempting to read this field from a NULL pointer results in a general protection fault.

Attack Vector

The attack vector is network-based and requires the ability to send ICMP packets to the target system. An attacker constructs an ICMP Fragmentation Needed message with a quoted inner IP header that specifies an unregistered protocol number. When this packet reaches a vulnerable system with ip_no_pmtu_disc=3 configured, the kernel attempts to validate the ICMP tags using a non-existent protocol handler, triggering the NULL pointer dereference.

The kernel crash trace shows the fault occurring at icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) in the interrupt context (<IRQ>), with the call chain flowing through icmp_rcv, ip_protocol_deliver_rcu, ip_local_deliver_finish, ip_local_deliver, ip_rcv, and ultimately handle_softirqs.

Detection Methods for CVE-2026-23398

Indicators of Compromise

• Unexpected kernel panics with "general protection fault" errors referencing icmp_unreach or icmp_tag_validation
• KASAN reports showing "null-ptr-deref in range [0x0000000000000010-0x0000000000000017]"
• System logs showing crashes in softirq context related to ICMP processing
• Unusual ICMP Fragmentation Needed packets with non-standard protocol numbers in the quoted inner header

Detection Strategies

• Monitor for kernel oops/panic events with RIP pointing to icmp_unreach in net/ipv4/icmp.c
• Deploy network intrusion detection rules to identify ICMP Type 3 Code 4 packets with unusual protocol values (outside commonly used protocols like TCP/6, UDP/17, ICMP/1)
• Enable kernel crash dump analysis to identify NULL pointer dereferences in ICMP handling paths
• Review system configurations for ip_no_pmtu_disc=3 setting to identify potentially vulnerable systems

Monitoring Recommendations

• Configure kdump/kexec for automated kernel crash collection on affected systems
• Implement network flow analysis to detect anomalous ICMP traffic patterns targeting infrastructure
• Set up alerting for unexpected system reboots or kernel panics on critical Linux systems
• Monitor syslog for kernel crash messages containing references to icmp.c or icmp_tag_validation

How to Mitigate CVE-2026-23398

Immediate Actions Required

• Apply the kernel patches from the stable kernel tree immediately
• If patching is not immediately possible, consider temporarily changing ip_no_pmtu_disc from 3 to a lower value
• Review firewall rules to limit exposure to potentially malicious ICMP traffic
• Prioritize patching for internet-facing Linux systems and critical infrastructure

Patch Information

The Linux kernel maintainers have released patches to address this vulnerability. The fix adds a NULL check before accessing icmp_strict_tag_validation, returning false for protocols without registered handlers since they cannot perform strict tag validation.

Patches are available through the following kernel commits:

• Linux Kernel Commit 1e4e2f5
• Linux Kernel Commit 1f9f2c6
• Linux Kernel Commit 614aefe
• Linux Kernel Commit 9647e99
• Linux Kernel Commit b61529c
• Linux Kernel Commit d938dd5

Workarounds

• Change the ip_no_pmtu_disc sysctl setting from 3 to a lower value (0, 1, or 2) to avoid the vulnerable code path
• Implement firewall rules to filter suspicious ICMP Fragmentation Needed packets at network boundaries
• Deploy rate limiting on ICMP traffic to reduce the impact of potential exploitation attempts
• Consider using iptables/nftables to drop ICMP Type 3 Code 4 packets from untrusted sources

# Configuration example
# Temporary workaround: Change ip_no_pmtu_disc setting
sysctl -w net.ipv4.ip_no_pmtu_disc=2

# Make persistent across reboots
echo "net.ipv4.ip_no_pmtu_disc = 2" >> /etc/sysctl.conf

# Optional: Rate limit ICMP at the firewall
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -m limit --limit 10/second -j ACCEPT
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j DROP