Look up another CVE · open CVE-2026-64540 in the interactive tracker
CVE-2026-64540
usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()
Published 2026-07-27 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64540 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4720-1 · 2026-08-05 · text | 6.1.180-1 | Update the kernel and reboot. DLA-4720-1 shipped the fix on 2026-08-05, in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6405-1 · 2026-07-31 · text | 6.12.100-1 | Update the kernel and reboot. DSA-6405-1 shipped the fix on 2026-07-31, in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4724-1 · 2026-08-07 · text | 6.12.100-1~deb12u1 | Update the kernel and reboot. DLA-4724-1 shipped the fix on 2026-08-07, in 6.12.100-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/usb/gl620a.c
- What this is
- USB NETWORKING DRIVERSMAINTAINERS section matched on drivers/net/usb/ · linux-usb@vger.kernel.org · Odd Fixes
- Kernel module
- gl620a
Check it on the machine
grep -wE 'CONFIG_USB_NET_DRIVERS|CONFIG_USB_NET_GL620A' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w gl620aPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_USB_NET_DRIVERS, CONFIG_USB_NET_GL620A
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-27 (3 months ago)source
- CVSS
- 8.1 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.27%, higher than 18.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.14 | 5.10.261 | 255d03551f94 |
| 2.6.14 | 5.15.212 | 4359376e6238 |
| 2.6.14 | 6.1.178 | 8624e179fa3c |
| 2.6.14 | 6.6.145 | 573418f7ea8f |
| 2.6.14 | 6.12.97 | 0575599e451a |
| 2.6.14 | 6.18.40 | 0a7d9c7c5f1f |
| 2.6.14 | 7.1.5 | 3ef79fa3860e |
| 2.6.14 | 7.2 | 8ff7f2a6da4f |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4724-1 | 2026-08-07 | bookworm 6.12.100-1~deb12u1 | tracker |
| DLA-4723-1 | 2026-08-07 | bullseye 6.1.180-1~deb11u1 | tracker |
| DLA-4720-1 | 2026-08-05 | bookworm 6.1.180-1 | tracker |
| DLA-4717-1 | 2026-08-05 | bullseye 5.10.262-1 | tracker |
| DSA-6405-1 | 2026-07-31 | trixie 6.12.100-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The gl620a driver is a FLAG_POINTTOPOINT network interface, and the malformed aggregation header is received network data generated by the peer host on the other end of the GeneLink host-to-host cable, processed in the usbnet RX softirq. The attack is confined to that directly attached link segment, making it logically adjacent rather than routable or purely physical.
- AC:LAttack complexity, low
- The attacker fully controls the frame contents and only needs to send an 18-byte URB declaring packet_count > 1 with a first packet_length of up to 1514; the missing bounds check is deterministic with no race, memory-layout, or timing dependency.
- PR:NPrivileges required, none
- No credentials or privileges on the target are required — the parse runs unconditionally in the RX softirq for any frame received once the interface is up, with no capability or authentication check anywhere on the usbnet_bh -> rx_process -> rx_fixup path.
- UI:NUser interaction, none
- No victim action is needed beyond the interface being in its normal operational state, which is inherent to a host-to-host link cable in use and is done automatically by NetworkManager/systemd-networkd.
- S:UScope, unchanged
- The over-read and the leaked memory stay within the kernel's own security authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- Up to ~47 KB of adjacent kernel heap is read past the valid received data and delivered up the network stack as an Ethernet frame, exfiltrating arbitrary slab contents (prior packet data, keys, pointers) to the attacker and to any local packet capture — an unbounded, repeatable kernel memory disclosure.
- I:NIntegrity impact, none
- The defect is strictly a read; gl_skb is allocated with alloc_skb(size) before skb_put_data() copies exactly size bytes, so no kernel memory is written out of bounds or otherwise modified.
- A:HAvailability impact, high
- With rx_urb_size reduced the read runs tens of kilobytes past a small slab object and can touch unmapped memory from softirq context, and on hardened kernels the KASAN slab-out-of-bounds report (as captured in the fix commit) panics the machine; the attacker can repeat it with every frame.