Cloudanix VulnDB

CVE-2026-68120

High · 7.5

CVSS

7.5

EPSS

0.4%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

Certain unusual network packets can freeze a computer's ability to send data, temporarily cutting off its network connection.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Malformed or fragmented packets with incomplete IPv4/IPv6/TCP/UDP headers or undersized PTP UDP payloads cause the hardware parser to expect missing data and trigger a TX hang in the rtase driver.

Why it matters to the business

Network transmission stops on affected systems, disrupting connectivity and causing denial of service for network-dependent operations until the system is restarted or the driver recovers.

How an attack unfolds

An attacker sends crafted packets containing incomplete transport headers or short UDP payloads on ports 319/320 that match PTP parsing rules; the rtase hardware parser fails to handle the missing data and hangs the transmit path, resulting in loss of network output.

How to fix it

Apply the kernel workaround that drops malformed packets before transmission and pads short transport data to the minimum length required by the hardware parser; upgrade to a fixed kernel version containing the rtase driver changes.

How to confirm the fix worked

Confirm the updated driver is loaded, test with crafted fragment and PTP packets to verify no TX hang occurs, and monitor kernel logs for absence of related hang events.

Typical attack path

  1. Locate systems running the vulnerable rtase network driver
  2. Craft IPv4 fragments, IPv6 fragments, or small PTP UDP packets with incomplete headers
  3. Transmit the packets to the target interface
  4. Observe TX hang and resulting loss of outbound network traffic

How to detect it

Search kernel logs and driver traces for messages indicating TX hang conditions in the rtase module; inspect network traffic for IPv4 non-initial fragments, IPv6 fragments with UDP, or UDP packets on ports 319/320 carrying less than the minimum padding length.

  • TX hang
  • rtase
  • RTASE_MIN_PAD_LEN
  • destination port 319
  • destination port 320

What your security team should do

  • Prioritize kernel updates containing the rtase TX hang workaround
  • Deploy network filters to drop suspicious fragments and short PTP packets
  • Enable logging of driver transmit errors and schedule periodic review of network interface health

The record

In the Linux kernel, the following vulnerability has been resolved: rtase: Workaround for TX hang caused by hardware packet parsing The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission.

Affected packages

Ecosystem Package Introduced Fixed