Linux systems that use USB-connected CAN bus adapters face a newly patched vulnerability that can quietly choke off all data transmission, potentially disabling industrial machinery, automotive subsystems, or embedded controllers. A flaw in the gs_usb kernel driver—responsible for translating CAN frames over USB—allowed repeated transfer errors to permanently consume transmit resources until the interface fell dead, with no warning and no automatic recovery. Microsoft’s Security Response Center published CVE-2025-68307 for the issue, and the Linux kernel community has already merged a surgical fix into stable trees.

What the Patch Actually Fixes

The gs_usb driver relies on USB Bulk Request Blocks (URBs) to send CAN frames. Each transmission allocates an URB, hands it to the USB stack, and expects a completion callback to clean up and release the slot. In the old code, the callback for successful URBs properly freed the buffer, updated network statistics, released the echo slot (used for loopback confirmation in CAN), and woke the transmit queue so more frames could flow. The callback for failed URBs? It did nothing.

No error counters were incremented. The memory allocated for the URB context leaked. The echo slot was never released, so the CAN stack believed a transmission was still in-flight even when it had clearly failed. Most critically, the driver never told the network layer it was ready to send more data. After a single failed URB, that transmit slot was gone forever. After a few dozen failures—easily triggered by a dodgy USB cable, a flaky adapter, or electrical noise—the driver ran out of URBs entirely. Transmission stopped. No crash, no kernel oops, just a silent, permanent stall until the system was rebooted or the module reloaded.

The fix, committed upstream, mirrors the success path in the error path. Failed URBs now increment tx_errors, free their dynamic state, release the echo slot, and call netif_wake_queue so the network stack can resume. It’s a few lines of code that prevent what could be hours of downtime in a factory or a dead dashboard in a vehicle.

Who Should Care—And Why

This isn’t a remote-code-execution bug. It doesn’t let an attacker take over your kernel. But for anyone whose Linux machine talks to the physical world over a CAN bus, it’s an operational grenade with a delayed fuse.

Hobbyists and makers using a Raspberry Pi with a CAN HAT to monitor a car’s OBD-II port or run a home automation protocol might see intermittent hang-ups or mysteriously unresponsive adapters. The fix prevents those “just reboot it” moments.

System integrators and industrial operators face a sharper risk. CAN is the backbone of many factory floors, connecting PLCs, motor drives, and sensors. A stalled CAN interface can stop production lines or mask safety alarms. In a warehouse where robots coordinate over CAN, a single USB error from a vibrating cable could, over minutes or hours, freeze the entire fleet. Because the failure is silent—no panic, no obvious error message—operators might misdiagnose the fault as a hardware failure and replace expensive equipment before checking the kernel version.

Automotive mechanics and fleet managers use USB-CAN tools for diagnostics and firmware flashing. A stall mid-flash can brick an electronic control unit. In a field service laptop that gets plugged into vehicles all day, the risk of encountering a noisy USB port or a counterfeit adapter is real.

The common thread: if you have a physical USB port and you connect a CAN adapter to it, you’re vulnerable until patched. The attack vector is local—someone (or some faulty device) must generate repeated URB errors—but on a shop floor, a kiosk, or a delivery truck, that’s hardly an exotic scenario.

A Bug Years in the Making

The gs_usb driver has been part of the Linux kernel since the early 3.x days, and the erroneous error-handling logic appears to be original. For over a decade, every failed URB silently leaked a transmit slot. Why wasn’t it caught sooner? CAN isn’t a mainstream consumer protocol like Wi-Fi; its user base is deep but narrow. And intermittent transmission failures often get chalked up to flaky hardware rather than a kernel bug. The vulnerability finally received a CVE after someone—likely a developer staring at a stalled CAN bus—traced the leak back to the missing cleanup code.

Tracking data from public vulnerability databases shows the flaw was present in kernels up to specific stable snapshots, with the fix first landing in mainline and then backported to long-term stable branches. Because the patch is so small and isolated, maintainers were able to merge it without destabilizing other parts of the USB or CAN subsystems.

Update Now: Where to Get the Fix

For most users, recovery is straightforward: update your kernel.

  1. Identify if you’re using gs_usb. Run lsmod | grep gs_usb. If the module is listed, you’re affected. Run uname -r to see your current kernel version.
  2. Check your distribution’s security advisory. Major distros will ship the fix in their regular kernel updates. Look for CVE-2025-68307 in the changelog, or search for the upstream commit IDs (available in the CVE record on the MITRE or NVD sites).
    - For Debian and Ubuntu: sudo apt update && sudo apt upgrade and then reboot.
    - For Fedora: sudo dnf upgrade kernel*.
    - For RHEL and CentOS Stream: sudo yum update kernel.
    - For SUSE: sudo zypper up kernel-default.
  3. For custom or embedded kernels: If you compile your own kernel from source, pull the latest stable tree or apply the patch manually. The commit IDs are in the CVE details.

If you can’t patch immediately, you can temporarily disable the driver if no CAN devices are in use:
- sudo modprobe -r gs_usb
- To make it persistent across reboots, blacklist the module (echo “blacklist gs_usb” | sudo tee /etc/modprobe.d/disable-gs_usb.conf).

Note: this will break any active CAN-over-USB communication, so only do it as a stopgap if you don’t need those adapters.

Protecting Your Systems While You Wait

Patching every system takes time—especially in industrial environments where change windows are measured in months, not days. In the interim:

  • Restrict physical USB access. On critical machines, lock down ports or use port blockers. If an attacker can’t plug in a malicious device, they can’t trigger the bug.
  • Deploy USB device allowlisting. Tools like USBGuard can be configured to reject any device whose vendor/product ID isn’t on a pre‑approved list, blocking unreliable or unknown adapters.
  • Monitor for early symptoms. Rising tx_errors on your CAN interface (check with ip -s link show <interface> or by reading /sys/class/net/<interface>/statistics/tx_errors) can indicate the leak is accumulating. URB error messages in dmesg or journalctl -k may also appear. Set up a SIEM or monitoring script to alert on these counters before the queue starves.
  • Isolate susceptible hosts. If you run virtual machines that pass through USB devices, disable USB passthrough for untrusted guests.

The Long Tail of Embedded Systems

The real headache isn’t the server farm; it’s the thousands of embedded devices that run customized kernels and never get updated. Automotive ECUs, medical instruments, building automation controllers, and field-deployed IoT gateways often use CAN and may rely on the gs_usb driver under a vendor-supplied Linux build. Many of these devices have no regular update mechanism, and the organizations that own them may not even know the kernel version inside.

If you operate such equipment, now is the time to contact your vendor and demand a patched firmware image. Ask for explicit confirmation that CVE-2025-68307 has been backported, not just a generic “security update.” The patch is trivial to apply—there’s no architectural overhaul—so any vendor with access to their kernel source tree can do it quickly. The bottleneck is usually the validation and release process, not the engineering.

For systems that cannot be patched (legacy, end-of-life, or locked-down), concentrate on the compensating controls: physical security, USB lockdown, and aggressive monitoring. The vulnerability will remain present, but you can make it very hard to exploit.

The CVE has not been seen in the wild as of this writing, and public exploit proofs are unavailable. But the attack surface is as simple as it gets—any USB port—and the payoff for an adversary in a targeted industrial environment could be significant. Patch early, and if you can’t patch, isolate.