CVE-2026-64056 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Make RX SKB per-port
The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both.
Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead.
Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped.
Zero it in some place where not strictly necessary just to emphasize what is going on.
This was found by Sashiko during normal patch review.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability identified in the Linux kernel's ethernet driver for cortina hardware represents a critical race condition affecting multi-port network interfaces. This issue manifests specifically within the gmac_rx() function where a static local socket buffer (SKB) is used to assemble packets from fragmented data. The problem becomes particularly severe on Gemini-based hardware which features dual ethernet ports, creating potential concurrency conflicts when both ports are actively processing network traffic simultaneously. When multiple network fragments arrive concurrently on different ports, the shared static SKB can become corrupted or overwritten during race conditions, leading to malformed packet assembly and potential network disruption.
The technical flaw stems from improper resource management within the network driver's receive path implementation. The original code design utilized a single static local SKB variable across all port contexts, violating fundamental principles of concurrent programming in kernel space. This approach fails to account for the fact that multiple hardware ports can operate simultaneously, each requiring independent packet assembly buffers. The race condition occurs because both ports may attempt to use the same memory location for fragment reassembly without proper synchronization mechanisms, creating a scenario where one port's fragment processing can overwrite another port's data structures. According to CWE-362, this represents a concurrent execution issue that allows for race conditions during resource access and manipulation.
The operational impact of this vulnerability extends beyond simple packet corruption to potentially compromise network reliability and system stability. When both ethernet ports are active and processing fragmented packets simultaneously, the likelihood of encountering corrupted SKB data increases significantly. This can result in dropped packets, malformed network frames, or even complete network interface instability. The vulnerability affects systems running on Gemini hardware platforms where dual-port ethernet controllers are present, making it particularly relevant for embedded networking equipment and server environments utilizing cortina-based network controllers. From an ATT&CK perspective, this represents a potential privilege escalation vector through network service disruption, as malicious actors could exploit the race condition to cause denial of service or manipulate network traffic flow.
The proposed fix addresses the core issue by implementing per-port SKB management rather than relying on static allocation. This solution involves modifying the port structure to maintain its own RX SKB instance, ensuring that each ethernet port operates with independent packet assembly buffers. The implementation requires careful pointer management throughout the receive processing pipeline, including zeroing the SKB pointer after calling napi_gro_frags() to prevent stale references, and during error conditions when napi_free_frags() is invoked or when a port is stopped. This approach aligns with kernel development best practices for concurrent resource management and eliminates the race condition by ensuring proper isolation between different network port contexts. The fix also includes additional zeroing operations in non-critical locations purely for clarity and maintainability, emphasizing the intended behavior of the resource management scheme and reducing the likelihood of similar issues in future modifications to the driver code.
This vulnerability resolution demonstrates the importance of proper concurrent programming practices in kernel space development, particularly when dealing with hardware that supports multiple independent interfaces. The fix not only resolves the immediate race condition but also establishes a more robust foundation for multi-port network driver implementations. The solution's effectiveness is validated through proper resource lifecycle management and adherence to kernel networking subsystem conventions, ensuring compatibility with existing network stack operations while providing the necessary isolation between concurrent port operations. The patch represents a standard approach to addressing hardware-specific concurrency issues in embedded networking drivers, where careful attention to shared resources and proper synchronization mechanisms becomes critical for system reliability.