mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
@ 2025-09-28 11:07 Cen Zhang
  2025-09-28 11:39 ` Markus Elfring
  0 siblings, 1 reply; 2+ messages in thread
From: Cen Zhang @ 2025-09-28 11:07 UTC (permalink / raw)
  To: Luiz Augusto von Dentz, johan.hedberg, marcel
  Cc: linux-kernel, linux-bluetooth, Cen Zhang

From: Cen Zhang <zzzccc427@gmail.com>

hci_cmd_sync_dequeue_once() does lookup and then cancel
the entry under two separate lock sections. Meanwhile,
hci_cmd_sync_work() can also delete the same entry,
leading to double list_del() and "UAF".

Fix this by holding cmd_sync_work_lock across both
lookup and cancel, so that the entry cannot be removed
concurrently.

Reported-by: Cen Zhang <zzzccc427@gmail.com>
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
 net/bluetooth/hci_sync.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index b6f888d83..f059b19fe 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -862,12 +862,13 @@ bool hci_cmd_sync_dequeue_once(struct hci_dev *hdev,
 			       void *data, hci_cmd_sync_work_destroy_t destroy)
 {
 	struct hci_cmd_sync_work_entry *entry;
-
-	entry = hci_cmd_sync_lookup_entry(hdev, func, data, destroy);
+	mutex_lock(&hdev->cmd_sync_work_lock);
+	entry = _hci_cmd_sync_lookup_entry(hdev, func, data, destroy);
 	if (!entry)
 		return false;
 
-	hci_cmd_sync_cancel_entry(hdev, entry);
+	_hci_cmd_sync_cancel_entry(hdev, entry, -ECANCELED);
+	mutex_unlock(&hdev->cmd_sync_work_lock);
 
 	return true;
 }
-- 
2.43.0


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
  2025-09-28 11:07 [PATCH] Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once Cen Zhang
@ 2025-09-28 11:39 ` Markus Elfring
  0 siblings, 0 replies; 2+ messages in thread
From: Markus Elfring @ 2025-09-28 11:39 UTC (permalink / raw)
  To: Cen Zhang, linux-bluetooth
  Cc: Cen Zhang, LKML, Johan Hedberg, Luiz Von Dentz, Marcel Holtmann

> hci_cmd_sync_dequeue_once() does lookup and then cancel
> the entry under two separate lock sections. Meanwhile,
> hci_cmd_sync_work() can also delete the same entry,
> leading to double list_del() and "UAF".

You may occasionally put more than 55 characters into text lines
of such a change description.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.17-rc7#n658


> Fix this by holding cmd_sync_work_lock across both
> lookup and cancel, so that the entry cannot be removed
> concurrently.
…
> +++ b/net/bluetooth/hci_sync.c
> @@ -862,12 +862,13 @@ bool hci_cmd_sync_dequeue_once(struct hci_dev *hdev,
…

* How do you think about to add any tags (like “Fixes” and “Cc”) accordingly?

* Under which circumstances would you become interested to apply a call
  like “scoped_guard(mutex, &hdev->cmd_sync_work_lock)”?
  https://elixir.bootlin.com/linux/v6.17-rc7/source/include/linux/mutex.h#L228


Regards,
Markus

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-09-28 11:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-09-28 11:07 [PATCH] Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once Cen Zhang
2025-09-28 11:39 ` Markus Elfring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®