linux-kernel - Re: [PATCH] Bluetooth: fix use-after-free in hci_conn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260210100901.2769-1-hdanton@sina.com>
Date: Tue, 10 Feb 2026 18:08:59 +0800
From: Hillf Danton <hdanton@...a.com>
To: kawada <youjingxiaogao2@...il.com>
Cc: linux-bluetooth@...r.kernel.org,
	luiz.dentz@...il.com,
	marcel@...tmann.org,
	johan.hedberg@...il.com,
	linux-kernel@...r.kernel.org,
	syzbot+3609b9b48e68e1fe47fd@...kaller.appspotmail.com
Subject: Re: [PATCH] Bluetooth: fix use-after-free in hci_conn_drop

[ 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.