<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/usb/gadget/function, branch linux-5.10.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.10.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.10.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-12-06T21:08:23Z</updated>
<entry>
<title>usb: gadget: f_eem: Fix memory leak in eem_unwrap</title>
<updated>2025-12-06T21:08:23Z</updated>
<author>
<name>Kuen-Han Tsai</name>
</author>
<published>2025-11-03T12:17:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a9985a88b2fc29fbe1657fe8518908e261d6889c'/>
<id>urn:sha1:a9985a88b2fc29fbe1657fe8518908e261d6889c</id>
<content type='text'>
commit e4f5ce990818d37930cd9fb0be29eee0553c59d9 upstream.

The existing code did not handle the failure case of usb_ep_queue in the
command path, potentially leading to memory leaks.

Improve error handling to free all allocated resources on usb_ep_queue
failure. This patch continues to use goto logic for error handling, as the
existing error handling is complex and not easily adaptable to auto-cleanup
helpers.

kmemleak results:
  unreferenced object 0xffffff895a512300 (size 240):
    backtrace:
      slab_post_alloc_hook+0xbc/0x3a4
      kmem_cache_alloc+0x1b4/0x358
      skb_clone+0x90/0xd8
      eem_unwrap+0x1cc/0x36c
  unreferenced object 0xffffff8a157f4000 (size 256):
    backtrace:
      slab_post_alloc_hook+0xbc/0x3a4
      __kmem_cache_alloc_node+0x1b4/0x2dc
      kmalloc_trace+0x48/0x140
      dwc3_gadget_ep_alloc_request+0x58/0x11c
      usb_ep_alloc_request+0x40/0xe4
      eem_unwrap+0x204/0x36c
  unreferenced object 0xffffff8aadbaac00 (size 128):
    backtrace:
      slab_post_alloc_hook+0xbc/0x3a4
      __kmem_cache_alloc_node+0x1b4/0x2dc
      __kmalloc+0x64/0x1a8
      eem_unwrap+0x218/0x36c
  unreferenced object 0xffffff89ccef3500 (size 64):
    backtrace:
      slab_post_alloc_hook+0xbc/0x3a4
      __kmem_cache_alloc_node+0x1b4/0x2dc
      kmalloc_trace+0x48/0x140
      eem_unwrap+0x238/0x36c

Fixes: 4249d6fbc10f ("usb: gadget: eem: fix echo command packet response issue")
Cc: stable@kernel.org
Signed-off-by: Kuen-Han Tsai &lt;khtsai@google.com&gt;
Link: https://patch.msgid.link/20251103121814.1559719-1-khtsai@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_hid: Fix zero length packet transfer</title>
<updated>2025-12-06T21:08:13Z</updated>
<author>
<name>William Wu</name>
</author>
<published>2025-08-26T10:28:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=807f13fd52f2f27aacfd16b739ced5c25072cc88'/>
<id>urn:sha1:807f13fd52f2f27aacfd16b739ced5c25072cc88</id>
<content type='text'>
[ Upstream commit ed6f727c575b1eb8136e744acfd5e7306c9548f6 ]

Set the hid req-&gt;zero flag of ep0/in_ep to true by default,
then the UDC drivers can transfer a zero length packet at
the end if the hid transfer with size divisible to EPs max
packet size according to the USB 2.0 spec.

Signed-off-by: William Wu &lt;william.wu@rock-chips.com&gt;
Link: https://lore.kernel.org/r/1756204087-26111-1-git-send-email-william.wu@rock-chips.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_ncm: Fix MAC assignment NCM ethernet</title>
<updated>2025-12-06T21:08:11Z</updated>
<author>
<name>raub camaioni</name>
</author>
<published>2025-08-15T13:07:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fa24a2584eb8f09d32ea5451ecebc0a7b0e3bb8e'/>
<id>urn:sha1:fa24a2584eb8f09d32ea5451ecebc0a7b0e3bb8e</id>
<content type='text'>
[ Upstream commit 956606bafb5fc6e5968aadcda86fc0037e1d7548 ]

This fix is already present in f_ecm.c and was never
propagated to f_ncm.c

When creating multiple NCM ethernet devices
on a composite usb gadget device
each MAC address on the HOST side will be identical.
Having the same MAC on different network interfaces is bad.

This fix updates the MAC address inside the
ncm_strings_defs global during the ncm_bind call.
This ensures each device has a unique MAC.
In f_ecm.c ecm_string_defs is updated in the same way.

The defunct MAC assignment in ncm_alloc has been removed.

Signed-off-by: raub camaioni &lt;raubcameo@gmail.com&gt;
Link: https://lore.kernel.org/r/20250815131358.1047525-1-raubcameo@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_fs: Fix epfile null pointer access after ep enable.</title>
<updated>2025-12-06T21:08:08Z</updated>
<author>
<name>Owen Gu</name>
</author>
<published>2025-09-15T09:29:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1c0dbd240be3f87cac321b14e17979b7e9cb6a8f'/>
<id>urn:sha1:1c0dbd240be3f87cac321b14e17979b7e9cb6a8f</id>
<content type='text'>
commit cfd6f1a7b42f62523c96d9703ef32b0dbc495ba4 upstream.

A race condition occurs when ffs_func_eps_enable() runs concurrently
with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()
sets ffs-&gt;epfiles to NULL before resetting ffs-&gt;eps_count to 0, leading
to a NULL pointer dereference when accessing epfile-&gt;ep in
ffs_func_eps_enable() after successful usb_ep_enable().

The ffs-&gt;epfiles pointer is set to NULL in both ffs_data_clear() and
ffs_data_close() functions, and its modification is protected by the
spinlock ffs-&gt;eps_lock. And the whole ffs_func_eps_enable() function
is also protected by ffs-&gt;eps_lock.

Thus, add NULL pointer handling for ffs-&gt;epfiles in the
ffs_func_eps_enable() function to fix issues

Signed-off-by: Owen Gu &lt;guhuinan@xiaomi.com&gt;
Link: https://lore.kernel.org/r/20250915092907.17802-1-guhuinan@xiaomi.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: u_serial: Fix race condition in TTY wakeup</title>
<updated>2025-07-17T16:27:57Z</updated>
<author>
<name>Kuen-Han Tsai</name>
</author>
<published>2025-06-17T05:07:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d43657b59f36e88289a6066f15bc9a80df5014eb'/>
<id>urn:sha1:d43657b59f36e88289a6066f15bc9a80df5014eb</id>
<content type='text'>
commit c529c3730bd09115684644e26bf01ecbd7e2c2c9 upstream.

A race condition occurs when gs_start_io() calls either gs_start_rx() or
gs_start_tx(), as those functions briefly drop the port_lock for
usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear
port.tty and port_usb, respectively.

Use the null-safe TTY Port helper function to wake up TTY.

Example
  CPU1:			      CPU2:
  gserial_connect() // lock
  			      gs_close() // await lock
  gs_start_rx()     // unlock
  usb_ep_queue()
  			      gs_close() // lock, reset port.tty and unlock
  gs_start_rx()     // lock
  tty_wakeup()      // NPE

Fixes: 35f95fd7f234 ("TTY: usb/u_serial, use tty from tty_port")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Kuen-Han Tsai &lt;khtsai@google.com&gt;
Reviewed-by: Prashanth K &lt;prashanth.k@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/linux-usb/20240116141801.396398-1-khtsai@google.com/
Link: https://lore.kernel.org/r/20250617050844.1848232-2-khtsai@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: potential integer overflow in usbg_make_tpg()</title>
<updated>2025-07-17T16:27:37Z</updated>
<author>
<name>Chen Yufeng</name>
</author>
<published>2025-04-15T06:58:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=603a83e5fee38a950bfcfb2f36449311fa00a474'/>
<id>urn:sha1:603a83e5fee38a950bfcfb2f36449311fa00a474</id>
<content type='text'>
[ Upstream commit 153874010354d050f62f8ae25cbb960c17633dc5 ]

The variable tpgt in usbg_make_tpg() is defined as unsigned long and is
assigned to tpgt-&gt;tport_tpgt, which is defined as u16. This may cause an
integer overflow when tpgt is greater than USHRT_MAX (65535). I
haven't tried to trigger it myself, but it is possible to trigger it
by calling usbg_make_tpg() with a large value for tpgt.

I modified the type of tpgt to match tpgt-&gt;tport_tpgt and adjusted the
relevant code accordingly.

This patch is similar to commit 59c816c1f24d ("vhost/scsi: potential
memory corruption").

Signed-off-by: Chen Yufeng &lt;chenyufeng@iie.ac.cn&gt;
Link: https://lore.kernel.org/r/20250415065857.1619-1-chenyufeng@iie.ac.cn
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()</title>
<updated>2025-06-27T10:04:20Z</updated>
<author>
<name>Terry Junge</name>
</author>
<published>2025-03-12T22:23:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=41827a2dbdd7880df9881506dee13bc88d4230bb'/>
<id>urn:sha1:41827a2dbdd7880df9881506dee13bc88d4230bb</id>
<content type='text'>
commit fe7f7ac8e0c708446ff017453add769ffc15deed upstream.

Update struct hid_descriptor to better reflect the mandatory and
optional parts of the HID Descriptor as per USB HID 1.11 specification.
Note: the kernel currently does not parse any optional HID class
descriptors, only the mandatory report descriptor.

Update all references to member element desc[0] to rpt_desc.

Add test to verify bLength and bNumDescriptors values are valid.

Replace the for loop with direct access to the mandatory HID class
descriptor member for the report descriptor. This eliminates the
possibility of getting an out-of-bounds fault.

Add a warning message if the HID descriptor contains any unsupported
optional HID class descriptors.

Reported-by: syzbot+c52569baf0c843f35495@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c52569baf0c843f35495
Fixes: f043bfc98c19 ("HID: usbhid: fix out-of-bounds bug")
Cc: stable@vger.kernel.org
Signed-off-by: Terry Junge &lt;linuxhid@cosmicgizmosystems.com&gt;
Reviewed-by: Michael Kelley &lt;mhklinux@outlook.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Terry Junge &lt;linuxhid@cosmicgizmosystems.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: gadget: f_midi: f_midi_complete to call queue_work</title>
<updated>2025-03-13T11:47:28Z</updated>
<author>
<name>Jill Donahue</name>
</author>
<published>2025-02-11T17:48:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1f10923404705a94891e612dff3b75e828a78368'/>
<id>urn:sha1:1f10923404705a94891e612dff3b75e828a78368</id>
<content type='text'>
[ Upstream commit 4ab37fcb42832cdd3e9d5e50653285ca84d6686f ]

When using USB MIDI, a lock is attempted to be acquired twice through a
re-entrant call to f_midi_transmit, causing a deadlock.

Fix it by using queue_work() to schedule the inner f_midi_transmit() via
a high priority work queue from the completion handler.

Link: https://lore.kernel.org/all/CAArt=LjxU0fUZOj06X+5tkeGT+6RbXzpWg1h4t4Fwa_KGVAX6g@mail.gmail.com/
Fixes: d5daf49b58661 ("USB: gadget: midi: add midi function driver")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Jill Donahue &lt;jilliandonahue58@gmail.com&gt;
Link: https://lore.kernel.org/r/20250211174805.1369265-1-jdonahue@fender.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb/gadget: f_midi: Replace tasklet with work</title>
<updated>2025-03-13T11:47:27Z</updated>
<author>
<name>Davidlohr Bueso</name>
</author>
<published>2021-01-11T04:28:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3635523e9b96213969693c320302d536774d8e9b'/>
<id>urn:sha1:3635523e9b96213969693c320302d536774d8e9b</id>
<content type='text'>
[ Upstream commit 8653d71ce3763aedcf3d2331f59beda3fecd79e4 ]

Currently a tasklet is used to transmit input substream buffer
data. However, tasklets have long been deprecated as being too
heavy on the system by running in irq context - and this is not
a performance critical path. If a higher priority process wants
to run, it must wait for the tasklet to finish before doing so.

Deferring work to a workqueue and executing in process context
should be fine considering the callback already does
f_midi_do_transmit() under the transmit_lock and thus changes in
semantics are ok regarding concurrency - tasklets being serialized
against itself.

Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Reviewed-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Acked-by: Felipe Balbi &lt;balbi@kernel.org&gt;
Signed-off-by: Davidlohr Bueso &lt;dbueso@suse.de&gt;
Link: https://lore.kernel.org/r/20210111042855.73289-1-dave@stgolabs.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Stable-dep-of: 4ab37fcb4283 ("USB: gadget: f_midi: f_midi_complete to call queue_work")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_midi: fix MIDI Streaming descriptor lengths</title>
<updated>2025-03-13T11:47:17Z</updated>
<author>
<name>John Keeping</name>
</author>
<published>2025-01-30T19:50:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9f36a89dcb78cb7e37f487b04a16396ac18c0636'/>
<id>urn:sha1:9f36a89dcb78cb7e37f487b04a16396ac18c0636</id>
<content type='text'>
commit da1668997052ed1cb00322e1f3b63702615c9429 upstream.

While the MIDI jacks are configured correctly, and the MIDIStreaming
endpoint descriptors are filled with the correct information,
bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.

This does not matter when the numbers of in and out ports are equal, but
when they differ the host will receive broken descriptors with
uninitialized stack memory leaking into the descriptor for whichever
value is smaller.

The precise meaning of "in" and "out" in the port counts is not clearly
defined and can be confusing.  But elsewhere the driver consistently
uses this to match the USB meaning of IN and OUT viewed from the host,
so that "in" ports send data to the host and "out" ports receive data
from it.

Cc: stable &lt;stable@kernel.org&gt;
Fixes: c8933c3f79568 ("USB: gadget: f_midi: allow a dynamic number of input and output ports")
Signed-off-by: John Keeping &lt;jkeeping@inmusicbrands.com&gt;
Reviewed-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Link: https://lore.kernel.org/r/20250130195035.3883857-1-jkeeping@inmusicbrands.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
