[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9b865b1f-fd7f-4378-a512-2c67dfff675f@web.de>
Date: Sun, 28 Sep 2025 13:39:03 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Cen Zhang <zzzccc427@...il.com>, linux-bluetooth@...r.kernel.org
Cc: Cen Zhang <zzzccc427@....com>, LKML <linux-kernel@...r.kernel.org>,
Johan Hedberg <johan.hedberg@...il.com>,
Luiz Von Dentz <luiz.dentz@...il.com>, Marcel Holtmann <marcel@...tmann.org>
Subject: Re: [PATCH] Bluetooth: hci_sync: fix race in
hci_cmd_sync_dequeue_once
> 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
Powered by blists - more mailing lists