The Linux kernel received a targeted repair that closes a robustness hole in the gs_usb CAN-over-USB driver: CVE-2025-68307 fixes improper handling of failed bulk URBs in gs_usb_xmit_callback, a defect that could silently consume transmit URBs and eventually halt CAN transmission on affected systems.
Background / Overview
The affected code lives in the in-tree Linux kernel CAN subsystem’s USB driver, commonly referred to as
gs_usb (drivers/net/can/usb/gs_usb.c). The driver implements CAN-over-USB adapters: when the kernel transmits CAN frames, it issues USB bulk URBs (USB Request Blocks). The xmit callback (gs_usb_xmit_callback is responsible for cleaning up when a URB completes — whether successfully or with an error.
The vulnerability, summarized by standard trackers, is a cleanup omission: when a transmit URB fails, the driver did not perform the same cleanup steps that it executes on success. Concretely, failed URBs were not accounted for in netdev statistics, the per-frame echo bookkeeping (echo_skb) was not released, the driver’s context for that URB was not freed, and the transmit queue was not woken. Over time, each uncleaned failure reduced the pool of available URBs by one and could lead to a complete cessation of transmission when the pool was exhausted. This behavior is described in the public vulnerability records and confirmed by upstream kernel change notes. This is an availability and reliability bug that is triggered by failed USB bulk transfers. It is not a classic memory-safety exploit (like an out-of-bounds read or a use-after-free), but the practical consequences in embedded, automotive, industrial or other CAN-reliant deployments are significant:
lost throughput, stalled CAN bus transmission, and degraded device performance until the driver or system is repaired or rebooted. Public trackers classify the attack vector as local (an attacker or faulty device must cause URB failures) and the immediate impact as availability.
Why this matters for CAN users and integrators
CAN is widely used in industrial control, automotive subsystems, and embedded telemetry. In many deployments, a CAN adapter is the sole or primary communications channel to a device or subsystem. A driver-level fault that silently drains transmit resources can:
- Reduce throughput and increase frame latency in normal operation.
- Produce intermittent failures that are difficult to attribute (they may look like hardware glitches or transient USB bus problems).
- Cause complete transmission stoppage once the driver’s URB pool is exhausted, potentially halting dependent subsystems.
- Increase operational risk for remote systems because the trigger is local but often requires only a single misbehaving USB device or repeated transmission errors to manifest.
These are practical availability and reliability impacts — high priority for organizations that rely on CAN for control or monitoring.
Technical anatomy — what went wrong
At a high level, the gs_usb driver manages a small pool of transmit URBs. For each transmitted CAN frame the driver:
- allocates/uses an URB,
- attaches a context structure that holds bookkeeping (including a pointer to the original skb used for echoing and accounting),
- submits the URB to the USB core, and
- expects the URB’s completion callback to clean up resources and release any per-frame slots so subsequent frames can be transmitted.
The bug arises when an URB completes with an error. Instead of handling error completion the same way it handles success completion, the faulty code path omitted several essential steps:
- it did not increment the appropriate netdev statistics (tx_errors),
- it did not mark the echo_skb / echo slot as free so the net subsystem could reuse it,
- it did not free the driver’s per-URB context and update accounting,
- it did not wake the transmit queue (netif_wake_queue to allow more traffic.
The net effect: every failed URB consumed a transmit slot forever (until reboot or module reload). When enough slots were consumed, the driver had no transmit URBs available and transmission stopped. The fix adds the missing cleanup steps to the error path so failed URBs perform the same accounting and resource release as successful ones. This change is small, surgical, and focused on correctness.
Affected versions and distribution impact
Public vulnerability trackers and package advisories indicate:
- The issue is an in-tree Linux kernel fix. Patch references and stable-kernel commit IDs are available in the tracked references for the CVE record. Distributions will or already have mapped those upstream commits into their kernel packages on differing schedules.
- Tracking tools show kernels built from upstream commits between older kernel series (starting from long-available 3.x-era tree) up to specific stable snapshots were affected, and that fixed commits were pushed into the stable trees. The vulnerability data aggregated by security services lists affected kernels as those that do not include the fix commits. Operators should treat their kernel package version and the distribution’s security advisory as authoritative for whether a given system is patched.
In practice, the remediation model looks like this:
- Mainline and stable kernel trees received the small fix; you will find it referenced by specific commit hashes in the kernel-stable repositories.
- Vendor and distribution packages (Debian, Ubuntu, SUSE, Red Hat, etc. will include the fix according to their own cadence. Some vendors may backport the small patch into older kernel branches; others will require upgrading the kernel package to a more recent release that contains the upstream fix.
- Embedded vendors and OEMs that ship custom or forked kernels typically have the longest patch tails; they must explicitly backport the change into their tree.
Operators must consult their distro or vendor advisories and kernel package changelogs to confirm the fix is present before declaring hosts remediated. Where an advisory is not immediately published, checking the distribution changelog for the kernel package or the presence of the upstream commit IDs is the most reliable verification method.
Exploitability and attacker model
This defect is fundamentally a local availability bug: it requires the attacker or faulty device to cause repeated URB failures. Realistic attack or trigger scenarios include:
- A malicious or compromised USB-to-CAN adapter that intentionally fails bulk transfers or abuses USB-level conditions to provoke repeated errors.
- A buggy firmware inside an adapter that frequently causes URB error completions.
- Environmental or hardware issues on the USB bus (electrical noise, poor cables, intermittent connectors) that produce repeated USB transfer errors in the field.
- In virtualized environments, malicious or misconfigured guests or host passthrough controllers can present problematic device behaviors that affect the host driver.
Because the vector is local and requires control or influence over the attached device or the USB transport, the probability of remote exploitation over a network alone is extremely low. However, in multi-tenant or physically accessible environments (lab benches, kiosks, development machines or test systems), an untrusted USB device can be enough to trigger the failure. Trackers and scoring services reflect this: EPSS and exploitation telemetry are low, and public advisories treat the immediate impact as availability rather than remote code execution.
The upstream fix — scope and rationale
The upstream correction is intentionally minimal:
ensure the error path executes the same release/accounting operations as the success path. That means:
- Increase netdev statistics counters when an URB completes in error (so tx_errors reflect the condition).
- Free or mark the echo skb/slot as available so the network stack can reuse it.
- Free the driver’s per-URB context structure and update accounting counters.
- Wake the send queue so netstack can continue trying to send frames.
These changes restore invariants in the driver state machine and prevent a single hardware failure from permanently consuming a transmit slot. Small, surgical repairs like this are preferred in kernel maintenance because they are easy to audit and backport and carry a low risk of introducing regressions. The kernel stable commits that implement the fix are referenced in the public CVE metadata and by distribution advisories.
Practical mitigation and remediation steps
Operators should follow a prioritized, practical approach.
- Immediate triage (minutes)
- Identify systems using gs_usb: check whether your kernel builds include the driver and whether the module is loaded (uname -r; lsmod | grep gs_usb).
- If a host does not require the CAN-over-USB adapter or the driver, consider unloading or blacklisting the module as a temporary mitigation: modprobe -r gs_usb (note: this disables CAN-over-USB adapters).
- Restrict access to physical USB ports on high-risk hosts; enforce device allowlists with tools such as USBGuard to prevent untrusted devices from attaching.
- Patch (hours–days)
- Apply your distribution or vendor kernel update that contains the upstream fix. Reboot is required for kernel patches.
- For embedded appliances or vendor images, request explicit confirmation from the vendor that their image includes the upstream fix or a backport.
- Validate (post-patch)
- Reproduce a representative transmit workload in a lab and confirm that repeated URB errors no longer reduce available URBs or stall transmission.
- Search kernel logs for residual traces: dmesg and journalctl -k may show URB completion errors, tx queue stalls, or netdev stat anomalies prior to patch; those should stop after remediation.
- For managed fleets, automate detection: add SIEM/EDR rules that alert on repeated tx_errors in the relevant netdev interface or on persistent device-specific transmit stalls.
- Compensating controls when patching is delayed
- Disable USB passthrough in virtual machines where untrusted tenants can attach devices.
- Enforce stricter physical controls on USB access in production and test labs.
- Use monitoring to detect and alert on growing counts of netdev tx_errors for the affected interface(s).
These steps reflect standard practice for kernel driver robustness fixes: patch, reboot, validate, and tighten device access during patch windows.
Hunting and detection tips
Successful detection and triage are often based on kernel logs and network statistics.
- Monitor netdev stats for interfaces backed by gs_usb (e.g., ip -s link show <ifname> or /proc/net/dev) and alert on a rising tx_errors count.
- Check kernel logs (dmesg, journalctl -k) for URB completion errors referencing the CAN USB device or for messages that indicate netif_stop_queue/netif_wake_queue imbalance or queues that are not being woken.
- For forensic deep-dive, capture dmesg and vmcore at the time of the anomaly and correlate with USB attach/detach events and device resets.
These indicators help distinguish driver-level resource leakage from hardware flakiness or higher-level application issues.
Risk analysis — strengths and residual concerns
Strengths of the fix
- The repair is small and low-risk. It restores missing cleanup and accounting rather than redesigning driver behavior, so it is easy to backport and audit.
- Upstream maintainers accepted the change into stable kernel trees; distribution packages are expected to follow their normal release processes.
Residual risks and operational caveats
- The long tail of embedded and OEM kernels: many automotive, industrial, and appliance images ship vendor-supplied kernels that are forked from upstream. Those vendors may lag in backporting the fix. Devices with long maintenance cycles or strict change control will remain exposed until the vendor supplies an update.
- The vulnerability is local: although network-only exposure is unlikely, devices in physically accessible locations (kiosks, field service vehicles, labs) remain at elevated risk if untrusted attachments are possible.
- Detection and forensics for intermittent URB failures can be tricky; operators may see symptoms only as degraded throughput or occasional loss, not an obvious kernel oops.
Similar historical context: device-parsing and USB driver defects are a recurring source of kernel reliability bugs. Previous CVEs in USB and wireless drivers have followed the same pattern — small missing checks or cleanup steps sometimes produced panics or resource leaks that were fixed with tight, surgical patches. A recent example of a buffer-length check omission in a Realtek USB Wi‑Fi driver produced kernel panics and was fixed in an equally minimal way; the operational guidance for that issue was similar: patch quickly and restrict untrusted devices where patching is delayed.
Verification and cross-checks
Administrators and packagers should verify remediation via at least two independent signals:
- Distribution/vendor advisory or package changelog that explicitly references CVE-2025-68307 or includes the upstream stable commit IDs.
- Confirm the kernel package running on the host includes the fix either by matching commit IDs in the kernel source tree used to build the package or by checking the package changelog entry that documents the backport.
Public vulnerability trackers list the upstream commits associated with the fix; operators can use those commit hashes to match their kernel trees or vendor-provided source packages. If vendor documentation is ambiguous, request an explicit attestation from the vendor confirming the backport.
Clear, actionable checklist (short)
- Inventory: identify machines using CAN-over-USB adapters and confirm whether gs_usb is present/loaded.
- Patch: apply distro/vendor kernel updates that include the upstream fix; reboot hosts.
- Short-term mitigation: if patching is delayed and the device is not needed, unload/blacklist gs_usb; enforce USB device allowlists.
- Monitor: add alerts for rising tx_errors on CAN interfaces, USB errors in kernel logs, and transmit queue stalls.
- Vendor engagement: for embedded OEM images, request explicit confirmation that the backport is included and obtain a remediated firmware/kernel image.
Conclusion
CVE-2025-68307 is a pragmatic, high-impact reliability defect in the Linux kernel’s gs_usb CAN driver: a small omission in the URB error path could silently leak transmit resources and bring CAN transmission to a stop. The upstream fix is direct and low-risk — add the missing cleanup and accounting steps for failed URBs — but the operational urgency depends on deployment context. Organizations that rely on CAN-over-USB adapters in production, embedded, automotive, or industrial settings should prioritize kernel updates and reduce exposure to untrusted USB attachments while supplier and distribution patches are rolled out. Verification should rely on both vendor/distro advisories and kernel commit-level checks to ensure the repair is present in deployed images.
Source: MSRC
Security Update Guide - Microsoft Security Response Center