Cloudanix VulnDB

CVE-2026-68366

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux USB video gadget handling can let a local program read memory it should not, which may crash the system or leak data until the kernel is updated.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds read in uvc_send_response() due to insufficient clamping of req->length against the 60-byte data->data buffer before memcpy, allowing reads beyond allocated source memory when both event_length and data->length exceed 60.

Why it matters to the business

Linux-based USB gadget devices (such as certain webcams or embedded peripherals) may experience kernel crashes, memory corruption, or information disclosure, potentially disrupting device functionality and requiring urgent patching across fleets.

How an attack unfolds

An attacker with local access to the UVC gadget device node issues a crafted UVCIOC_SEND_RESPONSE ioctl supplying large length values that bypass the existing negative check and event_length clamp, causing the kernel to copy past the end of the 60-byte response data buffer.

How to fix it

Apply the upstream kernel commit that adds clamping of req->length to sizeof(data->data); rebuild and deploy updated kernels to all affected systems; prioritize devices that expose UVC gadget functionality.

How to confirm the fix worked

Confirm the presence of the length clamp against sizeof(data->data) in uvc_send_response(); run regression tests exercising UVCIOC_SEND_RESPONSE with lengths > 60; verify no out-of-bounds accesses via kernel memory debugging tools.

Typical attack path

  1. Obtain local access or execute code on a system exposing the UVC gadget character device
  2. Open the UVC device and prepare a uvc_request_data structure with data->length > 60
  3. Invoke the UVCIOC_SEND_RESPONSE ioctl with a matching large wLength-derived event_length
  4. Trigger the memcpy that reads beyond the source buffer bounds
  5. Observe kernel oops, panic, or attempt to leverage any leaked data

How to detect it

Search kernel logs and audit trails for UVC ioctl activity followed by oops or panic messages; inspect user-space processes issuing UVCIOC_SEND_RESPONSE calls with oversized lengths; review device access logs on systems exposing /dev/video* gadget nodes.

What your security team should do

  • Inventory all Linux systems using usb gadget uvc and schedule kernel updates
  • Apply the fix immediately on any internet-facing or multi-tenant devices
  • Monitor kernel logs for UVC-related oops after deployment
  • Disable UVC gadget support where not required as a temporary mitigation

The record

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: req->length = min_t(unsigned int, uvc->event_length, data->length); ... memcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.

Affected packages

Ecosystem Package Introduced Fixed