CVE-2026-64338: USB: misc: uss720: unregister parport on probe failure
In the Linux kernel, the following vulnerability has been resolved:
USB: misc: uss720: unregister parport on probe failure
uss720probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get1284register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered.
Leaving the port registered is more than a private allocation leak: parportregisterport() has already reserved a parport number and registered the parport bus device, while pp->privatedata still points at the private data that the common error path is about to release.
Undo the pre-announce registration in the get1284register() failure branch before jumping to the common private-data cleanup path. Clear priv->pp first, matching the disconnect path and avoiding a stale pointer in the private data.
This issue was identified during our ongoing static-analysis research while reviewing kernel code.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the get_1284_register() failure path, unregister the parport before entering the common private-data cleanup path, undoing the pre-announce registration and preventing a stale registered parport device.
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel's uss720 USB miscellaneous driver may be exposed when probing an adapter requires reading the 1284 register and that read fails. The description specifically identifies unsupported Belkin F5U002 adapters as a case involved in this detection path.
What conditions are required to trigger the flaw?
The uss720 driver must register a parport during probe, then get_1284_register() must fail. This is a local attack surface in the provided CVSS vector and requires low privileges; no user interaction is required.
What is the impact if the vulnerable error path is reached?
The parport remains registered after the driver's private data and USB device reference are released. This leaves a registered parport bus device and a stale private_data pointer, and can cause a high availability impact.
What should be done if patching cannot be applied immediately?
The provided data identifies the affected path as the uss720 driver probe failure path. Avoiding use of that driver or the affected adapter/probe scenario is the only mitigation supported by the available information; a patch is available.