Cloudanix VulnDB

CVE-2026-63896

None

CVSS

—

EPSS

0.2%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how some USB devices handle certain requests could let a connected computer crash the device or potentially take control of it.

Exploitation
Physical Access
Attacker needs
Physical Access
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Integer underflow in WebUSB GET_URL handler in composite_setup allows wLength smaller than header length to wrap, resulting in memcpy of nearly UINT_MAX bytes from cdev->landing_page into url_descriptor buffer, causing slab out-of-bounds write.

Why it matters to the business

Kernel memory corruption on USB gadget devices with WebUSB enabled can lead to crashes, denial of service, or potential code execution, disrupting embedded or peripheral systems relying on this subsystem.

How an attack unfolds

Attacker connects as USB host and issues a single SETUP packet for GET_URL with wLength smaller than WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH against any gadget configured with webusb/use=1 and a landingPage; the underflow triggers oversized memcpy that corrupts adjacent kernel memory.

How to fix it

Apply the upstream fix that checks wLength against header length before subtraction and sets landing_page_length to landing_page_offset for small requests; rebuild and deploy updated kernel images to all affected systems.

How to confirm the fix worked

Confirm kernel source contains the early wLength check and no-op memcpy path; test with a USB host sending undersized GET_URL requests while monitoring for KASAN reports or FORTIFY traps.

Typical attack path

  1. Configure or identify target gadget with WebUSB landing page enabled
  2. Send USB SETUP packet requesting GET_URL descriptor with wLength < header size
  3. Trigger integer underflow during length calculation
  4. Execute oversized memcpy causing memory corruption or KASAN/FORTIFY detection

How to detect it

Inspect kernel logs for KASAN slab-out-of-bounds or FORTIFY_SOURCE memcpy warnings mentioning composite_setup and url_descriptor; review USB gadget configuration for webusb/use=1 settings.

What your security team should do

  • Prioritize kernel updates on any systems exposing USB gadgets with WebUSB
  • Disable webusb/use=1 or remove landingPage configuration where WebUSB is not required
  • Monitor for unusual USB control transfers during device enumeration

The record

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling The WebUSB GET_URL handler in composite_setup() narrows landing_page_length to fit the host-supplied wLength using landing_page_length = w_length - WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH + landing_page_offset; If wLength is smaller than WEBUSB_URL_DESCRIPTOR_HEADER_LENGTH the unsigned subtraction wraps, and the subsequent memcpy(url_descriptor->URL, cdev->landing_page + landing_page_offset, landing_page_length - landing_page_offset); ends up copying close to UINT_MAX bytes from cdev->landing_page into cdev->req->buf. KASAN reports a slab-out-of-bounds in composite_setup on the kmalloc-2k gadget_info allocation, and FORTIFY_SOURCE traps the memcpy as a 4294967293-byte field-spanning write into url_descriptor->URL (size 252). A USB host can reach this from a single SETUP packet against any gadget that has webusb/use=1 and a landingPage configured. Handle the small-wLength case before the math: when the host requested fewer bytes than the URL descriptor header, only the header is meaningful and no URL bytes need to be copied. Setting landing_page_length to landing_page_offset makes the existing memcpy a no-op and leaves the descriptor returned to the host unchanged for all larger wLength values.

Affected packages

Ecosystem Package Introduced Fixed