CVE-2026-68369

What it actually does

Infinite loop in printer_read() caused by reusing the same variable for requested copy size and bytes actually copied; when copy_to_user() returns the full size on failure, len/buf/current_rx_bytes/current_rx_buf remain unchanged while RX data exists and the user buffer stays unwritable.

Why it matters to the business

Denial of service against USB gadget printer functionality on Linux systems, potentially causing hangs or high CPU usage until the affected process is killed or the system is rebooted; low immediate risk given minimal EPSS and no known exploitation.

How an attack unfolds

An attacker with local access to a USB gadget printer device triggers repeated reads when RX data is queued but the user buffer cannot be written; each failed copy_to_user iteration leaves loop state unchanged, sustaining the infinite loop without external network or remote steps required.

How to fix it

Update the Linux kernel to a version containing the fix that tracks copied length separately and returns -EFAULT or partial bytes on no-progress iterations; apply vendor-supplied kernel updates as they become available.

How to confirm the fix worked

Confirm kernel source contains the corrected printer_read logic that separates copy-size tracking; test by forcing copy_to_user failures and verifying the loop terminates with an error return instead of repeating indefinitely.

Typical attack path

1. Obtain local access to a Linux system exposing the USB gadget printer interface
2. Ensure RX data is available in the driver buffer
3. Provide a user-space buffer that copy_to_user cannot write to
4. Invoke read operations that hit the faulty loop condition
5. Observe sustained CPU usage or process hang with no forward progress

How to detect it

Search kernel or system logs for repeated printer_read entries without progress, monitor for single-threaded CPU saturation in usb_gadget or printer-related kernel threads, and inspect process state for tasks stuck inside the USB gadget read path.

What your security team should do

• Apply kernel updates containing the printer_read fix at the next scheduled maintenance window given low current EPSS
• Monitor systems exposing USB gadget interfaces for unexpected CPU spikes in kernel threads
• Limit exposure of the printer gadget driver to only trusted local processes where feasible