CVE-2026-80827
USB: serial: option: fix slab OOB read in interrupt URB callback
No known exploitation. EPSS puts it in the 9th percentile. Fixed versions are out.
No public exploit knownFix1 product4 fixed builds listed below
e.g. OID 1.3.6.1.4.1.25623.1.1.10.2026.0506
What to do
Find your product and version, then upgrade to the build on the right.
- LinuxAffected: ≥ 58cfe9113e485f7e04bd0eac4fc4251b330af501, < fbe60fd2abc8a5561f39719a41ad9a01b5d8e567Upgrade to: fbe60fd2abc8a5561f39719a41ad9a01b5d8e567Affected: ≥ 58cfe9113e485f7e04bd0eac4fc4251b330af501, < 94e5525697b9e91ddc4071129874120a50a4f342Upgrade to: 94e5525697b9e91ddc4071129874120a50a4f342Affected: ≥ 58cfe9113e485f7e04bd0eac4fc4251b330af501, < 6b8cf5422c7e96ed5b22a8368eff663f3f98b8ecUpgrade to: 6b8cf5422c7e96ed5b22a8368eff663f3f98b8ecAffected: ≥ 58cfe9113e485f7e04bd0eac4fc4251b330af501, < 030e3a73d3c3aa67c44454649e984d6383cdb7d3Upgrade to: 030e3a73d3c3aa67c44454649e984d6383cdb7d3 + 5 more branchesStated by: CVE record
Versions as the sources state them. Full version matrix after sign-in
What it is
From the CVE record
In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.2% chance of exploitation activity in the next 30 days, which ranks it in the 9th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
4 events over 45 days, from the signal feeds we watch.
- Record updated
- OpenVAS check added
- Publishedrecord updated
Affected products
Sources
References in the record
- git.kernel.org/stable/c/030e3a73d3c3aa67c44454649e984d6383cdb7d3
- git.kernel.org/stable/c/060db7d48af1e650643c8b8319111a9ea2ce4486
- git.kernel.org/stable/c/2ef5560387f2c0713cee975be2b24b281bd90f3e
And 6 more references. See all after sign-in
In the news
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Linux, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI