Bug 2507275 (CVE-2026-64351) - CVE-2026-64351 kernel: net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()
Summary: CVE-2026-64351 kernel: net: usb: kalmia: bound RX frame length in kalmia_rx_f...
Keywords:
Status: NEW
Alias: CVE-2026-64351
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-07-25 10:14 UTC by OSIDB Bzimport
Modified: 2026-07-27 05:56 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-07-25 10:14:04 UTC
In the Linux kernel, the following vulnerability has been resolved:

net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()

kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 *
KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that
skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can
deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or
leave a short trailing remainder on a later loop iteration. Either case
underflows usb_packet_length to about 65530.

That bypasses the usb_packet_length < ether_packet_length truncation path.
The device-supplied ether_packet_length, a le16 up to 65535 read from
header_start[2], then drives a memcmp() and the following skb_trim() and
skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10,
which is 14000 bytes. That is an out of bounds read.

Require both the start and end framing headers to be present before
subtracting them, on every loop iteration.


Note You need to log in before you can comment on or make changes to this bug.