[PATCH] xhci: dbc: lock the minor IDR on registration failure

[PATCH] xhci: dbc: lock the minor IDR on registration failure

[Sang-Hoon Choi]

dbc_tty_minors is protected by dbc_tty_minors_lock when entries are
allocated and during normal device removal. The registration error path
removes an entry without taking that lock. Different DbC instances have
separate event work items, so this removal can race with an IDR update
for another instance.

Take the same mutex around the error-path removal.

Fixes: e1ec140f273e ("xhci: dbgtty: use IDR to support several dbc instances.")
Reported-by: Changyul Lee <lcy8047@gmail.com>
Assisted-by: LLM
Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com>
---
Compile-tested the affected object with x86_64 allmodconfig
and W=1 (GCC 13.3.0). Base: mainline 3b7cab693ba2bab63774bf5b988e8a61b2ef0f32.
No hardware testing or runtime failure reproduction was performed.

 drivers/usb/host/xhci-dbgtty.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c
index 3d51e8d82659..2249cc16800c 100644
--- a/drivers/usb/host/xhci-dbgtty.c
+++ b/drivers/usb/host/xhci-dbgtty.c
@@ -535,7 +535,9 @@ static int xhci_dbc_tty_register_device(struct xhci_dbc *dbc)
 err_free_fifo:
 	kfifo_free(&port->port.xmit_fifo);
 err_exit_port:
+	mutex_lock(&dbc_tty_minors_lock);
 	idr_remove(&dbc_tty_minors, port->minor);
+	mutex_unlock(&dbc_tty_minors_lock);
 err_idr:
 	xhci_dbc_tty_exit_port(port);
 

Re: [PATCH] xhci: dbc: lock the minor IDR on registration failure

[Mathias Nyman]

On 10/2/26 22:47, Sang-Hoon Choi wrote:
> dbc_tty_minors is protected by dbc_tty_minors_lock when entries are
> allocated and during normal device removal. The registration error path
> removes an entry without taking that lock. Different DbC instances have
> separate event work items, so this removal can race with an IDR update
> for another instance.
> 
> Take the same mutex around the error-path removal.
> 
> Fixes: e1ec140f273e ("xhci: dbgtty: use IDR to support several dbc instances.")
> Reported-by: Changyul Lee <lcy8047@gmail.com>
> Assisted-by: LLM
> Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com>
> ---
> Compile-tested the affected object with x86_64 allmodconfig
> and W=1 (GCC 13.3.0). Base: mainline 3b7cab693ba2bab63774bf5b988e8a61b2ef0f32.
> No hardware testing or runtime failure reproduction was performed.
> 
>   drivers/usb/host/xhci-dbgtty.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c
> index 3d51e8d82659..2249cc16800c 100644
> --- a/drivers/usb/host/xhci-dbgtty.c
> +++ b/drivers/usb/host/xhci-dbgtty.c
> @@ -535,7 +535,9 @@ static int xhci_dbc_tty_register_device(struct xhci_dbc *dbc)
>   err_free_fifo:
>   	kfifo_free(&port->port.xmit_fifo);
>   err_exit_port:
> +	mutex_lock(&dbc_tty_minors_lock);
>   	idr_remove(&dbc_tty_minors, port->minor);
> +	mutex_unlock(&dbc_tty_minors_lock);
>   err_idr:
>   	xhci_dbc_tty_exit_port(port);
>   

Thanks

Adding to queue

As an additional remark it seems that this issue is a bit theoretical.
We just allocated that id in the same function a few lines earlier (while protected
by the mutex).
The tty port device never got registered or used in this error path, so nothing will
try to use or find anything with this specific id.

I think internal XArray synchronization working underneath IDR can probably manage
idr_find(), idr_alloc() and idr_remove() calls for other ids even if this one is being
removed at the same time, but not 100% sure.

Let me know if you can describe a scenario where current idr_remove() in the error
path without the mutex protection is an issue.

Thanks
Mathias