[PATCH bluetooth 0/4] Bluetooth: fix cmd_sync payload lifetimes on the cancel path

The cmd_sync worker calls entry->destroy() after running a command, and
_hci_cmd_sync_cancel_entry() does the same when an entry is cancelled --
but only if a destroy callback was supplied. Without one it frees the
work entry and leaves entry->data unreleased.

These four call sites pass a heap payload with a NULL destroy callback
and free it inside the sync function instead, so each of them leaks when
the entry is cancelled rather than run. hci_cmd_sync_clear() cancels
every pending entry when the controller is unregistered.

Patch 1 additionally holds the connection, as the payload stores a bare
hci_conn pointer. Patch 2 additionally frees the payload when queueing
fails, which it currently does not check for. Patches 3 and 4 also leak
the socket reference taken by mgmt_pending_new().

Each patch moves the release into a destroy callback; apart from holding
the connection in patch 1, no behaviour changes.

Found by inspection while reading the recent cmd_sync lifetime fixes.
Not tested on hardware: these paths need an adapter removal racing a
queued command, or allocation failure, to reach.

Linmao Li (4):
  Bluetooth: hci_conn: fix the SCO setup context lifetime
  Bluetooth: hci_sync: free the advertising instance on the failure and
    cancel paths
  Bluetooth: MGMT: free the mesh send cancel command when it is
    cancelled
  Bluetooth: MGMT: free the HCI command when it is cancelled

 net/bluetooth/hci_conn.c | 20 +++++++++++++++-----
 net/bluetooth/hci_sync.c | 12 +++++++++---
 net/bluetooth/mgmt.c     | 22 +++++++++++++++-------
 3 files changed, 39 insertions(+), 15 deletions(-)


base-commit: abd93c85c8667add738ee82aeab95dd9fc8265a2
-- 
2.25.1