---
id: "CVE-2026-98597"
kind: "vulnerability"
aliases: ["CVE-2026-98597"]
title: "Linux kernel sr9700 USB driver: receive length check misses header overhead"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["infrastructure", "linux-kernel", "self-hosted", "usb-ethernet"]
not_affected_if: ["driver-not-loaded", "no-sr9700-adapter"]
published_at: "2026-10-18T16:17:12+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:21:38+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98597", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel sr9700 USB driver: receive length check misses header overhead

The Linux kernel's sr9700 USB Ethernet driver compares a received packet's payload length against the whole receive buffer without accounting for the header and CRC bytes, so a crafted USB packet can read or write past the buffer. The sources do not state the attacker-controlled impact beyond this bounds error.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the running kernel with `uname -r` and see whether the sr9700 driver is loaded with `lsmod | grep sr9700`
- unknown

## Fix

- Update the Linux kernel to a release that includes the sr9700 length-check fix; the exact fixed version is unknown from the sources
- unknown

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98597

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

net: usb: sr9700: include receive overhead in the length check

The receive fixup subtracts the Ethernet CRC from the reported packet
length, but compares that payload length against the whole remaining
receive buffer. The following copy starts after the three-byte header,
and the cursor advance consumes both that header and the four-byte CRC.

Require the payload to fit after SR_RX_OVERHEAD before copying it or
advancing to the next packet. The loop already ensures that the
remaining buffer is larger than the overhead, so the subtraction is
safe.

The issue was found by our static-analysis tool.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_