CVE-2026-46103

What it actually does

This vulnerability is a Linux kernel availability issue in the USB CAN ucan driver. The driver incorrectly ties a device-managed control message buffer to the parent USB device rather than the USB interface that the driver actually binds to. When the driver is unbound, reprobed, probe-deferred, or reconfigured without the physical USB device being disconnected, the buffer lifetime can be wrong and resources may not be released as intended. Repeated trigger conditions can cause kernel memory/resource leakage and may ultimately degrade system stability or lead to denial of service. Exploitation requires local access with sufficient privileges to influence USB driver binding/unbinding or attach/manipulate a relevant USB CAN device; it does not provide confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels with USB CAN adapters supported by the ucan driver may become unstable if the driver is repeatedly unbound or reprobed. In operational technology, automotive, lab, fleet, manufacturing, or embedded environments that rely on CAN bus interfaces, this can interrupt monitoring, diagnostics, testing, or control workflows. The issue is not currently listed in CISA KEV, has very low EPSS, and has no reported mature public exploitation, so broad internet-scale risk is low; however, affected systems with local users, exposed device-management workflows, or untrusted physical USB access should still be patched during the next kernel maintenance cycle.

How an attack unfolds

An attacker must first obtain local access to a Linux system or physical/logical access to a relevant USB CAN device path. They then cause the ucan USB CAN driver to bind and unbind, reprobe, or encounter configuration changes without fully disconnecting the parent USB device. Because the affected kernel version associates the control message buffer lifetime with the wrong device object, driver unbind events may fail to release resources correctly. By repeating this cycle, the attacker can consume kernel memory or related resources. Over time, this can result in memory pressure, allocation failures, degraded performance, driver malfunction, or a system-level denial of service requiring service restart or reboot.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the ucan driver devres lifetime issue. Because no exact fixed package versions were provided, use distribution or appliance vendor advisories to identify the corrected kernel package for each affected platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the ucan driver if USB CAN functionality is not required, restricting local shell access, limiting access to USB device management interfaces, preventing untrusted USB device attachment, and monitoring for repeated bind/unbind activity. On systems where CAN functionality is business-critical, test the updated kernel and ucan driver with representative USB CAN adapters before broad rollout.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the ucan driver devres lifetime fix. Validate package status using the operating system vendor's kernel advisory, changelog, or source package notes referencing the ucan driver lifetime/resource-release fix. On Linux hosts, check whether the ucan module is present or loaded using commands such as `lsmod | grep ucan`, `modinfo ucan`, and kernel package inventory tooling. After patching, reboot into the fixed kernel and confirm `uname -a` and package manager output show the corrected kernel. In a controlled test environment, repeatedly bind and unbind the ucan USB interface and confirm memory usage remains stable and no kernel warnings, allocation failures, or resource leaks appear in `dmesg` or the system journal.

Typical attack path

1. Gain local access to a Linux system, or obtain physical/logical ability to connect and manipulate a USB CAN adapter handled by the ucan driver.
2. Identify that the ucan driver is loaded or can be loaded for the attached USB CAN interface.
3. Repeatedly trigger driver bind/unbind, reprobe, probe deferral, or USB configuration changes without fully removing the parent USB device.
4. Cause unreleased control message buffers or related resources to accumulate due to the incorrect devres lifetime.
5. Drive the host into resource exhaustion, degraded kernel stability, CAN interface failure, or denial of service.

How to detect it

To assess whether this may have been exploited, review host telemetry rather than relying on network indicators. Primary sources are kernel logs, `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, audit logs for sysfs writes, and endpoint telemetry that records module loading or USB device events. Look for repeated ucan driver bind/unbind cycles, USB CAN device resets, rapid creation/removal of CAN network interfaces, probe deferral messages, kernel memory allocation failures, out-of-memory activity, or unexplained host instability correlated with USB CAN activity. If auditd or EDR captures command-line activity, search for writes to USB driver `bind` or `unbind` sysfs nodes and repeated use of tools that manipulate USB devices or kernel modules. Because this is a resource-lifetime bug, there may be no durable artifact after reboot; absence of logs does not prove absence of exploitation.

• ucan
• lsmod | grep ucan
• modinfo ucan
• /sys/bus/usb/drivers/ucan/bind
• /sys/bus/usb/drivers/ucan/unbind
• /sys/bus/usb/drivers/*/unbind
• /sys/bus/usb/drivers/*/bind
• echo * > /sys/bus/usb/drivers/ucan/unbind
• echo * > /sys/bus/usb/drivers/ucan/bind
• usbcore: deregistering interface driver ucan
• usbcore: registered new interface driver ucan
• ucan: probe
• ucan: disconnect
• probe deferral
• Out of memory
• page allocation failure
• Memory allocation failure
• oom-killer
• can%d
• can0
• can1

What your security team should do

• Inventory Linux systems that use USB CAN adapters or load the ucan kernel module.
• Prioritize patching systems where untrusted users have local access, where USB ports are physically accessible, or where CAN interfaces support critical operations.
• Apply the fixed vendor kernel and reboot into the corrected version; verify the active running kernel, not only the installed package version.
• If USB CAN is not required, disable or blacklist the ucan module until patching is complete.
• Restrict permissions for users and automation that can bind, unbind, or reconfigure USB drivers through sysfs or device-management tools.
• Monitor kernel logs for repeated ucan bind/unbind activity, memory allocation failures, USB reset loops, or CAN interface instability.
• For embedded or appliance-like deployments, obtain patched firmware or kernel images from the device vendor and schedule operationally safe maintenance windows.