* [PATCH] usb: gadget: uvc: Fix deadlock in uvcg_extension_bm_controls_store
@ 2026-11-05 5:39 Saad Varshani
2026-11-05 6:05 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Saad Varshani @ 2026-11-05 5:39 UTC (permalink / raw)
To: nkapron, gregkh
Cc: linux-usb, linux-kernel, Saad Varshani,
syzbot+300213c2b5b55c0244f4
Removed su_mutex locking in the function uvcg_extension_bm_controls_store.
Done this due to the deadlock caused by the mutex conflict in
fs/configfs_write_iter. Validated commit with the C repro provided by
syzbot.No other conficts observed.
Reported-by: syzbot+300213c2b5b55c0244f4@syzkaller.appspotmail.com
Closes: https://syzbot.org/bug?extid=300213c2b5b55c0244f4
Signed-off-by: Saad Varshani <varshanisaad@gmail.com>
---
drivers/usb/gadget/function/uvc_configfs.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/gadget/function/uvc_configfs.c b/drivers/usb/gadget/function/uvc_configfs.c
index 70a1415ea401..78588366f656 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -1114,16 +1114,12 @@ static ssize_t uvcg_extension_bm_controls_show(struct config_item *item,
static ssize_t uvcg_extension_bm_controls_store(struct config_item *item,
const char *page, size_t len)
{
- struct config_group *group = to_config_group(item->ci_parent);
- struct mutex *su_mutex = &group->cg_subsys->su_mutex;
struct uvcg_extension *xu = to_uvcg_extension(item);
struct config_item *opts_item;
struct f_uvc_opts *opts;
u8 *bm_controls, *iter;
int ret, n = 0;
- mutex_lock(su_mutex);
-
opts_item = item->ci_parent->ci_parent->ci_parent;
opts = to_f_uvc_opts(opts_item);
@@ -1157,7 +1153,6 @@ static ssize_t uvcg_extension_bm_controls_store(struct config_item *item,
unlock:
mutex_unlock(&opts->lock);
- mutex_unlock(su_mutex);
return ret;
}
--
2.55.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] usb: gadget: uvc: Fix deadlock in uvcg_extension_bm_controls_store
2026-11-05 5:39 [PATCH] usb: gadget: uvc: Fix deadlock in uvcg_extension_bm_controls_store Saad Varshani
@ 2026-11-05 6:05 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-11-05 6:05 UTC (permalink / raw)
To: Saad Varshani; +Cc: linux-usb
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] usb: gadget: uvc: incomplete su_mutex deadlock fix across sibling configfs attributes
--
commit 352b1b2da8cde195be417fe376d9490d718f3b87
Author: Saad Varshani <varshanisaad@gmail.com>
usb: gadget: uvc: Fix deadlock in uvcg_extension_bm_controls_store
This commit removes the acquisition of group->cg_subsys->su_mutex from
uvcg_extension_bm_controls_store() to avoid a circular locking dependency
reported by syzbot in configfs_write_iter().
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c b/drivers/usb/gadget/function/uvc_configfs.c
> index 70a1415ea4014..78588366f656f 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -1114,16 +1114,12 @@ static ssize_t uvcg_extension_bm_controls_show(struct config_item *item,
> static ssize_t uvcg_extension_bm_controls_store(struct config_item *item,
> const char *page, size_t len)
> {
> - struct config_group *group = to_config_group(item->ci_parent);
> - struct mutex *su_mutex = &group->cg_subsys->su_mutex;
> struct uvcg_extension *xu = to_uvcg_extension(item);
> struct config_item *opts_item;
> struct f_uvc_opts *opts;
> u8 *bm_controls, *iter;
> int ret, n = 0;
>
> - mutex_lock(su_mutex);
> -
> opts_item = item->ci_parent->ci_parent->ci_parent;
> opts = to_f_uvc_opts(opts_item);
>
> @@ -1157,7 +1153,6 @@ static ssize_t uvcg_extension_bm_controls_store(struct config_item *item,
>
> unlock:
> mutex_unlock(&opts->lock);
> - mutex_unlock(su_mutex);
[Severity: High]
Does removing su_mutex only from uvcg_extension_bm_controls_store() leave the
exact same deadlock present in all sibling configfs attribute callbacks in
drivers/usb/gadget/function/uvc_configfs.c?
When configfs_write_iter() -> flush_write_buffer() or configfs_read_iter() ->
fill_read_buffer() invokes an attribute callback, it already holds
buffer->mutex and down_read(&frag->frag_sem), which prevents configfs_rmdir()
from unlinking the item or its ci_parent hierarchy.
However, the sibling store and show callbacks on struct uvcg_extension still
acquire group->cg_subsys->su_mutex before opts->lock in the same way:
drivers/usb/gadget/function/uvc_configfs.c:uvcg_extension_ba_source_id_store() {
struct config_group *group = to_config_group(item->ci_parent);
struct mutex *su_mutex = &group->cg_subsys->su_mutex;
...
mutex_lock(su_mutex);
opts_item = item->ci_parent->ci_parent->ci_parent;
opts = to_f_uvc_opts(opts_item);
mutex_lock(&opts->lock);
}
The same locking pattern remains in uvcg_extension_b_control_size_store(),
uvcg_extension_b_nr_in_pins_store(), uvcg_extension_b_num_controls_store(),
uvcg_extension_guid_extension_code_store(), uvcg_extension_bm_controls_show(),
uvcg_extension_ba_source_id_show(), uvcg_extension_guid_extension_code_show(),
and the other configfs attribute show/store callbacks throughout
drivers/usb/gadget/function/uvc_configfs.c (such as
uvcg_default_processing_bm_controls_store(),
uvcg_default_camera_bm_controls_store(), and
uvcg_frame_dw_frame_interval_store()).
Should su_mutex be removed consistently across these configfs attribute
callbacks, and could the commit message also describe the lock dependency
chain and why traversing item->ci_parent is safe without su_mutex?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105053900.20082-1-varshanisaad@gmail.com?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-11-05 6:05 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-05 5:39 [PATCH] usb: gadget: uvc: Fix deadlock in uvcg_extension_bm_controls_store Saad Varshani
2026-11-05 6:05 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox