CVE-2026-64540 in Linux
Summary
by MITRE • 07/28/2026
In the Linux kernel, the following vulnerability has been resolved:
usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()
genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received.
A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes.
skb_put_data(gl_skb, packet->packet_data, size);
then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up.
BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...
skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/28/2026
The vulnerability resides in the Linux kernel's usbnet driver specifically affecting the GL620A device implementation where an out-of-bounds read occurs during packet processing within the genelink_rx_fixup() function. This flaw represents a classic buffer overflow condition that arises from insufficient validation of packet length parameters provided by the network device itself. The function processes aggregated RX frames by splitting them into individual packets using packet lengths extracted directly from device-supplied headers without proper bounds checking against actual received data quantities. According to CWE-129, this constitutes an improper validation of array index or buffer bounds, while the ATT&CK framework would classify this under privilege escalation through kernel memory corruption techniques.
The technical execution path begins when a malicious GeneLink GL620A device crafts a short URB (USB Request Block) containing a header that indicates multiple packets are present but with the first packet claiming up to 1514 bytes in length. This maximum packet size constant serves as an upper boundary for the length field but provides no protection against actual data receipt limitations. The problematic code sequence at line 112 in drivers/net/usb/gl620a.c performs a direct copy operation using skb_put_data() without verifying whether the specified packet size exceeds available buffer space. This results in reading beyond the allocated receive buffer boundaries and subsequently exposes kernel heap memory contents to the network stack, creating a data leak vulnerability.
The impact of this vulnerability extends beyond simple information disclosure as it operates within the USB network interface's RX softirq context, eliminating any privilege requirements for exploitation. The KASAN (Kernel Address Sanitizer) report demonstrates that the out-of-bounds read occurs at address ffff888011309708 during processing by ksoftirqd/0/14, indicating this is a kernel-level memory corruption issue. The call trace shows execution flow through standard kernel networking mechanisms including __asan_memcpy, usbnet_bh, and softirq processing functions, confirming that the vulnerability exploits established kernel pathways rather than requiring complex attack vectors.
The recommended mitigation strategy involves implementing proper bounds checking before packet data copying operations by inserting skb_pull() verification ahead of the problematic copy operation. This approach aligns with defensive programming principles and follows existing kernel patterns where buffer validation occurs prior to data manipulation. The fix ensures that packets which would exceed available received data are rejected before any memory access occurs, maintaining functionality for legitimate well-formed frames while preventing the out-of-bounds read condition. This solution addresses the root cause by enforcing proper length validation against actual buffer boundaries rather than relying solely on device-provided metadata, thus aligning with security best practices for kernel driver development and memory safety protocols.