CVE-2026-68369: Linux USB Printer Gadget DoS Fixed

The National Vulnerability Database published the record on August 10, 2026, based on kernel.org’s advisory data. The important operational detail is that this is not a bug in the ordinary Linux USB printer driver used when a PC connects to a physical printer. It is in

, the code used when a Linux device presents itself to another machine as a USB printer.

For Windows administrators, that distinction rules out the usual desktop and print-server fleet. A Windows PC or Windows Server host is not affected by this Linux-kernel CVE. The relevant scenario is a Linux appliance, embedded board, thin client, development device, or purpose-built peripheral that is connected over USB to a Windows computer and advertises itself as a printer.

The loop is triggered by a failed copy into local userspace​

The fault sits in

, the gadget driver’s read path for data received from the USB host. The function moves received printer data into the memory buffer supplied by the local Linux process servicing the printer gadget.

Before the fix, the code reused one variable for two different meanings: the amount it asked to copy and the amount actually copied. That is unsafe because Linux’s

returns the number of bytes it could not copy, not the number it successfully transferred.

When

fails completely, the driver calculates that no progress was made. But it also leaves the input length, output-buffer pointer, and current receive-buffer state untouched. If USB receive data remains available and the local process keeps providing an unwritable destination buffer, the function can go around the same loop indefinitely.

The patch separates requested-copy length from completed-copy length. When an iteration cannot copy any bytes, the corrected code returns

; if an earlier iteration already copied some data, it returns the amount successfully transferred instead. In other words, the repair turns an endless retry into the normal Linux error behavior expected when a process passes a bad userspace pointer.

This is a liveness failure, not a memory-corruption fix. The published CVE description does not claim arbitrary code execution, kernel memory disclosure, privilege escalation, or an out-of-bounds access. The documented outcome is a loop that can consume CPU and leave the printer-function read path stuck.

USB printer gadget mode is the exposure boundary​

Linux has two similarly named but fundamentally different printer components. The common

driver, built under

, lets a Linux computer use an attached USB printer. CVE-2026-68369 does not affect that host-side driver.

The affected component is commonly enabled through

, the USB gadget printer function. Kernel documentation and the Linux Kernel Driver Database describe it as a channel between a USB host and a userspace program running the print engine. That program reads and writes

.

That makes the affected deployment model specific:

• A Linux device must have USB device/peripheral capability, rather than only ordinary USB host ports.
• The USB gadget printer function must be built, loaded, or configured into a gadget.
• The gadget must be activated against a USB Device Controller.
• A local process must open and read the resulting /dev/g_printer* device.
• Received USB data must be available when that process attempts a read into memory that the kernel cannot write.

A Raspberry Pi Zero-class device configured as a USB printer, an ARM board with a USB Device Controller, an industrial controller, a kiosk peripheral, or a custom embedded print appliance are more plausible targets than a conventional Linux workstation. Many x86 servers and laptops have no usable USB gadget controller at all, even though they run an affected kernel version.

The CVE record lists Linux versions beginning with 4.1 as affected, subject to the stable-tree fixes. That long version span should not be read as evidence that every machine running those kernels is exposed. The vulnerable source file may exist in a kernel tree, but it is inert when the USB gadget printer feature is absent or never configured.

A USB-connected Windows machine is not enough to trigger it alone​

The CVE language could be misread as a malicious USB host being able to lock up any Linux system configured as a printer. The code path imposes an additional local condition: the process reading

must provide an invalid or otherwise unwritable userspace buffer.

A connected host can supply printer data, fulfilling the receive-data half of the condition. It does not choose the virtual memory address handed to

by the Linux printer-gadget service. An external Windows host therefore cannot independently create the exact failure merely by sending a print job or malformed printer payload.

That changes the risk assessment. This is not comparable to a USB parser flaw where a hostile peripheral can attack a host kernel simply by being plugged in. Instead, it is a local error-handling flaw in a specialized service path, with USB data present as a prerequisite.

There are still credible operational consequences. A defective or compromised local print-engine process could deliberately issue reads with bad buffer addresses once data arrives. In an appliance where the service runs with elevated privileges or is responsible for a critical USB-connected workflow, the endless loop can pin CPU time and prevent normal receive handling. Depending on the surrounding service design, it may also hold the gadget printer I/O mutex and block other work in that function.

The scope of impact will therefore depend more on device-node permissions and the service architecture than on the printer connected at the other end of the cable. A

node accessible only to a tightly confined service represents a different threat model from one exposed to untrusted local users or containers.

Fixed versions matter more than the CVE publication date​

The NVD entry was published on August 10, but its affected-version data identifies the first fixed releases across the maintained stable lines:

That timing is significant for patch management. The record is a late vulnerability catalog entry for a fix that had already landed in stable kernels; it does not necessarily mean distributors began receiving the code only on August 10. Administrators should check the distribution’s kernel changelog and package backport status rather than treating the upstream version number as the sole test.

Kernel.org’s CVE data ties the issue to five stable commits, reflecting backports across the supported trees. The NVD record currently has no CVSS v3, CVSS v4, CWE classification, or NIST severity assessment. It also supplies no exploit narrative, attack vector, or evidence of exploitation in the wild.

No independent security outlet had published a separate exploitation report at the time of publication. That absence does not eliminate risk, but it supports treating this as a targeted reliability and local-denial-of-service remediation rather than an emergency remote-compromise event.

What Linux appliance operators should check​

First, establish whether the affected function is even present. On systems that retain their build configuration, check for

or related printer-gadget settings in the running kernel’s config file. Then look for active device nodes such as

and for configured gadget functions beneath

.

Do not confuse the presence of CUPS, a network printer queue, a USB printer connected to a Linux PC, or the

module with exposure to this CVE. Those facts alone do not activate

.

If a device does operate in USB printer-gadget mode, move to a vendor kernel package containing the stable backport or to Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, or later in the applicable series. Where an immediate kernel update is unavailable, disabling the printer gadget function or preventing untrusted processes from accessing

removes the vulnerable execution path.

The concrete consequence is straightforward: Linux USB printer emulators should update their kernel or disable that gadget function; ordinary Windows systems, standard Linux print servers, and Linux PCs that merely connect to USB printers do not need a response to CVE-2026-68369.