* Re: [PATCH] Bluetooth: hci_event: fix OOB read and infinite loop in hci_le_create_big_complete_evt
2026-03-31 5:50 [PATCH] Bluetooth: hci_event: fix OOB read and infinite loop in hci_le_create_big_complete_evt hkbinbin
@ 2026-03-31 13:36 ` Luiz Augusto von Dentz
2026-03-31 14:13 ` [PATCH v2] Bluetooth: hci_event: fix OOB read " hkbinbin
2026-03-31 14:13 ` hkbinbin
2 siblings, 0 replies; 4+ messages in thread
From: Luiz Augusto von Dentz @ 2026-03-31 13:36 UTC (permalink / raw)
To: hkbinbin; +Cc: marcel, gregkh, linux-bluetooth, linux-kernel, stable
Hi Hkbinbin,
On Tue, Mar 31, 2026 at 1:50 AM hkbinbin <hkbinbinbin@gmail.com> wrote:
>
> hci_le_create_big_complete_evt() iterates over BT_BOUND connections
> for a BIG handle using a while loop, accessing ev->bis_handle[i++]
> on each iteration. However, there is no check that i < ev->num_bis
> before the array access.
>
> When a controller sends a LE_Create_BIG_Complete event with num_bis=0
> while BT_BOUND connections exist for that BIG handle, the loop reads
> beyond the valid bis_handle[] entries into adjacent heap memory.
> Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX
> (0x0EFF), hci_conn_set_handle() rejects them and the connection
> remains in BT_BOUND state. The same connection is then found again
> by hci_conn_hash_lookup_big_state(), creating an infinite loop with
> hci_dev_lock held that blocks all Bluetooth operations:
>
> Bluetooth: hci0: Invalid handle: 0x6b6b > 0x0eff
> Bluetooth: hci0: Invalid handle: 0x6b6b > 0x0eff
> ... (repeats ~177 times)
> Bluetooth: hci0: Opcode 0x2040 failed: -110
> Bluetooth: hci0: command 0x2040 tx timeout
>
> The value 0x6b6b is the KASAN slab free poison byte (0x6b),
> confirming reads of freed/uninitialized heap memory.
>
> Fix this by adding a bounds check on i against ev->num_bis before
> accessing the array. Connections beyond the reported count are
> cleaned up with HCI_ERROR_UNSPECIFIED to prevent the infinite loop.
>
> Fixes: a0bfde167b50 ("Bluetooth: ISO: Add support for connecting multiple BISes")
> Cc: stable@vger.kernel.org
> Signed-off-by: hkbinbin <hkbinbinbin@gmail.com>
> ---
> net/bluetooth/hci_event.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 286529d2e554..ebd7ae75b133 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -7085,6 +7085,12 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
> continue;
> }
>
> + if (i >= ev->num_bis) {
> + hci_connect_cfm(conn, HCI_ERROR_UNSPECIFIED);
> + hci_conn_del(conn);
> + continue;
> + }
https://sashiko.dev/#/patchset/20260331055032.1883139-1-hkbinbinbin%40gmail.com
Actually we might want to consider that all BISes failed if something
like this happens, so perhaps we should break and terminate if i !=
ev->num_bis
> if (hci_conn_set_handle(conn,
> __le16_to_cpu(ev->bis_handle[i++])))
> continue;
> --
> 2.51.0
>
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH v2] Bluetooth: hci_event: fix OOB read in hci_le_create_big_complete_evt
2026-03-31 5:50 [PATCH] Bluetooth: hci_event: fix OOB read and infinite loop in hci_le_create_big_complete_evt hkbinbin
2026-03-31 13:36 ` Luiz Augusto von Dentz
@ 2026-03-31 14:13 ` hkbinbin
2026-03-31 14:13 ` hkbinbin
2 siblings, 0 replies; 4+ messages in thread
From: hkbinbin @ 2026-03-31 14:13 UTC (permalink / raw)
To: marcel, luiz.dentz
Cc: gregkh, linux-bluetooth, linux-kernel, stable, hkbinbin
hci_le_create_big_complete_evt() iterates over BT_BOUND connections for
a BIG handle using a while loop, accessing ev->bis_handle[i++] on each
iteration. However, there is no check that i stays within ev->num_bis
before the array access.
When a controller sends a LE_Create_BIG_Complete event with fewer
bis_handle entries than there are BT_BOUND connections for that BIG,
or with num_bis=0, the loop reads beyond the valid bis_handle[] flex
array into adjacent heap memory. Since the out-of-bounds values
typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()
rejects them and the connection remains in BT_BOUND state. The same
connection is then found again by hci_conn_hash_lookup_big_state(),
creating an infinite loop with hci_dev_lock held.
Fix this by:
- Breaking out of the loop when i reaches ev->num_bis and cleaning
up all remaining BT_BOUND connections, then terminating the BIG
since a mismatch between the host and controller state indicates
failure.
- Properly cleaning up the connection when hci_conn_set_handle()
fails, instead of calling continue which leaves it in BT_BOUND
state where it would be found again by the same lookup on the
next iteration.
Fixes: a0bfde167b50 ("Bluetooth: ISO: Add support for connecting multiple BISes")
Cc: stable@vger.kernel.org
Signed-off-by: hkbinbin <hkbinbinbin@gmail.com>
---
net/bluetooth/hci_event.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 286529d2e554..64b5b497c491 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -7085,9 +7085,15 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
continue;
}
+ if (i >= ev->num_bis)
+ break;
+
if (hci_conn_set_handle(conn,
- __le16_to_cpu(ev->bis_handle[i++])))
+ __le16_to_cpu(ev->bis_handle[i++]))) {
+ hci_connect_cfm(conn, HCI_ERROR_UNSPECIFIED);
+ hci_conn_del(conn);
continue;
+ }
conn->state = BT_CONNECTED;
set_bit(HCI_CONN_BIG_CREATED, &conn->flags);
@@ -7096,7 +7102,22 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
hci_iso_setup_path(conn);
}
- if (!ev->status && !i)
+ if (conn) {
+ /* More bound connections than BIS handles reported by the
+ * controller -- treat this as a failure for the entire BIG
+ * and clean up any remaining BT_BOUND connections.
+ */
+ do {
+ hci_connect_cfm(conn, HCI_ERROR_UNSPECIFIED);
+ hci_conn_del(conn);
+ } while ((conn = hci_conn_hash_lookup_big_state(hdev,
+ ev->handle,
+ BT_BOUND,
+ HCI_ROLE_MASTER)));
+
+ hci_cmd_sync_queue(hdev, hci_iso_term_big_sync,
+ UINT_PTR(ev->handle), NULL);
+ } else if (!ev->status && !i) {
/* If no BISes have been connected for the BIG,
* terminate. This is in case all bound connections
* have been closed before the BIG creation
@@ -7104,6 +7125,7 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
*/
hci_cmd_sync_queue(hdev, hci_iso_term_big_sync,
UINT_PTR(ev->handle), NULL);
+ }
hci_dev_unlock(hdev);
}
--
2.51.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH v2] Bluetooth: hci_event: fix OOB read in hci_le_create_big_complete_evt
2026-03-31 5:50 [PATCH] Bluetooth: hci_event: fix OOB read and infinite loop in hci_le_create_big_complete_evt hkbinbin
2026-03-31 13:36 ` Luiz Augusto von Dentz
2026-03-31 14:13 ` [PATCH v2] Bluetooth: hci_event: fix OOB read " hkbinbin
@ 2026-03-31 14:13 ` hkbinbin
2 siblings, 0 replies; 4+ messages in thread
From: hkbinbin @ 2026-03-31 14:13 UTC (permalink / raw)
To: marcel, luiz.dentz
Cc: gregkh, linux-bluetooth, linux-kernel, stable, hkbinbin
hci_le_create_big_complete_evt() iterates over BT_BOUND connections for
a BIG handle using a while loop, accessing ev->bis_handle[i++] on each
iteration. However, there is no check that i stays within ev->num_bis
before the array access.
When a controller sends a LE_Create_BIG_Complete event with fewer
bis_handle entries than there are BT_BOUND connections for that BIG,
or with num_bis=0, the loop reads beyond the valid bis_handle[] flex
array into adjacent heap memory. Since the out-of-bounds values
typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()
rejects them and the connection remains in BT_BOUND state. The same
connection is then found again by hci_conn_hash_lookup_big_state(),
creating an infinite loop with hci_dev_lock held.
Fix this by:
- Breaking out of the loop when i reaches ev->num_bis and cleaning
up all remaining BT_BOUND connections, then terminating the BIG
since a mismatch between the host and controller state indicates
failure.
- Properly cleaning up the connection when hci_conn_set_handle()
fails, instead of calling continue which leaves it in BT_BOUND
state where it would be found again by the same lookup on the
next iteration.
Fixes: a0bfde167b50 ("Bluetooth: ISO: Add support for connecting multiple BISes")
Cc: stable@vger.kernel.org
Signed-off-by: hkbinbin <hkbinbinbin@gmail.com>
---
net/bluetooth/hci_event.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 286529d2e554..64b5b497c491 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -7085,9 +7085,15 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
continue;
}
+ if (i >= ev->num_bis)
+ break;
+
if (hci_conn_set_handle(conn,
- __le16_to_cpu(ev->bis_handle[i++])))
+ __le16_to_cpu(ev->bis_handle[i++]))) {
+ hci_connect_cfm(conn, HCI_ERROR_UNSPECIFIED);
+ hci_conn_del(conn);
continue;
+ }
conn->state = BT_CONNECTED;
set_bit(HCI_CONN_BIG_CREATED, &conn->flags);
@@ -7096,7 +7102,22 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
hci_iso_setup_path(conn);
}
- if (!ev->status && !i)
+ if (conn) {
+ /* More bound connections than BIS handles reported by the
+ * controller -- treat this as a failure for the entire BIG
+ * and clean up any remaining BT_BOUND connections.
+ */
+ do {
+ hci_connect_cfm(conn, HCI_ERROR_UNSPECIFIED);
+ hci_conn_del(conn);
+ } while ((conn = hci_conn_hash_lookup_big_state(hdev,
+ ev->handle,
+ BT_BOUND,
+ HCI_ROLE_MASTER)));
+
+ hci_cmd_sync_queue(hdev, hci_iso_term_big_sync,
+ UINT_PTR(ev->handle), NULL);
+ } else if (!ev->status && !i) {
/* If no BISes have been connected for the BIG,
* terminate. This is in case all bound connections
* have been closed before the BIG creation
@@ -7104,6 +7125,7 @@ static void hci_le_create_big_complete_evt(struct hci_dev *hdev, void *data,
*/
hci_cmd_sync_queue(hdev, hci_iso_term_big_sync,
UINT_PTR(ev->handle), NULL);
+ }
hci_dev_unlock(hdev);
}
--
2.51.0
^ permalink raw reply related [flat|nested] 4+ messages in thread