CVE-2026-64339: usb: misc: usbio: bound bulk IN response length to the received transfer

Greg Kroah-Hartman <[email protected]> Sat, 25 Jul 2026 10:49:16 +0200
Newsgroups org.kernel.vger.linux-cve-announce
Message-ID <2026072515-CVE-2026-64339-cb0c@gregkh>
From: Greg Kroah-Hartman <[email protected]>

Description
===========

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

usb: misc: usbio: bound bulk IN response length to the received transfer

usbio_bulk_msg() copies bpkt_len = le16_to_cpu(bpkt->len) bytes out of
the bulk IN buffer (usbio->rxbuf, allocated with size usbio->rxbuf_len)
into the caller's buffer.  bpkt_len is fully controlled by the device
and is only checked against ibuf_len; ibuf_len in turn is checked
against usbio->txbuf_len, not against rxbuf_len:

	if ((obuf_len > (usbio->txbuf_len - sizeof(*bpkt))) ||
	    (ibuf_len > (usbio->txbuf_len - sizeof(*bpkt))))
		return -EMSGSIZE;

txbuf_len and rxbuf_len are taken independently from the bulk OUT and
bulk IN endpoint wMaxPacketSize in usbio_probe().  A malicious or
malfunctioning device that advertises a large bulk OUT endpoint and a
small bulk IN endpoint (e.g. by claiming one of the quirk-free IDs such
as the Lattice NX33U, 0x2ac1:0x20cb) therefore makes ibuf_len, and
hence the device-supplied bpkt_len, exceed rxbuf_len.  memcpy() then
reads up to txbuf_len - rxbuf_len bytes past the end of the rxbuf slab
object.  The over-read bytes are handed back to the i2c layer and on to
user space through i2c-dev, disclosing adjacent slab memory; with KASAN
this is reported as a slab-out-of-bounds read.

The number of bytes actually received is already known: act equals the
URB actual_length and is bounded by rxbuf_len.  Reject any response
that claims more payload than was received, mirroring the existing
"act < sizeof(*bpkt)" check just above.

The control path (usbio_ctrl_msg()) is not affected: it uses a single
buffer (ctrlbuf) for both directions, so its analogous copy can never
leave the allocation.

Found by code review.  The out-of-bounds read was confirmed under
AddressSanitizer with a faithful userspace model of usbio_bulk_msg()'s
receive path (an rxbuf_len-sized buffer, the same act/ibuf_len/bpkt_len
checks and the memcpy).  A USB raw-gadget + dummy_hcd reproducer is
also available.

The Linux kernel CVE team has assigned CVE-2026-64339 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.18 with commit 121a0f839dbb397af5fabb701cea3e9983223e50 and fixed in 6.18.39 with commit 48394f94211cf8fe0ea8604fc441633abf90fc94
	Issue introduced in 6.18 with commit 121a0f839dbb397af5fabb701cea3e9983223e50 and fixed in 7.1.4 with commit fc1b546973c1442d5b947fcdd03581f20ecc5bd2
	Issue introduced in 6.18 with commit 121a0f839dbb397af5fabb701cea3e9983223e50 and fixed in 7.2-rc3 with commit 8c6314489550fa81d41723a0ff33f655b5b6c7b6

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64339
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/usb/misc/usbio.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/48394f94211cf8fe0ea8604fc441633abf90fc94
	https://git.kernel.org/stable/c/fc1b546973c1442d5b947fcdd03581f20ecc5bd2
	https://git.kernel.org/stable/c/8c6314489550fa81d41723a0ff33f655b5b6c7b6