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:

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

bash

# 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