CVE-2026-46228

What it actually does

CVE-2026-46228 is a Linux kernel resource-lifetime flaw in the CH341 USB SPI driver. The driver incorrectly tied device-managed resources to the parent USB device rather than the USB interface that the driver actually binds to. When the driver is unbound, reprobed, deferred during probe, or affected by USB configuration changes without the physical device being disconnected, kernel resources may not be released at the correct time. The practical impact is local denial of service through resource leakage or unstable driver state, potentially degrading system availability on hosts using CH341-based USB SPI adapters.

Why it matters to the business

Systems that rely on CH341 USB SPI hardware can become unstable or unavailable if the affected kernel driver is repeatedly bound and unbound or encounters configuration changes. The risk is most relevant to engineering workstations, embedded Linux devices, industrial systems, hardware programming stations, and lab infrastructure that use CH341 adapters. The vulnerability is not known to be exploited publicly, is not in CISA KEV, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, affected systems should still be patched during normal kernel maintenance because the impact is availability loss.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel and using, or capable of loading, the CH341 USB SPI driver. The attacker then triggers driver lifecycle events such as unbinding and rebinding the CH341 USB interface, causing probe deferral, changing USB configuration, or repeatedly loading and unloading the relevant driver while the device remains connected. Because affected kernels associate managed resources with the wrong USB object lifetime, resources that should be released when the interface driver is unbound may persist or be released at an inappropriate time. Repetition of these events can exhaust kernel memory or destabilize the driver stack, resulting in a denial of service. No evidence currently indicates widespread exploitation, ransomware use, or named threat actor activity for this issue.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the upstream fix for the CH341 SPI driver resource lifetime issue, specifically the patch titled "spi: ch341: fix devres lifetime." Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, or embedded platform maintainer. Where immediate patching is not possible, mitigate by disabling or blacklisting the CH341 SPI driver if the hardware is not required, restricting local access to systems using CH341 adapters, limiting permissions to driver bind/unbind sysfs controls, and avoiding repeated driver reloads or USB configuration changes on production systems.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version and that vendor advisories identify the CH341 SPI lifetime fix as included. On source-built kernels, confirm that the patch "spi: ch341: fix devres lifetime" is present in the kernel source or changelog. Validate exposure by checking whether the CH341 SPI driver is built, loaded, or available as a module, and whether CH341 USB devices are connected. After patching, perform controlled CH341 device connect, disconnect, bind, and unbind testing while monitoring kernel logs and memory consumption to confirm that resources are released cleanly and no leak or driver instability is observed.

Typical attack path

1. Gain local authenticated access to a Linux host with an affected kernel.
2. Identify that a CH341 USB SPI adapter or the CH341 SPI driver is present or loadable.
3. Trigger CH341 driver lifecycle changes, such as unbind/rebind, probe deferral, USB configuration changes, or module reloads.
4. Repeat the lifecycle changes to accumulate leaked resources or force unstable driver state.
5. Cause system degradation, kernel instability, service disruption, or denial of service on workloads dependent on the affected host or device.

How to detect it

To determine whether this was already exploited, review kernel logs, system journals, audit logs, shell history, and endpoint telemetry for repeated manipulation of the CH341 SPI driver or USB driver bind/unbind paths. Focus on systems with CH341 USB SPI adapters attached or the relevant driver loaded. Look for frequent connect/disconnect, bind/unbind, module load/unload, probe deferral, kernel warnings, increasing kernel memory use, out-of-memory events, or unexplained reboots around CH341 activity. Useful log sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald, auditd execve records, command history, EDR process telemetry, and USB device inventory logs. Since no public exploit-specific artifact is known, detection should focus on behavioral evidence of repeated driver lifecycle manipulation followed by resource exhaustion or service disruption.

• ch341
• spi-ch341
• /sys/bus/usb/drivers/ch341/unbind
• /sys/bus/usb/drivers/ch341/bind
• /sys/bus/usb/drivers/spi-ch341/unbind
• /sys/bus/usb/drivers/spi-ch341/bind
• modprobe -r spi-ch341
• rmmod spi-ch341
• modprobe spi-ch341
• USB disconnect
• Out of memory
• oom-killer
• probe deferral

What your security team should do

• Inventory Linux systems that use CH341 USB SPI adapters or include the CH341 SPI driver.
• Prioritize patching for embedded, industrial, lab, manufacturing, and hardware programming systems where local denial of service could disrupt operations.
• Apply the vendor-fixed kernel update that includes the CH341 SPI devres lifetime correction.
• If CH341 functionality is unnecessary, disable or blacklist the affected driver to remove exposure.
• Restrict local shell access and administrative access to systems with attached CH341 hardware.
• Monitor for repeated USB driver unbind/rebind activity, CH341 driver reloads, and kernel memory pressure on exposed systems.
• Because this issue is not KEV-listed, not associated with ransomware, and has low EPSS, handle through risk-based kernel maintenance unless the affected hardware supports critical operations.