CVE-2026-98597

What it actually does

The sr9700 receive path subtracts the Ethernet CRC from the reported packet length but validates the result against the entire remaining buffer instead of the payload space after the three-byte header and four-byte CRC overhead, enabling an out-of-bounds copy or cursor advance when a crafted packet reports an insufficient length.

Why it matters to the business

Systems using the sr9700 USB Ethernet adapter can experience kernel crashes, denial of service, or potential local privilege escalation; the flaw affects any Linux deployment relying on this driver for network connectivity.

How an attack unfolds

An attacker with the ability to inject crafted USB frames (via a malicious device or man-in-the-middle on the USB bus) supplies packets whose reported length, after CRC subtraction, fails to account for SR_RX_OVERHEAD, causing the subsequent memcpy and pointer advancement to read or write beyond allocated receive buffers.

How to fix it

Update the Linux kernel to a version containing the fix that enforces payload length must fit after SR_RX_OVERHEAD before copying or advancing; apply the vendor-supplied kernel package that resolves the sr9700 receive validation.

How to confirm the fix worked

Confirm the installed kernel contains the commit titled 'net: usb: sr9700: include receive overhead in the length check'; test by attaching an sr9700 device and exercising receive paths with both valid and edge-case length packets while monitoring for oops or panics.

Typical attack path

1. Attacker presents a malicious or compromised USB Ethernet device or injects frames on the USB bus
2. Driver receives a packet whose length field leads to payload length being smaller than SR_RX_OVERHEAD after CRC subtraction
3. Length check incorrectly passes because it compares against the full remaining buffer
4. Copy starts after the three-byte header and advances past both header and CRC, accessing memory outside the intended packet buffer
5. Resulting invalid memory access triggers kernel panic, information leak, or controllable memory corruption

How to detect it

Search kernel logs for oops or panic messages referencing sr9700, usbnet, or receive fixup functions; inspect dmesg and syslog for buffer-overrun warnings or invalid length values during USB Ethernet packet processing.

What your security team should do

• Prioritize kernel updates on all systems that may use sr9700-based USB adapters
• Disable or blacklist the sr9700 module on systems where the hardware is not required
• Monitor vendor security advisories for the specific distribution kernel package containing this fix
• Review endpoint detection and response logs for any sr9700-related oops or USB receive anomalies