CVE-2026-64056

What it actually does

This is a race condition in the Linux kernel Cortina/Gemini Ethernet receive path. The driver used a static socket buffer pointer while assembling fragmented received packets in gmac_rx(), but Gemini systems can have two Ethernet ports active at the same time. Concurrent receive processing across both ports can cause the same buffer state to be reused or corrupted between ports. At a technical level, that can lead to memory corruption in kernel context, packet misassembly, kernel crashes, denial of service, and potentially arbitrary code execution with kernel privileges if an attacker can reliably influence packet timing and contents.

Why it matters to the business

Systems using the affected Linux kernel driver for Cortina/Gemini Ethernet hardware may be vulnerable to remote disruption or compromise through network traffic. Successful exploitation could interrupt network availability, crash affected appliances or embedded systems, or in a worst case allow takeover of the device at the operating-system level. Although the CVSS score is critical, the currently reported EPSS is low, the issue is not listed in CISA KEV, and no public exploit maturity is reported, so urgency should be driven by exposure of affected hardware and whether both Ethernet ports are in use.

How an attack unfolds

An attacker would need network reachability to an affected device using the Cortina/Gemini Ethernet driver, particularly a configuration where both Ethernet ports can receive traffic. The attacker sends crafted or carefully timed traffic that causes fragmented receive processing on one port while the other port is also processing receive fragments. Because the vulnerable driver keeps packet assembly state in a static local SKB rather than per-port state, the two receive paths can race and corrupt shared kernel buffer state. Depending on timing, kernel build options, memory layout, and traffic characteristics, the result may be a crash, malformed packet processing, data corruption, or potentially control over kernel memory. There are no named threat actors or ransomware campaigns currently associated with this issue in the provided intelligence.

How to fix it

Update the Linux kernel to a version that includes the fix changing the Cortina/Gemini Ethernet RX SKB from static shared state to per-port state. If consuming a vendor kernel, apply the vendor-provided security update rather than only tracking upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling unused Ethernet ports, avoiding dual-port concurrent operation on affected devices, placing affected systems on trusted network segments, filtering untrusted traffic before it reaches the device, and enabling kernel hardening features where available. Because no exact fixed package versions were provided, security teams should verify remediation through the applicable Linux distribution, appliance vendor, or kernel stable tree advisory for CVE-2026-64056.

How to confirm the fix worked

Confirm that the running kernel or vendor firmware contains the patch that makes the RX SKB per-port in the Cortina/Gemini Ethernet driver. Validate by checking the installed kernel package version against the relevant vendor advisory or by inspecting the driver source/build metadata for the per-port RX SKB change. Confirm whether affected hardware and driver code are present by reviewing loaded modules, kernel configuration, boot logs, and device tree or PCI/platform device information for Cortina/Gemini Ethernet support. After patching, perform controlled network testing with both Ethernet ports active and monitor for kernel oops, panic, packet corruption, or driver reset messages. Exposure is reduced if the affected driver is not present, the hardware is not used, or only fixed kernels are running.

Typical attack path

1. Identify a Linux-based device or appliance using Cortina/Gemini Ethernet hardware and an affected kernel driver.
2. Confirm or infer that both Ethernet ports are active or capable of concurrent receive processing.
3. Generate traffic patterns that exercise fragmented packet receive handling on one or both ports.
4. Time packets so both ports enter the vulnerable receive assembly path concurrently.
5. Trigger corruption of the shared static SKB state used by the driver.
6. Cause a kernel crash, network service disruption, or attempt to shape memory corruption toward code execution.

How to detect it

There is no reliable single log indicator that proves exploitation, because this is a kernel race condition in a network driver and successful attempts may only appear as instability or memory corruption. Review kernel logs, persistent journal data, crash dumps, appliance event logs, and network monitoring around the time of any unexpected reboot, kernel panic, or network outage. Look for oops or panic traces involving the Cortina/Gemini Ethernet driver, gmac_rx(), NAPI/GRO receive handling, SKB corruption, page fragment handling, or general kernel memory corruption shortly after bursts of inbound traffic. Correlate crashes with packet captures, NetFlow, firewall logs, switch port counters, and IDS telemetry showing unusual fragmented traffic, high packet rates, or concurrent traffic across both Ethernet ports. If kdump/vmcore data is available, inspect stack traces and corrupted objects for receive-path functions and SKB/page-fragment structures. Absence of logs does not rule out exploitation, especially on embedded systems that do not persist kernel logs across reboot.

• gmac_rx
• napi_gro_frags
• napi_free_frags
• skb
• SKB
• Gemini Ethernet
• Cortina Ethernet
• GMAC
• kernel BUG
• Oops:
• Kernel panic
• general protection fault
• BUG: unable to handle kernel
• slab-use-after-free
• use-after-free
• corrupted list
• page allocation failure
• net: ethernet: cortina
• cortina
• gemini

What your security team should do

• Prioritize inventory: identify Linux systems, embedded devices, routers, NAS devices, and appliances using Cortina/Gemini Ethernet hardware or the related kernel driver.
• Patch affected systems to a vendor kernel or firmware release that includes the per-port RX SKB fix.
• Treat internet-facing or untrusted-network-facing devices with both Ethernet ports enabled as the highest-risk population.
• If patching is delayed, disable unused Ethernet ports or restrict traffic to trusted management and service networks.
• Monitor affected systems for unexplained kernel crashes, network driver resets, packet receive errors, and messages referencing Gemini, Cortina, GMAC, SKB, NAPI, or GRO.
• Because the issue is not currently KEV-listed and has low EPSS, balance emergency response against actual hardware exposure, but do not defer patching on exposed embedded or edge devices.
• Ensure appliance and firmware vendors are tracked separately from general-purpose Linux distributions, since embedded devices may receive fixes through firmware updates rather than standard package managers.