CVE-2026-64547

CVE-2026-64547 in the net1080 USB network driver is a bounds-check ordering failure that deserves more scrutiny than its CVSS 8.1 score suggests. The driver validates `packet_len` against `NC_MAX_PACKET` (the protocol maximum of 16384 bytes) but never checks whether `packet_len` exceeds the actual `skb->len` of the received buffer before performing the pad-byte read. This allows a malicious or buggy USB device to trigger an out-of-bounds read by advertising a protocol-valid but buffer-invalid length. If you run this driver, the fix is straightforward: ensure `packet_len <= skb->len` before accessing any byte at offset `packet_len`. The canonical pattern is `if (packet_len > skb->len) return NULL;` at the start of the rx_fixup function. This is a one-line check that must come before any device-supplied length is used as an array index or read offset. The more concerning issue is the pattern itself. This is the fourth or fifth USB network driver fix in three years with the identical failure mode—checking against protocol maximum instead of actual buffer size. The attack surface is USB device-level, which CVSS treats as 'adjacent' with reduced scores. But in high-assurance environments, a compromised USB device represents a realistic supply chain threat with DMA access and firmware persistence that remote exploits lack. The 'adjacent' classification underweights this. Audit your kernel's USB network drivers. Every rx_fixup implementation that handles external length values should be reviewed for this same ordering failure. The pattern to flag is any check of the form `if (len > MAX_PROTOCOL_VALUE)` without a corresponding `if (len > skb->len)` guard before memory access. If you maintain USB networking drivers, treat device-supplied lengths as untrusted input regardless of protocol-level validation—the USB stack's reliable-transport abstraction should not be inherited by protocol handlers.

Reviewed through automated stages and approved by a human before publication.