Re: [PATCH] Bluetooth: fix use-after-free in hci_conn_drop

[Hillf Danton]

[ hm... top reply looks no good ]

On Tue, 10 Feb 2026 15:08:12 +0900 Masahiro Kawada wrote:
> > but the race still exists after this patch.
> 
> I agree that the TOCTOU issue remains. I looked into all the functions
> that can be called as entry->destroy in hci_cmd_sync_work where the
> second argument (data) is used as hci_conn*. I found five such
> functions across two files:
> 
> In hci_sync.c:
>   - create_le_conn_complete
>   - create_pa_complete
>   - create_big_complete
>   - le_read_features_complete
> 
> In hci_conn.c:
>   - create_big_complete (separate static function)
> 
> Of these, create_le_conn_complete and create_pa_complete already use
> hci_dev_lock, which effectively prevents this TOCTOU issue.
> 
> The remaining three are vulnerable:
>   - create_big_complete in hci_sync.c calls hci_conn_valid without
>     holding hci_dev_lock (TOCTOU)
>   - le_read_features_complete calls hci_conn_drop with no validity
>     check at all
>   - create_big_complete in hci_conn.c calls hci_connect_cfm and
>     hci_conn_del with no validity check at all
> 
> Given this, I believe the following set of patches would be
> appropriate:
> 
> 1. Reorder hci_cmd_sync_dequeue before hci_conn_cleanup in
>    hci_conn_del
> 2. Wrap all three vulnerable callbacks with hci_dev_lock and
>    hci_conn_valid, following the same pattern used by
>    create_le_conn_complete and create_pa_complete
> 
> If this approach sounds reasonable, I will prepare updated patches.
>
Better not before spotting the reason why conn->refcnt failed to make the
entry->destroy callback safe, given the complexity of the race.