<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/usb/gadget/function, branch v5.15.208</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.208</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.208'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-18T08:33:38+00:00</updated>
<entry>
<title>usb: gadget: uvc: fix NULL pointer dereference during unbind race</title>
<updated>2026-04-18T08:33:38+00:00</updated>
<author>
<name>Jimmy Hu</name>
<email>hhhuuu@google.com</email>
</author>
<published>2026-04-11T14:09:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d92d1532e05b1b31d36d48765e43bf73d793d19f'/>
<id>urn:sha1:d92d1532e05b1b31d36d48765e43bf73d793d19f</id>
<content type='text'>
[ Upstream commit eba2936bbe6b752a31725a9eb5c674ecbf21ee7d ]

Commit b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanly
shutdown") introduced two stages of synchronization waits totaling 1500ms
in uvc_function_unbind() to prevent several types of kernel panics.
However, this timing-based approach is insufficient during power
management (PM) transitions.

When the PM subsystem starts freezing user space processes, the
wait_event_interruptible_timeout() is aborted early, which allows the
unbind thread to proceed and nullify the gadget pointer
(cdev-&gt;gadget = NULL):

[  814.123447][  T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind()
[  814.178583][ T3173] PM: suspend entry (deep)
[  814.192487][ T3173] Freezing user space processes
[  814.197668][  T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release

When the PM subsystem resumes or aborts the suspend and tasks are
restarted, the V4L2 release path is executed and attempts to access the
already nullified gadget pointer, triggering a kernel panic:

[  814.292597][    C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake
[  814.386727][ T3173] Restarting tasks ...
[  814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030
[  814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4
[  814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94
[  814.404078][ T4558] Call trace:
[  814.404080][ T4558]  usb_gadget_deactivate+0x14/0xf4
[  814.404083][ T4558]  usb_function_deactivate+0x54/0x94
[  814.404087][ T4558]  uvc_function_disconnect+0x1c/0x5c
[  814.404092][ T4558]  uvc_v4l2_release+0x44/0xac
[  814.404095][ T4558]  v4l2_release+0xcc/0x130

Address the race condition and NULL pointer dereference by:

1. State Synchronization (flag + mutex)
Introduce a 'func_unbound' flag in struct uvc_device. This allows
uvc_function_disconnect() to safely skip accessing the nullified
cdev-&gt;gadget pointer. As suggested by Alan Stern, this flag is protected
by a new mutex (uvc-&gt;lock) to ensure proper memory ordering and prevent
instruction reordering or speculative loads. This mutex is also used to
protect 'func_connected' for consistent state management.

2. Explicit Synchronization (completion)
Use a completion to synchronize uvc_function_unbind() with the
uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by
ensuring struct uvc_device is freed after all video device resources
are released.

Fixes: b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanly shutdown")
Cc: stable &lt;stable@kernel.org&gt;
Suggested-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Suggested-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Jimmy Hu &lt;hhhuuu@google.com&gt;
Link: https://patch.msgid.link/20260320065427.1374555-1-hhhuuu@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
[ replaced guard()/scoped_guard() macros ]
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop</title>
<updated>2026-04-18T08:33:38+00:00</updated>
<author>
<name>Kuen-Han Tsai</name>
<email>khtsai@google.com</email>
</author>
<published>2026-04-11T16:31:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e1e7a66584bf0aff3becb73c19fa31527889fc9e'/>
<id>urn:sha1:e1e7a66584bf0aff3becb73c19fa31527889fc9e</id>
<content type='text'>
[ Upstream commit e1eabb072c75681f78312c484ccfffb7430f206e ]

A race condition between gether_disconnect() and eth_stop() leads to a
NULL pointer dereference. Specifically, if eth_stop() is triggered
concurrently while gether_disconnect() is tearing down the endpoints,
eth_stop() attempts to access the cleared endpoint descriptor, causing
the following NPE:

  Unable to handle kernel NULL pointer dereference
  Call trace:
   __dwc3_gadget_ep_enable+0x60/0x788
   dwc3_gadget_ep_enable+0x70/0xe4
   usb_ep_enable+0x60/0x15c
   eth_stop+0xb8/0x108

Because eth_stop() crashes while holding the dev-&gt;lock, the thread
running gether_disconnect() fails to acquire the same lock and spins
forever, resulting in a hardlockup:

  Core - Debugging Information for Hardlockup core(7)
  Call trace:
   queued_spin_lock_slowpath+0x94/0x488
   _raw_spin_lock+0x64/0x6c
   gether_disconnect+0x19c/0x1e8
   ncm_set_alt+0x68/0x1a0
   composite_setup+0x6a0/0xc50

The root cause is that the clearing of dev-&gt;port_usb in
gether_disconnect() is delayed until the end of the function.

Move the clearing of dev-&gt;port_usb to the very beginning of
gether_disconnect() while holding dev-&gt;lock. This cuts off the link
immediately, ensuring eth_stop() will see dev-&gt;port_usb as NULL and
safely bail out.

Fixes: 2b3d942c4878 ("usb ethernet gadget: split out network core")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Kuen-Han Tsai &lt;khtsai@google.com&gt;
Link: https://patch.msgid.link/20260311-gether-disconnect-npe-v1-1-454966adf7c7@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_hid: move list and spinlock inits from bind to alloc</title>
<updated>2026-04-18T08:33:38+00:00</updated>
<author>
<name>Michael Zimmermann</name>
<email>sigmaepsilon92@gmail.com</email>
</author>
<published>2026-04-12T12:00:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=de93e0862169b5539e00c2b9980b93fd80c37c0d'/>
<id>urn:sha1:de93e0862169b5539e00c2b9980b93fd80c37c0d</id>
<content type='text'>
[ Upstream commit 4e0a88254ad59f6c53a34bf5fa241884ec09e8b2 ]

There was an issue when you did the following:
- setup and bind an hid gadget
- open /dev/hidg0
- use the resulting fd in EPOLL_CTL_ADD
- unbind the UDC
- bind the UDC
- use the fd in EPOLL_CTL_DEL

When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported
within remove_wait_queue (via ep_remove_wait_queue). After some
debugging I found out that the queues, which f_hid registers via
poll_wait were the problem. These were initialized using
init_waitqueue_head inside hidg_bind. So effectively, the bind function
re-initialized the queues while there were still items in them.

The solution is to move the initialization from hidg_bind to hidg_alloc
to extend their lifetimes to the lifetime of the function instance.

Additionally, I found many other possibly problematic init calls in the
bind function, which I moved as well.

Signed-off-by: Michael Zimmermann &lt;sigmaepsilon92@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://patch.msgid.link/20260331184844.2388761-1-sigmaepsilon92@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_uac1_legacy: validate control request size</title>
<updated>2026-04-18T08:33:35+00:00</updated>
<author>
<name>Taegu Ha</name>
<email>hataegu0826@gmail.com</email>
</author>
<published>2026-04-01T19:13:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=21b11e8581285c6f10ef43d05df349d445f24273'/>
<id>urn:sha1:21b11e8581285c6f10ef43d05df349d445f24273</id>
<content type='text'>
commit 6e0e34d85cd46ceb37d16054e97a373a32770f6c upstream.

f_audio_complete() copies req-&gt;length bytes into a 4-byte stack
variable:

  u32 data = 0;
  memcpy(&amp;data, req-&gt;buf, req-&gt;length);

req-&gt;length is derived from the host-controlled USB request path,
which can lead to a stack out-of-bounds write.

Validate req-&gt;actual against the expected payload size for the
supported control selectors and decode only the expected amount
of data.

This avoids copying a host-influenced length into a fixed-size
stack object.

Signed-off-by: Taegu Ha &lt;hataegu0826@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://patch.msgid.link/20260401191311.3604898-1-hataegu0826@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_rndis: Protect RNDIS options with mutex</title>
<updated>2026-04-18T08:33:35+00:00</updated>
<author>
<name>Kuen-Han Tsai</name>
<email>khtsai@google.com</email>
</author>
<published>2026-03-20T08:54:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c1b3d5b0acb194efe20fc5864ee03439fa7bd45c'/>
<id>urn:sha1:c1b3d5b0acb194efe20fc5864ee03439fa7bd45c</id>
<content type='text'>
commit 8d8c68b1fc06ece60cf43e1306ff0f4ac121547e upstream.

The class/subclass/protocol options are suspectible to race conditions
as they can be accessed concurrently through configfs.

Use existing mutex to protect these options. This issue was identified
during code inspection.

Fixes: 73517cf49bd4 ("usb: gadget: add RNDIS configfs options for class/subclass/protocol")
Cc: stable@vger.kernel.org
Signed-off-by: Kuen-Han Tsai &lt;khtsai@google.com&gt;
Link: https://patch.msgid.link/20260320-usb-net-lifecycle-v1-2-4886b578161b@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_subset: Fix unbalanced refcnt in geth_free</title>
<updated>2026-04-18T08:33:35+00:00</updated>
<author>
<name>Kuen-Han Tsai</name>
<email>khtsai@google.com</email>
</author>
<published>2026-03-20T08:54:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d7d702407b61e96286a15b6e715572f541a8d41c'/>
<id>urn:sha1:d7d702407b61e96286a15b6e715572f541a8d41c</id>
<content type='text'>
commit caa27923aacd8a5869207842f2ab1657c6c0c7bc upstream.

geth_alloc() increments the reference count, but geth_free() fails to
decrement it. This prevents the configuration of attributes via configfs
after unlinking the function.

Decrement the reference count in geth_free() to ensure proper cleanup.

Fixes: 02832e56f88a ("usb: gadget: f_subset: add configfs support")
Cc: stable@vger.kernel.org
Signed-off-by: Kuen-Han Tsai &lt;khtsai@google.com&gt;
Link: https://patch.msgid.link/20260320-usb-net-lifecycle-v1-1-4886b578161b@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: gadget: f_eem: Fix memory leak in eem_unwrap</title>
<updated>2025-12-06T21:09:35+00:00</updated>
<author>
<name>Kuen-Han Tsai</name>
<email>khtsai@google.com</email>
</author>
<published>2025-11-03T12:17:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5a1628283cd9dccf1e44acfb74e77504f4dc7472'/>
<id>urn:sha1:5a1628283cd9dccf1e44acfb74e77504f4dc7472</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:09:21+00:00</updated>
<author>
<name>William Wu</name>
<email>william.wu@rock-chips.com</email>
</author>
<published>2025-08-26T10:28:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2dc7bcc0b1123bfb6f8e78d76dd7f75b880b4587'/>
<id>urn:sha1:2dc7bcc0b1123bfb6f8e78d76dd7f75b880b4587</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:09:19+00:00</updated>
<author>
<name>raub camaioni</name>
<email>raubcameo@gmail.com</email>
</author>
<published>2025-08-15T13:07:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e14d3af189de740b8ab81ddcd35ddc424e2e2b16'/>
<id>urn:sha1:e14d3af189de740b8ab81ddcd35ddc424e2e2b16</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:09:15+00:00</updated>
<author>
<name>Owen Gu</name>
<email>guhuinan@xiaomi.com</email>
</author>
<published>2025-09-15T09:29:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ec40fba7357df2d36f4c2e2f3b9b1a4fba0a272'/>
<id>urn:sha1:9ec40fba7357df2d36f4c2e2f3b9b1a4fba0a272</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>
</feed>
