CVE-2025-68352

What it actually does

Out-of-bounds read from a transmit buffer of size trans->len and potential out-of-bounds write into a 32-byte driver buffer when copying data for a CH341 SPI transfer that includes a one-byte command header.

Why it matters to the business

Local attackers with access to affected systems can trigger memory corruption in the Linux kernel USB-SPI driver, leading to crashes, privilege escalation, or data leakage on devices using CH341 chips; the issue affects embedded and general-purpose Linux deployments with downstream package updates required.

How an attack unfolds

An attacker with local access supplies a crafted SPI transfer request to the ch341 driver; the driver miscalculates the copy length as min(32, trans->len + 1) and copies too many bytes from the source buffer and into the driver buffer, causing memory corruption that can be leveraged for further exploitation.

How to fix it

Update to a fixed kernel commit (cad6c0fd6f3c0e76a1f75df4bce3b08a13f08974) or package version (vault-k8s-fips 1.4.2-r8 or later) that changes the copy length to len-1 bytes; rebuild and reboot systems using the CH341 driver; apply vendor kernel updates promptly.

How to confirm the fix worked

Confirm the driver source contains the corrected copy of (len-1) bytes; verify the running kernel reports the fixed commit hash; test SPI transfers with the CH341 device to ensure no crashes occur on boundary lengths.

Typical attack path

1. Obtain local execution or device access on a system using the ch341 SPI driver
2. Craft and submit a SPI transfer structure with trans->len chosen to trigger len == 32
3. Trigger the ch341_transfer_one path to perform the oversized copy
4. Exploit the resulting out-of-bounds read/write for kernel memory corruption or code execution

How to detect it

Review kernel logs for oops, page faults, or slab corruption messages involving ch341_transfer_one or spi transfers; inspect USB device attach events for CH341 chips followed by abnormal SPI activity; no public exploit artifacts are known.

What your security team should do

• Apply the listed kernel or package updates immediately on all systems exposing the ch341 driver
• Audit device inventories for CH341-based USB-SPI hardware and prioritize patching
• Monitor kernel update channels for backports to older stable trees
• Restrict unprivileged local access where CH341 hardware is present until patches are deployed