linux-stable.git/drivers/usb/misc, branch v6.6.63

Revert "usb: yurex: Replace snprintf() with the safer scnprintf() variant"

2024-10-17T13:24:33+00:00

commit 71c717cd8a2e180126932cc6851ff21c1d04d69a upstream.

This reverts commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035.

This patch leads to passing 0 to simple_read_from_buffer()
as a fifth argument, turning the read method into a nop.
The change is fundamentally flawed, as it breaks the driver.

Signed-off-by: Oliver Neukum 
Cc: stable 
Link: https://lore.kernel.org/r/20241007094004.242122-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman

usb: yurex: Fix inconsistent locking bug in yurex_read()

2024-10-04T14:30:04+00:00

commit e7d3b9f28654dbfce7e09f8028210489adaf6a33 upstream.

Unlock before returning on the error path.

Fixes: 86b20af11e84 ("usb: yurex: Replace snprintf() with the safer scnprintf() variant")
Reported-by: Dan Carpenter 
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/r/202312170252.3udgrIcP-lkp@intel.com/
Signed-off-by: Harshit Mogalapalli 
Link: https://lore.kernel.org/r/20231219063639.450994-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Greg Kroah-Hartman

USB: misc: yurex: fix race between read and write

2024-10-04T14:29:57+00:00

[ Upstream commit 93907620b308609c72ba4b95b09a6aa2658bb553 ]

The write code path touches the bbu member in a non atomic manner
without taking the spinlock. Fix it.

The bug is as old as the driver.

Signed-off-by: Oliver Neukum 
CC: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240912132126.1034743-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: yurex: Replace snprintf() with the safer scnprintf() variant

2024-10-04T14:29:57+00:00

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ]

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Whilst we're at it, let's define some magic numbers to increase
readability and ease of maintenance.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Tomoki Sekiyama 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org
Signed-off-by: Greg Kroah-Hartman 
Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write")
Signed-off-by: Sasha Levin

USB: misc: cypress_cy7c63: check for short transfer

2024-10-04T14:29:50+00:00

commit 49cd2f4d747eeb3050b76245a7f72aa99dbd3310 upstream.

As we process the second byte of a control transfer, transfers
of less than 2 bytes must be discarded.

This bug is as old as the driver.

SIgned-off-by: Oliver Neukum 
CC: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240912125449.1030536-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman

USB: appledisplay: close race between probe and completion handler

2024-10-04T14:29:50+00:00

commit 8265d06b7794493d82c5c21a12d7ba43eccc30cb upstream.

There is a small window during probing when IO is running
but the backlight is not registered. Processing events
during that time will crash. The completion handler
needs to check for a backlight before scheduling work.

The bug is as old as the driver.

Signed-off-by: Oliver Neukum 
CC: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240912123317.1026049-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman

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

2024-06-27T11:49:04+00:00

[ Upstream commit 3295f1b866bfbcabd625511968e8a5c541f9ab32 ]

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 
Signed-off-by: Sasha Levin

usb: misc: onboard-hub: add support for Microchip USB5744

2023-12-03T06:33:08+00:00

commit 6972b38ca05235f6142715db7062ecc87a422e22 upstream.

Add support for the Microchip USB5744 USB3.0 and USB2.0 Hub.

The Microchip USB5744 supports two power supplies, one for 1V2 and one
for 3V3. According to the datasheet there is no need for a delay between
power on and reset, so this value is set to 0.

Signed-off-by: Stefan Eichenberger 
Signed-off-by: Francesco Dolcini 
Cc: stable 
Acked-by: Matthias Kaehlcke 
Link: https://lore.kernel.org/r/20231113145921.30104-3-francesco@dolcini.it
Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_hub: add support for Microchip USB2412 USB 2.0 hub

2023-10-02T14:15:22+00:00

The USB2412 is a 2-Port USB 2.0 hub controller that provides a reset pin
and a single 3v3 powre source, which makes it suitable to be controlled
by the onboard_hub driver.

This hub has the same reset timings as USB2514/2517 and the same
onboard hub specific-data can be reused for USB2412.

Signed-off-by: Javier Carrasco 
Cc: stable 
Acked-by: Matthias Kaehlcke 
Link: https://lore.kernel.org/r/20230911-topic-2412_onboard_hub-v1-1-7704181ddfff@wolfvision.net
Signed-off-by: Greg Kroah-Hartman

USB: misc: Remove unused include file usb_u132.h

2023-08-08T08:36:46+00:00

Since commit 8be174835f07 ("usb: ftdi-elan: Delete driver") this include file
is not used anymore, so can remove it.

Signed-off-by: Yue Haibing 
Link: https://lore.kernel.org/r/20230807141128.39092-1-yuehaibing@huawei.com
Signed-off-by: Greg Kroah-Hartman