CVE-2026-64338

What it actually does

This is a Linux kernel use-after-free condition in the USB uss720 parallel-port adapter driver. During device probe, the driver registers a parport device before completing hardware capability checks. If reading the IEEE 1284 register fails, the failure path releases driver-private memory and drops the USB device reference but leaves the parport device registered with a stale pointer to freed private data. Later interaction with the registered parport device can dereference freed kernel memory, potentially causing kernel memory corruption, a kernel crash, or in harder-to-achieve cases local privilege escalation. Practical exploitation likely requires the ability to attach or emulate a malicious or malformed USB parallel adapter that triggers the failing probe path.

Why it matters to the business

Systems that load the affected Linux uss720 USB parallel-port driver may be vulnerable to crashes or possible kernel-level compromise when exposed to a malicious or faulty USB device. The operational risk is highest for workstations, kiosks, industrial systems, lab systems, and servers where untrusted USB devices can be attached or where USB device pass-through is allowed. Public exploitation indicators are currently low: the issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score, but kernel flaws involving physical or emulated devices should still be addressed through routine kernel updates and USB access controls.

How an attack unfolds

An attacker first needs a way to present a crafted USB device to an affected Linux system, such as physical access, a malicious USB peripheral, a compromised USB device, or a virtualized USB pass-through path. The device must be recognized by the uss720 driver and then cause get_1284_register() to fail after parport_register_port() has already registered the parport device. Because the vulnerable error path frees the driver's private data without unregistering the parport, the kernel retains a registered parport object that references freed memory. The attacker then attempts to trigger later parport interaction or device cleanup paths that dereference the stale pointer. The most likely visible result is a kernel oops, panic, or denial of service; a highly capable attacker may attempt heap grooming and repeated attach/detach cycles to turn the use-after-free into controlled kernel memory corruption.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the uss720 driver, specifically the change that unregisters the parport on get_1284_register() probe failure and clears priv->pp before the common cleanup path. If a vendor distribution kernel is used, apply the relevant vendor security update rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the uss720 module if USB-to-parallel adapters are not required, restricting physical USB access, disabling USB device pass-through from untrusted contexts, and enforcing USB device allowlisting. Example mitigations include adding the module to a modprobe blacklist and rebuilding initramfs where applicable, but these should be tested first to avoid disrupting legitimate parallel-port adapter use.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for this issue or by reviewing the uss720 driver source to ensure the get_1284_register() failure path unregisters the previously registered parport and clears the private parport pointer before freeing private data. Check whether the uss720 module is present or loaded using standard kernel module inventory commands, and confirm whether systems actually require USB parallel-port support. For exposure validation, review dmesg, journal, and kernel logs for uss720 and parport activity, especially probe failures followed by kernel oops, panic, KASAN, or slab-use-after-free messages. In controlled testing only, a KASAN-enabled kernel and a fault-injection or malformed USB device test can be used to confirm that failed probe cleanup no longer leaves a registered stale parport object.

Typical attack path

1. Gain the ability to attach or emulate a USB device to the target Linux system.
2. Present a USB parallel-port adapter or crafted USB device that binds to the uss720 driver.
3. Trigger the probe sequence so the driver registers a parport device.
4. Cause the IEEE 1284 register read to fail during probe.
5. Rely on the vulnerable error path to free driver-private data while leaving the parport registered.
6. Trigger subsequent parport access, cleanup, or enumeration that dereferences the stale private_data pointer.
7. Cause a kernel crash or attempt controlled kernel memory corruption for privilege escalation.

How to detect it

To determine whether exploitation or triggering may have occurred, review kernel log sources such as dmesg, journald kernel facility logs, /var/log/kern.log, /var/log/messages, crash dumps, and KASAN reports. Look for USB device insertion events that bind to the uss720 driver, parport registration immediately followed by probe or register-read failures, and then kernel oops, panic, general protection fault, slab corruption, or KASAN use-after-free messages. Correlate timestamps with physical USB activity, USB/IP or virtualization pass-through events, and repeated attach/detach cycles. Because no public exploit-specific payload indicators are known and the issue is not in KEV, detection should focus on behavioral evidence: unexpected uss720 module loading, unexpected USB parallel-port adapters, repeated failed probes, and memory-safety crash signatures involving uss720 or parport code paths.

• uss720
• parport
• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• general protection fault
• kernel BUG at drivers/usb/misc/uss720
• drivers/usb/misc/uss720
• /lib/modules/*/kernel/drivers/usb/misc/uss720.ko
• Belkin F5U002
• get_1284_register
• parport_register_port

What your security team should do

• Prioritize patching Linux systems where untrusted users can attach USB devices, where USB pass-through is enabled, or where the uss720 driver is loaded.
• Inventory systems for the uss720 kernel module and for use of USB-to-parallel adapters; focus remediation on systems where the module is present or auto-loadable.
• If the driver is not needed, blacklist or otherwise disable uss720 as a compensating control until patched kernels are deployed.
• Restrict physical USB access and enforce USB device allowlisting on workstations, kiosks, industrial endpoints, and shared systems.
• Monitor kernel logs for uss720, parport, KASAN use-after-free, kernel oops, or panic events associated with USB device insertion or removal.
• Treat crashes occurring immediately after USB parallel-port device activity as potentially security-relevant and preserve logs and crash dumps for analysis.
• Track vendor advisories for the exact fixed kernel package versions applicable to each Linux distribution in use.