Live › vulnerability › CVE-2026-98621
Go to dashboardThe Linux kernel's GUE tunnel parser accepted REMCSUM option offsets in reversed order, which underflows a 16-bit checksum offset. A forwarded packet can then make a hardware checksum driver write two bytes about 64 KiB past its destination buffer.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Hosts and routers that terminate or forward GUE (Generic UDP Encapsulation) traffic with the REMCSUM option on a Linux kernel carrying the unpatched code. Systems that do not use GUE tunnels are unlikely to process such packets. unknown whether the sources list affected kernel version ranges.
No product ranges from the sources yet.
uname -r and compare with the first fixed kernel in your distribution's advisoryip link show type gueEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
net: gue: reject invalid REMCSUM offsets
The REMCSUM option carries an absolute checksum start and checksum field offset. gue_remcsum() passes them to skb_remcsum_process(), whose partial path stores offset - start in the u16 skb->csum_offset variable. If offset is less than start, this underflows.
A forwarded packet can retain CHECKSUM_PARTIAL and reach a NETIF_F_HW_CSUM driver which trusts the metadata, leading skb_copy_and_csum_dev() to write two bytes about 64 KiB beyond the destination buffer.
Reject reversed tuples in validate_gue_flags(), after the existing length validation, so all GUE parsers enforce the ordering in one place.
This page as .md · .json · in your agent: get_signal("CVE-2026-98621")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.