Bluetooth: hci_conn: hold a reference for LE connection timeout

le_conn_timeout is embedded in struct hci_conn, but queued timeout work does not hold a connection reference. hci_conn_del() uses cancel_delayed_work() because synchronous cancellation would deadlock when le_conn_timeout() itself calls hci_conn_del() while holding hdev->lock.

This leaves the following interleaving possible:

CPU 0 CPU 1
le_conn_timeout()
hci_conn_del()
cancel_delayed_work() = false hci_conn_cleanup()
put_device()
kfree(conn)
hci_conn_failed(conn, ...)

The callback then dereferences the released connection. KASAN reported:

  BUG: KASAN: slab-use-after-free in hci_conn_failed+0x232/0x250
  Read of size 8 at addr ffff8881180e8e20 by task kworker/u33:1/111
  Workqueue: hci0 le_conn_timeout
  Call Trace:
   hci_conn_failed+0x232/0x250
   le_conn_timeout+0x23e/0x2c0
   process_one_work+0x61b/0xf50
   worker_thread+0x45b/0xd10

  Allocated by task 115:
   __hci_conn_add+0x1758/0x1b90
   hci_connect_le+0x523/0x780
   l2cap_chan_connect+0xfca/0x1bd0
   l2cap_sock_connect+0x310/0x530

  Freed by task 110:
   kfree+0x149/0x330
   device_release+0xc8/0x240
   kobject_put+0x14d/0x280
   hci_conn_del+0x561/0xe70
   hci_abort_conn_sync+0x3e3/0x800

Take a connection reference before queueing le_conn_timeout. Drop it when queueing fails or cancellation removes a pending instance. An executing callback defers its put to the system workqueue. The final reference can release the controller and destroy hdev->workqueue. Flush the previous deferred put before reusing its embedded work item.

Keep the timeout on hdev->workqueue so it remains ordered with received HCI events. It can also enqueue chained controller work while that workqueue is being drained. Under hdev->lock, act only while the connection is still registered and in BT_CONNECT.

Release hdev->lock around the existing timeout flush in a failed connection completion. Revalidate the connection after reacquiring it. This allows the timeout's locked state check to finish without deadlocking its flusher.

---
Changes in v6:
- Replace v5's command-sync wait and advertising-state changes with a lifetime-only fix after validation found regressions in those paths.
- Hold a connection reference for queued timeout work and defer the final put to the system workqueue, avoiding destruction of hdev->workqueue from one of its own workers.
- Keep the timeout ordered with received HCI events on hdev->workqueue. Serialize its state check with hdev->lock and revalidate the connection after flushing the timeout without that lock.
- Validate the lifetime and ordering cases with focused tests, the normal Bluetooth test suites, a full kernel build and Sashiko with zero findings.

 include/net/bluetooth/hci_core.h |  3 ++
 net/bluetooth/hci_conn.c         | 51 ++++++++++++++++++++++++++------
 net/bluetooth/hci_event.c        | 10 ++-----
 net/bluetooth/hci_sync.c         |  6 ++++
 4 files changed, 54 insertions(+), 16 deletions(-)

index 788d6600f500..f1e85bfe6366 100644
@@ -773,6 +773,7 @@ struct hci_conn {
 	struct delayed_work auto_accept_work;
 	struct delayed_work idle_work;
 	struct delayed_work le_conn_timeout;
+	struct work_struct le_conn_timeout_put;
 
 	struct device	dev;
 	struct dentry	*debugfs;

@@ -1641,6 +1642,8 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst,
 struct hci_conn *hci_conn_add_unset(struct hci_dev *hdev, int type,
 				    bdaddr_t *dst, u8 dst_type, u8 role);
 void hci_conn_del(struct hci_conn *conn);
+void hci_conn_queue_le_timeout(struct hci_conn *conn);
+void hci_conn_cancel_le_timeout(struct hci_conn *conn);
 void hci_conn_hash_flush(struct hci_dev *hdev);
 
 struct hci_chan *hci_chan_create(struct hci_conn *conn);

index 5ac2357e92c9..d34c70f51ae7 100644
@@ -1593,9 +1593,7 @@ static u8 hci_cc_le_set_adv_enable(struct hci_dev *hdev, void *data,
 
 		conn = hci_lookup_le_connect(hdev);
 		if (conn)
-			queue_delayed_work(hdev->workqueue,
-					   &conn->le_conn_timeout,
-					   conn->conn_timeout);
+			hci_conn_queue_le_timeout(conn);
 	} else {
 		hci_dev_clear_flag(hdev, HCI_LE_ADV);
 	}

@@ -1641,9 +1639,7 @@ static u8 hci_cc_le_set_ext_adv_enable(struct hci_dev *hdev, void *data,
 
 		conn = hci_lookup_le_connect(hdev);
 		if (conn)
-			queue_delayed_work(hdev->workqueue,
-					   &conn->le_conn_timeout,
-					   conn->conn_timeout);
+			hci_conn_queue_le_timeout(conn);
 	} else {
 		if (cp->num_of_sets) {
 			if (adv)

@@ -5801,7 +5797,7 @@ static void le_conn_complete_evt(struct hci_dev *hdev, u8 status,
 			}
 		}
 	} else {
-		cancel_delayed_work(&conn->le_conn_timeout);
+		hci_conn_cancel_le_timeout(conn);
 	}
 
 	/* The HCI_LE_Connection_Complete event is only sent once per connection.

index 00be55cf60ac..6c4f93f55a4d 100644
@@ -7308,7 +7308,13 @@ static void create_le_conn_complete(struct hci_dev *hdev, void *data, int err)
 		goto unlock;
 
 	/* Flush to make sure we send create conn cancel command if needed */
+	hci_dev_unlock(hdev);
 	flush_delayed_work(&conn->le_conn_timeout);
+	hci_dev_lock(hdev);
+
+	if (!hci_conn_valid(hdev, conn) || conn->state != BT_CONNECT)
+		goto unlock;
+
 	hci_conn_failed(conn, bt_status(err));
 
 unlock:

2.43.0

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1178509/

---Test result---

Test Summary:

CheckPatch                    PASS      1.43 seconds
VerifyFixes                   PASS      0.09 seconds
VerifySignedoff               PASS      0.09 seconds
GitLint                       PASS      0.26 seconds
SubjectPrefix                 PASS      0.08 seconds
BuildKernel                   PASS      29.69 seconds
CheckAllWarning               PASS      33.33 seconds
CheckSparse                   WARNING   36.32 seconds
BuildKernel32                 PASS      29.54 seconds
CheckKernelLLVM               PASS      35.12 seconds
TestRunnerSetup               PASS      798.47 seconds
TestRunner_l2cap-tester       PASS      12.55 seconds
TestRunner_iso-tester         PASS      14.67 seconds
TestRunner_bnep-tester        PASS      3.07 seconds
TestRunner_mgmt-tester        PASS      61.41 seconds
TestRunner_rfcomm-tester      PASS      4.48 seconds
TestRunner_sco-tester         PASS      5.60 seconds
TestRunner_ioctl-tester       PASS      4.66 seconds
TestRunner_mesh-tester        FAIL      7.81 seconds
TestRunner_smp-tester         PASS      4.29 seconds
TestRunner_userchan-tester    PASS      3.16 seconds
TestRunner_6lowpan-tester     PASS      4.42 seconds
IncrementalBuild              PASS      27.99 seconds

Details
##############################
Test: CheckSparse - WARNING
Desc: Run sparse tool with linux kernel
Output:
net/bluetooth/hci_event.c: note: in included file (through include/net/bluetooth/hci_core.h):
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases

Mesh - Send cancel - 1                               Timed out    2.396 seconds
Mesh - Send cancel - 2                               Timed out    1.999 seconds

https://github.com/bluez/bluetooth-next/pull/853

---
Regards,
Linux Bluetooth

Hello Chengfeng,

We independently reproduced the LE connection timeout use-after-free and tested your [PATCH v6] ("Bluetooth: hci_conn: hold a reference for LE connection timeout") on a clean Linux v7.4-rc1 tree (6628e7d4c6b2).

Test setup:
- QEMU/KVM, KASAN-enabled kernel, /dev/vhci virtual controller
- Management SET_ADVERTISING and L2CAP LE connection
- Kprobe-assisted timing injection at le_conn_timeout() entry, 50 ms park, with mgmt disconnect at discms=2015

Results:
- Unpatched v7.4-rc1: 42 slab-use-after-free reports, with the first relevant frame in hci_conn_failed()
- Your v6 patch applied to the clean tree: 0 KASAN reports, with 200 confirmed probe hits under the same timing setup
- Control run without injection: 0 KASAN reports

This is a test of your posted v6 reference-counting patch, not merely our independently developed fix. The result supports the lifetime fix under the tested interleaving; it does not establish coverage of every Bluetooth shutdown path.

I also confirmed your analysis that a naive cancel_delayed_work_sync() replacement is NOT safe: the mgmt disconnect path holds hdev->lock while calling hci_conn_del, which would deadlock against le_conn_timeout's hci_dev_lock acquisition. Your reference-counting approach is the correct solution.

We can provide the full console logs, build configuration, and reproducer details privately if useful. The investigation was AI-assisted, and the patch application and test results were reviewed by the human tester.

Best regards,
Yaohan Li

Hi Yaohan,

Thank you for reproducing the issue and testing the v6 patch, the detailed results and your confirmation of the locking issue are helpful. I also appreciate your Tested-by tag.

Best regards,
Chengfeng