xhci: dbc: lock the minor IDR on registration failure

PATCH In review Sang-Hoon Choi 2 participants 2 messages Oct 2 – Oct 5

Subsystems (2)

USB USB xHCI driver

lore

Share & tools

lore

Sang-Hoon Choi

author

2026-10-02 19:59 UTC #0 lore raw

PATCH 1/1 xhci: dbc: lock the minor IDR on registration failure

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 <[email protected]>

Assisted-by LLM

Signed-off-by Sang-Hoon Choi <[email protected]>

---
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(+)

drivers/usb/host/xhci-dbgtty.c +2 -0

index 3d51e8d82659..2249cc16800c 100644
@@ -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);

Mathias Nyman

2026-10-05 15:28 UTC #1 lore raw

Quoted 25 lines · 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 <[email protected]>
Assisted-by LLM
Signed-off-by Sang-Hoon Choi <[email protected]>
---
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(+)
drivers/usb/host/xhci-dbgtty.c +0 -0
index 3d51e8d82659..2249cc16800c 100644

drivers/usb/host/xhci-dbgtty.c static int xhci_dbc_tty_register_device(struct xhci_dbc *dbc) · line 543

Quoted 9 lines

drivers/usb/host/xhci-dbgtty.c +2 -0

@@ -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