[PATCH v3 0/2] Bluetooth: fix race during h4 bluetooth initialization

[PATCH v3 0/2] Bluetooth: fix race during h4 bluetooth initialization

[Jonathan Rissanen]

Hi,

This series fixes a race condition that causes hci events to sometimes
be ignored during h4 initialization.

The first patch clears the HCI_UART_PROTO_INIT bit if device
registration fails. This is needed to prevent the second patch from
introducing a possible null pointer dereference.

The second patch contains the fix for the race condition.

Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com>
---
Changes in v3:
- Add "Fixes:" tag to the commits.
- Link to v2: https://lore.kernel.org/r/20260326-hci-init-fix-v2-0-a974211d0224@axis.com

Changes in v2:
- Added a patch before the fix that prevents possible null pointer dereference
  from being introduced.
- Link to v1: https://lore.kernel.org/r/20260320-hci-init-fix-v1-1-e1960a41baf2@axis.com

---
Jonathan Rissanen (2):
      Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error
      Bluetooth: hci_h4: Fix race during initialization

 drivers/bluetooth/hci_h4.c    | 3 ---
 drivers/bluetooth/hci_ldisc.c | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260303-hci-init-fix-9657128a0104

Best regards,
-- 
Jonathan Rissanen <jonathan.rissanen@axis.com>

[PATCH v3 1/2] Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error

[Jonathan Rissanen]

When hci_register_dev() fails in hci_uart_register_dev()
HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu)
and setting hu->hdev to NULL. This means incoming UART data will reach
the protocol-specific recv handler in hci_uart_tty_receive() after
resources are freed.

Clear HCI_UART_PROTO_INIT with a write lock before calling
hu->proto->close() and setting hu->hdev to NULL. The write lock ensures
all active readers have completed and no new reader can enter the
protocol recv path before resources are freed.

This allows the protocol-specific recv functions to remove the
"HCI_UART_REGISTERED" guard without risking a null pointer dereference
if hci_register_dev() fails.

Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization")
Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com>
---
 drivers/bluetooth/hci_ldisc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 2b28515de92c..5455990ab211 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -692,6 +692,9 @@ static int hci_uart_register_dev(struct hci_uart *hu)
 
 	if (hci_register_dev(hdev) < 0) {
 		BT_ERR("Can't register HCI device");
+		percpu_down_write(&hu->proto_lock);
+		clear_bit(HCI_UART_PROTO_INIT, &hu->flags);
+		percpu_up_write(&hu->proto_lock);
 		hu->proto->close(hu);
 		hu->hdev = NULL;
 		hci_free_dev(hdev);

-- 
2.39.5

[PATCH v3 2/2] Bluetooth: hci_h4: Fix race during initialization

[Jonathan Rissanen]

Commit 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during
initialization") fixed a race for hci commands sent during initialization.
However, there is still a race that happens if an hci event from one of
these commands is received before HCI_UART_REGISTERED has been set at
the end of hci_uart_register_dev(). The event will be ignored which
causes the command to fail with a timeout in the log:

"Bluetooth: hci0: command 0x1003 tx timeout"

This is because the hci event receive path (hci_uart_tty_receive ->
h4_recv) requires HCI_UART_REGISTERED to be set in h4_recv(), while the
hci command transmit path (hci_uart_send_frame -> h4_enqueue) only
requires HCI_UART_PROTO_INIT to be set in hci_uart_send_frame().

The check for HCI_UART_REGISTERED was originally added in commit
c2578202919a ("Bluetooth: Fix H4 crash from incoming UART packets")
to fix a crash caused by hu->hdev being null dereferenced. That can no
longer happen: once HCI_UART_PROTO_INIT is set in hci_uart_register_dev()
all pointers (hu, hu->priv and hu->hdev) are valid, and
hci_uart_tty_receive() already calls h4_recv() on HCI_UART_PROTO_INIT
or HCI_UART_PROTO_READY.

Remove the check for HCI_UART_REGISTERED in h4_recv() to fix the race
condition.

Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization")
Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com>
---
 drivers/bluetooth/hci_h4.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index ec017df8572c..1e9e2cad9ddf 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -109,9 +109,6 @@ static int h4_recv(struct hci_uart *hu, const void *data, int count)
 {
 	struct h4_struct *h4 = hu->priv;
 
-	if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
-		return -EUNATCH;
-
 	h4->rx_skb = h4_recv_buf(hu, h4->rx_skb, data, count,
 				 h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts));
 	if (IS_ERR(h4->rx_skb)) {

-- 
2.39.5

Re: [PATCH v3 0/2] Bluetooth: fix race during h4 bluetooth initialization

[patchwork-bot+bluetooth]

Hello:

This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Fri, 27 Mar 2026 11:47:19 +0100 you wrote:
> Hi,
> 
> This series fixes a race condition that causes hci events to sometimes
> be ignored during h4 initialization.
> 
> The first patch clears the HCI_UART_PROTO_INIT bit if device
> registration fails. This is needed to prevent the second patch from
> introducing a possible null pointer dereference.
> 
> [...]

Here is the summary with links:
  - [v3,1/2] Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error
    https://git.kernel.org/bluetooth/bluetooth-next/c/c6a106ff1913
  - [v3,2/2] Bluetooth: hci_h4: Fix race during initialization
    https://git.kernel.org/bluetooth/bluetooth-next/c/42ee54fcd11e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html