public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Pauli Virtanen <pav@iki.fi>
To: linux-bluetooth@vger.kernel.org
Cc: Pauli Virtanen <pav@iki.fi>
Subject: [PATCH 0/9] Bluetooth: avoid concurrent deletion of hci_conn
Date: Fri,  3 Oct 2025 20:08:43 +0300	[thread overview]
Message-ID: <cover.1759511032.git.pav@iki.fi> (raw)

This contains the simpler fixes from
https://lore.kernel.org/linux-bluetooth/cover.1758481869.git.pav@iki.fi/

hdev has two workqueues that run concurrently, and both may delete
hci_conn. hci_conn* pointers then require either (i) hdev/rcu lock
covering lookup and usage, or (ii) hci_conn_get reference held.

If neither is done, it's likely there are corner cases that hit UAF,
especially if controller misbehaves.

Correct code in several places to follow the patterns (1)

    take lock
    conn = hci_conn_hash_lookup(...)
    if (conn)
	do_something(conn)
    release lock

or (2)

    take lock
    conn = hci_conn_hash_lookup(...)
    if (conn)
	conn = hci_conn_get(conn)
    release lock
    do_something_carefully(conn)
    hci_conn_put(conn)

Generally do_something_carefully should do (3)

    take lock
    if (hci_conn_valid(hdev, conn))
	do_something(conn)
    release lock

hci_conn_valid() shouldn't be called unless refcount on conn is known to
be held, as the pointer may otherwise already be freed, and even though
hci_conn_valid() doesn't dereference the comparison of freed pointer it
does is strictly speaking undefined behavior (kalloc is not guaranteed
to not reuse addresses).

Some of the code touched here is missing locks for (3), those need to be
addressed in separate series.

Pauli Virtanen (9):
  Bluetooth: hci_event: extend hdev lock in
    hci_le_remote_conn_param_req_evt
  Bluetooth: hci_conn: take hdev lock in set_cig_params_sync
  Bluetooth: mgmt: take lock and hold reference when handling hci_conn
  Bluetooth: L2CAP: fix hci_conn_valid() usage
  Bluetooth: hci_sync: extend conn_hash lookup RCU critical sections
  Bluetooth: hci_sync: make hci_cmd_sync_run* indicate if item was added
  Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if
    exists
  Bluetooth: hci_conn: hold reference in abort_conn_sync
  Bluetooth: hci_sync: hold references in hci_sync callbacks

 net/bluetooth/hci_conn.c   |  22 +++++-
 net/bluetooth/hci_event.c  |  33 +++++----
 net/bluetooth/hci_sync.c   | 144 ++++++++++++++++++++++++++++++-------
 net/bluetooth/l2cap_core.c |   8 ++-
 net/bluetooth/mgmt.c       |  42 +++++++++--
 5 files changed, 202 insertions(+), 47 deletions(-)

-- 
2.51.0


             reply	other threads:[~2025-10-03 17:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-03 17:08 Pauli Virtanen [this message]
2025-10-03 17:08 ` [PATCH 1/9] Bluetooth: hci_event: extend hdev lock in hci_le_remote_conn_param_req_evt Pauli Virtanen
2025-10-03 17:08 ` [PATCH 2/9] Bluetooth: hci_conn: take hdev lock in set_cig_params_sync Pauli Virtanen
2025-10-03 17:08 ` [PATCH 3/9] Bluetooth: mgmt: take lock and hold reference when handling hci_conn Pauli Virtanen
2025-10-03 17:08 ` [PATCH 4/9] Bluetooth: L2CAP: fix hci_conn_valid() usage Pauli Virtanen
2025-10-03 17:08 ` [PATCH 5/9] Bluetooth: hci_sync: extend conn_hash lookup RCU critical sections Pauli Virtanen
2025-10-03 17:08 ` [PATCH 6/9] Bluetooth: hci_sync: make hci_cmd_sync_run* indicate if item was added Pauli Virtanen
2025-10-03 17:08 ` [PATCH 7/9] Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists Pauli Virtanen
2025-10-03 17:08 ` [PATCH 8/9] Bluetooth: hci_conn: hold reference in abort_conn_sync Pauli Virtanen
2025-10-03 17:08 ` [PATCH 9/9] Bluetooth: hci_sync: hold references in hci_sync callbacks Pauli Virtanen
2025-10-06  0:39 ` [PATCH 0/9] Bluetooth: avoid concurrent deletion of hci_conn Pauli Virtanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1759511032.git.pav@iki.fi \
    --to=pav@iki.fi \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox