CVE-2026-80901

What it actually does

Linux kernel IPVS fails to correctly validate checksums on some ICMP/ICMPv6 (and related TCP/UDP) paths. Incoming client ICMPv6 may be accepted without checksum checks, and IPv6 ICMP from real servers may skip the IPv6 pseudo-header when checksums are not offloaded. Packets that should be dropped can be processed, mangled (MASQ/NAT or tunnel reply), or used to influence IPVS connection handling. This is improper input validation, not memory corruption or privilege escalation by itself.

Why it matters to the business

Hosts using Linux IP Virtual Server / LVS for load balancing may see disrupted or misdirected sessions, especially around ICMP error handling (unreachable, too-big/PMTU, and similar). Availability of virtual services can be affected; confidentiality and integrity impact is limited unless combined with other weaknesses. The issue is not listed in CISA KEV, is not associated with ransomware campaigns, has no reported exploit maturity, and is about 25 days old—treat as a standard kernel patch, with higher priority where IPVS/IPv6 is in the production data path.

How an attack unfolds

An attacker who can send packets toward an IPVS director (or, in some topologies, toward real servers whose ICMP is handled by IPVS) crafts ICMP or ICMPv6 messages with invalid or inconsistent checksums. Because ip_vs_in_icmp_v6() did not validate client ICMPv6 checksums, and handle_response_icmp() could omit the IPv6 pseudo-header, those packets may be accepted instead of discarded. Accepted ICMP errors can then be applied to load-balanced flows (for example tearing down or shrinking connections) or can be mangled on NAT/tunnel paths with incorrect checksum state. LOCAL_OUT and FORWARD traffic was not the intended validation point; LOCAL_IN is where missing nf_checksum() coverage matters. There are no named threat actors or public exploit kits associated with this CVE.

How to fix it

Apply a Linux kernel update that includes the IPVS checksum-validation fix (ip_vs_checksum_common_check / consistent nf_checksum() use for TCP, UDP, and ICMP on IPv4 and IPv6, plus correct IP offset for debug packet dumps). Use your distribution or vendor kernel package; no per-package fixed versions were supplied with this record, so take the vendor advisory’s kernel version as authoritative. Prioritize directors and appliances with CONFIG_IP_VS and IPv6 virtual services. If you cannot patch immediately, restrict who can send ICMP/ICMPv6 to virtual IPs (edge ACLs, anti-spoofing, ICMP rate limits) and avoid exposing IPVS directors to untrusted networks. Do not disable IPVS checksum offload as a substitute for the patch.

How to confirm the fix worked

Confirm the running kernel changelog or stable commit contains the IPVS checksum validation fix, then reboot into that kernel. Verify IPVS is still healthy (ipvsadm/n, virtual services and real servers, IPv4 and IPv6). After patching, invalid-checksum ICMP/ICMPv6 should no longer be consumed on LOCAL_IN when nf_checksum() was not already applied on PRE_ROUTING. Inventory exposure by finding nodes with IPVS loaded (lsmod/ip_vs*, CONFIG_IP_VS, keepalived/lvs/kube-proxy IPVS mode) rather than scanning for a version string alone.

Typical attack path

1. Discover Linux hosts or appliances performing IPVS/LVS load balancing, especially with IPv6 or mixed IPv4/IPv6 virtual services.
2. Send crafted ICMP or ICMPv6 error or related packets toward the virtual service or director so they hit IPVS LOCAL_IN handling.
3. Rely on missing or incomplete checksum (and IPv6 pseudo-header) validation so the kernel processes packets that hardware or PRE_ROUTING did not already drop.
4. Cause IPVS to apply those messages to existing connections or to mangle/NAT/tunnel them incorrectly.
5. Observe connection resets, blackholing, PMTU/MSS disruption, or unbalanced/failed forwarding as the operational result.

How to detect it

This bug leaves no unique implant; look for pre-patch evidence that IPVS accepted ICMP that should have failed checksum checks. Review kernel and netfilter logs on directors around connection resets, PMTU changes, and ICMP errors aimed at virtual IPs. Correlate conntrack/IPVS connection drops with inbound ICMP/ICMPv6 (types such as destination unreachable and packet too big) from unexpected sources. Packet captures on LOCAL_IN to the director showing ICMP/ICMPv6 with invalid checksums that still affected virtual services are the strongest artifact. There is no associated APT or campaign telemetry. Post-patch, the same traffic should be dropped before IPVS connection logic.

• ip_vs
• ip_vs_ipv6
• nf_conntrack ICMP related to virtual service drops
• ICMPv6 type 1 (Destination Unreachable) to VIP
• ICMPv6 type 2 (Packet Too Big) to VIP
• ICMP type 3 to VIP with invalid L4 checksum
• kernel: IPVS
• keepalived.*ipvs
• kube-proxy ipvs

What your security team should do

• Inventory Linux load balancers, HA directors, and Kubernetes/kube-proxy IPVS-mode nodes and schedule the vendor kernel update.
• Patch and reboot those systems first if they terminate untrusted or Internet-facing virtual services, especially with IPv6.
• Until patched, tighten ICMP/ICMPv6 allow-lists and anti-spoofing in front of directors; monitor for connection flaps correlated with ICMP errors.
• Track distribution kernel CVEs/advisories for the IPVS checksum fix because this record lists no explicit fixed versions.
• Do not treat this as KEV/ransomware-driven emergency change, but do not defer it on Internet-exposed IPVS either.