CVE-2026-64055

What it actually does

This vulnerability is a memory-corruption flaw in the Linux kernel Cortina Ethernet GMAC receive path. The driver assembles received packet fragments across a ring buffer during NAPI polling. If the receive ring is emptied before a packet is fully assembled, the fragment counter is reset on the next poll even though the partially assembled socket buffer still exists. Subsequent fragments can then be associated incorrectly, potentially corrupting packet state and kernel memory. Because the flaw is in kernel networking code and is reachable through network traffic handled by the affected Ethernet driver, successful exploitation could plausibly cause kernel crashes, denial of service, or potentially code execution in kernel context, although no public exploit maturity is reported.

Why it matters to the business

Systems using the affected Linux kernel driver for Cortina Ethernet hardware may be exposed to remotely triggerable kernel instability. In practical terms, exploitation could interrupt network services, crash appliances or embedded systems, and potentially allow deeper system compromise if reliable kernel memory corruption exploitation is developed. The CVSS score indicates critical severity, but the EPSS value is currently low and the issue is not listed in CISA KEV, so prioritization should focus first on internet-facing or untrusted-network-facing devices using the affected driver.

How an attack unfolds

An attacker would need network reachability to an interface backed by the affected Cortina GMAC driver. They would send crafted traffic designed to influence how receive fragments are placed into the driver ring buffer, specifically attempting to cause a NAPI poll cycle to end after the ring is emptied while a packet remains only partially assembled. On the next receive poll, the driver incorrectly restarts its fragment counter from zero instead of preserving the previous fragment state. This can cause later fragments to be processed as if they were the beginning of a new fragment sequence, corrupting the in-kernel socket buffer state. The most likely observable result is a kernel warning, oops, panic, network interface reset, or system crash; in a worst case, carefully controlled corruption could be used to alter kernel memory and gain code execution. No public exploitation or known threat actor activity is currently indicated by the provided data.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the Cortina Ethernet GMAC receive fragment counter handling. If distribution-specific fixed package versions are not yet available, track vendor advisories for the running kernel branch and update to the first patched release provided by the OS, appliance, or embedded-device vendor. Where immediate patching is not possible, reduce exposure by isolating affected Cortina GMAC interfaces from untrusted networks, disabling unused affected interfaces, applying ingress filtering, limiting jumbo/fragment-heavy traffic where operationally feasible, and placing vulnerable devices behind trusted network segments. Because this is kernel driver code, application-level mitigations are not sufficient if the vulnerable interface remains exposed.

How to confirm the fix worked

Confirm the running kernel version and vendor patch level include the fix that carries the RX fragment counter across gmac_rx() NAPI poll invocations. Validate whether the Cortina GMAC driver is present, loaded, or built into the kernel, and whether active interfaces use that driver. On Linux systems, review kernel package changelogs, vendor errata, or source commits for the Cortina Ethernet GMAC frag counter fix. After remediation, reboot into the patched kernel and verify the active kernel version with standard OS tooling. Where safe test capability exists, perform controlled network stress testing of the affected interface and confirm there are no kernel oops, panic, RX path warnings, or interface resets under fragmented or high-rate traffic conditions.

Typical attack path

1. Identify a target running a Linux kernel build that includes the affected Cortina Ethernet GMAC driver.
2. Confirm or infer that the reachable network interface is backed by the affected Cortina GMAC hardware/driver.
3. Send crafted network traffic patterns intended to manipulate receive-ring exhaustion and fragmented packet assembly during NAPI polling.
4. Trigger the condition where a poll cycle exits with an incompletely assembled packet while the fragment counter is later reset incorrectly.
5. Cause malformed SKB fragment state, leading to kernel memory corruption.
6. Achieve denial of service through kernel crash or, if exploit primitives are reliable, attempt kernel-level code execution or privilege escalation.

How to detect it

There are no specific public exploit indicators provided for this vulnerability. Detection should focus on signs of attempted or successful exploitation against systems using the affected Cortina Ethernet GMAC driver. Review kernel logs, persistent journal logs, serial console logs, crash dumps, appliance watchdog logs, and network-device telemetry for kernel oops, panic, slab corruption, page faults, SKB/GRO warnings, NAPI receive-path errors, interface resets, or unexplained reboots correlated with bursts of fragmented, oversized, malformed, or high-rate inbound traffic. Network telemetry may show repeated traffic bursts to the affected interface immediately before a crash, but packet contents are not currently associated with a stable signature. If crash dumps are available, triage stack traces for the Cortina GMAC receive path, gmac_rx(), NAPI polling, GRO fragment handling, napi_gro_frags(), or napi_free_frags(). Because no KEV listing, ransomware use, named threat actors, or mature public exploit are indicated, absence of known IOCs should not be considered proof of non-exploitation.

What your security team should do

• Inventory Linux systems, appliances, and embedded devices that use Cortina Ethernet GMAC hardware or the corresponding kernel driver.
• Prioritize patching for devices with affected interfaces exposed to untrusted, adjacent, or internet-routed networks.
• Track distribution and vendor advisories because fixed package versions were not provided in the input and may vary by kernel branch.
• If patching is delayed, segment or firewall affected interfaces so only trusted traffic can reach them.
• Increase monitoring for kernel crashes, network-driver warnings, watchdog resets, and unexpected reboots on systems using the affected driver.
• Coordinate with network and platform teams before stress testing, because malformed traffic validation may crash vulnerable systems.
• Do not treat the low EPSS value as a reason to ignore the issue; kernel network memory corruption with unauthenticated reachability can become urgent if exploit code appears.