kernel/linux.git/drivers/usb/misc/uss720.c, branch v7.1.7

USB: misc: uss720: unregister parport on probe failure

2026-07-18T14:55:37+00:00

commit b4ecbdc4f8830f5586c4a5cfc384c00f20f8f8b3 upstream. uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() 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: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is about to release. Undo the pre-announce registration in the get_1284_register() 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. Fixes: 3295f1b866bf ("usb: misc: uss720: check for incompatible versions of the Belkin F5U002") Cc: stable Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Alex Henrie Link: https://patch.msgid.link/20260706151049.63470-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman

Merge 7.0-rc4 into usb-next

2026-03-16T10:50:48+00:00

We need the USB fixes in this branch as well to build on top of Signed-off-by: Greg Kroah-Hartman

usb: misc: uss720: properly clean up reference in uss720_probe()

2026-03-11T15:17:12+00:00

If get_1284_register() fails, the usb device reference count is incorrect and needs to be properly dropped before returning. That will happen when the kref is dropped in the call to destroy_priv(), so jump to that error path instead of returning directly. Cc: stable Assisted-by: gkh_clanker_2000 Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2026022342-smokiness-stove-d792@gregkh Signed-off-by: Greg Kroah-Hartman

usb: uss720: unify error handling in probe

2026-03-11T14:00:11+00:00

There is a lot of code duplication. Unify it. Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20260304160734.1742200-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

usb: misc: uss720: check for incompatible versions of the Belkin F5U002

2024-04-04T15:07:48+00:00

The incompatible device in my possession has a sticker that says "F5U002 Rev 2" and "P80453-B", and lsusb identifies it as "050d:0002 Belkin Components IEEE-1284 Controller". There is a bug report from 2007 from Michael Trausch who was seeing the exact same errors that I saw in 2024 trying to use this cable. Link: https://lore.kernel.org/all/46DE5830.9060401@trausch.us/ Signed-off-by: Alex Henrie Link: https://lore.kernel.org/r/20240326150723.99939-5-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: misc: uss720: add support for another variant of the Belkin F5U002

2024-04-04T15:07:48+00:00

This device is a gray USB parallel port adapter with "F5U002" imprinted on the plastic and a sticker that says both "F5U002" and "P80453-A". It's identified in lsusb as "05ab:1001 In-System Design BAYI Printer Class Support". It's subtly different from the other gray cable I have that has "F5U002 Rev 2" and "P80453-B" on its sticker and device ID 050d:0002. The uss720 driver appears to work flawlessly with this device, although the device evidently does not support ECP. Signed-off-by: Alex Henrie Link: https://lore.kernel.org/r/20240326150723.99939-4-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: misc: uss720: document the names of the compatible devices

2024-04-04T15:07:48+00:00

Information about 04b8:0002 and 05ab:0002 is from commit e3cb7bde9a6a ("USB: misc: uss720: more vendor/product ID's", 2018-03-20). The rest are from . Signed-off-by: Alex Henrie Link: https://lore.kernel.org/r/20240326150723.99939-3-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: misc: uss720: point pp->dev to usbdev->dev

2024-04-04T15:07:48+00:00

This avoids a "fix this legacy no-device port driver" warning from parport_announce_port in drivers/parport/share.c. The parport driver now requires a pointer to the device struct. Signed-off-by: Alex Henrie Acked-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20240326150723.99939-2-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman