Hi Luiz, Thanks for your patch! It not only addresses the TOCTOU issue we discussed but may also fix another bug I reported (https://lore.kernel.org/linux-bluetooth/CAFRLqsWWMnrZ6y8MUMUSK=tmAb3r8_jfSwqforOoR8_-=XgX7g@xxxxxxxxxxxxxx/T/#u). I will test it soon to confirm. Thanks again for the great work. Best regards, Cen Zhang Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> 于2025年9月13日周六 02:29写道： > > Hi Cen, > > On Fri, Sep 12, 2025 at 11:59 AM cen zhang <zzzccc427@xxxxxxxxx> wrote: > > > > Hi Luiz, > > > > Thank you for your quick response and the important clarification > > about hci_cmd_sync_dequeue(). > > > > You are absolutely correct - I was indeed referring to the TOCTOU > > problem in pending_find(), not the -ECANCELED check. The > > hci_cmd_sync_dequeue() call in cmd_complete_rsp() is a crucial detail > > that I initially overlooked in my analysis. > > > > After examining the code more carefully, I can see that while > > hci_cmd_sync_dequeue() does attempt to remove pending sync commands > > from the queue, but it cannot prevent the race condition we're seeing. > > The fundamental issue is that hci_cmd_sync_dequeue() can only remove > > work items that are still queued, but cannot stop work items that are > > already executing or about to execute their completion callbacks. > > > > The race window occurs when: > > 1. mgmt_set_powered_complete() is about to execute (work item has been dequeued) > > 2. mgmt_index_removed() -> mgmt_pending_foreach() -> cmd_complete_rsp() executes > > 3. hci_cmd_sync_dequeue() removes queued items but cannot affect the > > already-running callback > > 4. mgmt_pending_free() frees the cmd object > > 5. mgmt_set_powered_complete() still executes and accesses freed cmd->param > > > > I am sorry that I haven't get a reliable reproducer from syzkaller for > > this bug may be due to it is timing-sensitive. > > Let's try to fix all instances then, since apparently there is more > than one cmd with this pattern, please test with the attached patch.
