[PATCH 0/4] Bluetooth: Keep borrowed keys inside RCU sections

[Cen Zhang <zzzccc427@gmail.com>]

hci_find_link_key(), hci_find_ltk() and hci_find_irk_by_addr() return
entries of RCU-protected lists after leaving their read-side sections.
Management clears and reloads these lists under hdev->lock, and
kfree_rcu() frees the old entries after a grace period. A user that
does not hold hdev->lock must therefore keep the returned entry inside
its own RCU read-side section until it has finished reading it.

Two such users have already been fixed this way in bluetooth-next by
commit 817cbcab91fe ("Bluetooth: hci_core: Keep RCU protection through
LTK filtering") and commit 4b76fa362110 ("Bluetooth: hci_sync: Protect
IRK identity reads with RCU").

This series applies the same approach to the remaining users that run
without hdev->lock:

  1/4 hci_find_link_key() checks the blocked-key list after leaving
      RCU, as hci_find_ltk() did before 817cbcab91fe.
  2/4 sc_generate_ltk() derives an LTK from a borrowed link key.
  3/4 smp_ltk_encrypt() starts encryption with a borrowed LTK.
  4/4 hci_le_add_resolve_list_sync() copies a borrowed IRK, as
      hci_le_set_privacy_mode_sync() did before 4b76fa362110.

The other callers either hold hdev->lock, which the management handlers
also take, or only test whether a key exists.

Each change only extends a read-side section over code that does not
sleep. Every section ends before a synchronous HCI command or a
GFP_KERNEL allocation. The patches are independent of each other.

Cen Zhang (4):
  Bluetooth: hci_core: Keep link-key filtering inside RCU
  Bluetooth: SMP: Protect link keys during LTK derivation
  Bluetooth: SMP: Protect LTK encryption with RCU
  Bluetooth: hci_sync: Copy the resolving-list IRK under RCU

 net/bluetooth/hci_core.c |  5 ++---
 net/bluetooth/hci_sync.c | 11 +++++++++--
 net/bluetooth/smp.c      | 29 +++++++++++++++++++++--------
 3 files changed, 32 insertions(+), 13 deletions(-)

---