CVE-2026-68366: Patch Linux USB Webcam Gadget Over-Read

The important boundary is easy to miss in a CVE title full of USB and UVC terminology: this is not a flaw in the ordinary Linux webcam driver used to connect a USB camera to a computer. It is in the reverse role, the UVC gadget function, where a Linux device uses USB device-mode hardware to impersonate a UVC camera to a connected host. A Raspberry Pi configured as a USB webcam, an embedded Linux product exposing a camera feed over an OTG port, or a purpose-built video bridge may be in scope. A Windows system connected to that device is the USB host; Windows itself is not identified as vulnerable by this CVE.

NIST published the entry on August 10, 2026, one day before this report. It has no NVD CVSS assessment, no mapped CWE, and no vendor-supplied severity score yet. The absence of a score should not be read as a clean bill of health, but it does reflect a narrowly conditional bug rather than a broadly exposed USB-host vulnerability.

The bug is a four-byte boundary failure​

The affected code is in

, in the

path used when the gadget’s userspace video application answers a UVC control request. That application passes the kernel a

through the

ioctl. The public structure contains a signed length field followed by exactly 60 bytes of response data.

Before the patch, the driver calculated the amount to copy by taking the smaller of two values: the control-request length advertised by the connected USB host and the length field passed in through the ioctl. The first value was already limited to

, which is 64 bytes. The second was rejected only when negative.

That left a small but real gap: if the host requested 61 to 64 bytes and the local userspace process supplied a matching positive response length, the kernel copied up to four bytes beyond the 60-byte

array. The copy destination—the USB control request buffer—was sized for the broader 64-byte UVC request limit. The bad boundary is on the source side:

reads past the end of the userspace-provided structure after it has been copied into the kernel.

The fix is correspondingly small. The updated code clamps the requested copy length against

as well as the host-request length and ioctl length. In plain terms, the driver will now send at most 60 bytes because that is all the response structure can actually contain.

Small fixes can still be security fixes. An over-read may disclose adjacent kernel memory through the USB response, trigger memory-safety instrumentation, or produce unstable behavior depending on compiler layout and surrounding data. The CVE description does not claim code execution, privilege escalation, a crash, or a demonstrated information leak, and no public severity assessment has been attached. Those limits matter: the record establishes the unsafe read, not a fully developed exploit chain.

A USB host alone does not satisfy the trigger​

The most useful finding in the technical record is that the connected host does not control both conditions needed to reach the bad copy. The host controls the UVC control request’s

, and can ask for as many as 64 bytes. But the response length is supplied by the Linux gadget’s local userspace companion through

.

Linux’s UVC Gadget documentation explains that the function exposes a V4L2 device on the gadget side and relies on a userspace application to process control requests and queue video data. The interface definition confirms that

accepts the 60-byte

payload. The kernel’s UVC setup handler records the host-requested length, then sends the event to userspace, which later calls the ioctl to submit its response.

That means an external USB host can create one half of the condition—asking for 61 through 64 bytes—but a local gadget application must also issue an oversized response length. A correctly written application that never claims more than 60 bytes will not exercise this defect, even before the kernel update.

This changes the operational assessment. The issue is relevant where a gadget service automatically reflects, derives, or mishandles host-controlled control-transfer lengths. It is also relevant where a compromised or otherwise untrusted local process has access to the UVC gadget device and can issue the ioctl. It is not a case where plugging a standard USB webcam into an unpatched Linux workstation creates exposure, nor is a Windows machine running Teams, OBS, Camera, or a browser made vulnerable simply because it sees a Linux-powered UVC gadget.

A malicious host still matters in deployments that trust arbitrary physical USB connections. It can supply the request length that opens the four-byte window. But the local UVC-gadget control application supplies the other value, making this a boundary-validation failure across the host–userspace–kernel chain rather than a simple host-to-kernel overflow.

The affected feature is optional and specialized​

The kernel’s UVC Gadget documentation identifies the feature as support for hardware on the device side of USB, such as boards with OTG-capable ports. It must be deliberately enabled through the USB gadget stack. Relevant kernel configuration options include

,

,

, and

.

The Kconfig entry calls

the “USB Webcam function” and states that it provides a userspace API for UVC control requests and video streaming to the host. The gadget must then be configured through configfs and bound to an available USB device controller. In other words, merely having a UVC-capable camera, the

host driver, or generic USB support in a distribution kernel does not mean a machine is actively using the affected path.

For Windows-focused users, the common scenario is a Linux endpoint connected directly to a Windows system and advertised as a camera. Projects using embedded boards as conferencing cameras, HDMI-to-USB capture bridges, test rigs, kiosk peripherals, or USB device emulators are more likely to have enabled this feature than conventional desktops and servers.

The CVE data supplied by kernel.org marks Linux versions from 3.10 onward as affected, while identifying five stable-tree fixes and the upstream fix in Linux 7.2-rc5. That broad historical range should not be confused with every distribution package being exploitable in practice: the vulnerable code must be present, the UVC gadget function must be built and enabled, compatible USB device-mode hardware must be used, and a local control application must submit the oversized response.

Patch by fixed commit, not by a generic kernel label​

The CVE record lists backported commits for supported stable lines and names the first fixed releases as Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6. The upstream correction entered the 7.2 release cycle in 7.2-rc5, whose release announcement includes the UVC gadget change under Muhammad Bilal’s contributions.

Administrators should not assume that a distribution kernel carrying a lower-looking version string lacks the repair. Enterprise and long-term-support distributions routinely backport individual stable commits while preserving their own package version format. The right check is the distribution’s security advisory or changelog for CVE-2026-68366, followed by confirmation that the installed kernel package is the remediated build.

For systems maintained from upstream stable sources, the practical remediation is straightforward:

• Upgrade any 6.6-series deployment to 6.6.148 or later.
• Upgrade any 6.12-series deployment to 6.12.101 or later.
• Upgrade any 6.18-series deployment to 6.18.42 or later.
• Upgrade any 7.1-series deployment to 7.1.6 or later.
• Treat Linux 7.2-rc5 as the first upstream pre-release carrying the correction.

If an immediate kernel update is unavailable, disabling the UVC gadget function or unbinding the USB gadget from its device controller removes the reachable path. Restricting access to the userspace service that owns the UVC gadget also limits the chance that a malformed

call can be generated locally.

The concrete takeaway is narrow but actionable: update Linux devices that present themselves as USB cameras. Ordinary Linux machines using USB webcams and Windows PCs receiving the camera feed are outside the vulnerable driver path; embedded UVC-gadget deployments need the patched kernel before they are connected to untrusted USB hosts.