CVE-2025-68304: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hcicore: lookup hciconn on RX path on protocol side

The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hciconn is not concurrently modified/deleted. This locking appears to be leftover from before connhash started using RCU commit bf4c63252490b ("Bluetooth: convert conn hash to RCU") and not clear if it had purpose since then.

Currently, there are code paths that delete hciconn from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a ("Bluetooth: hcisync: Fix UAF on hciabortconnsync") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible.

Move the lookup of hciconn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hciconn usage and lookup.

syzkaller has reported a crash that appears to be this issue:

[Task hdev->workqueue] [Task 2] hcidisconnectallsync l2caprecvacldata(hcon) hciconnget(hcon) hciabortconnsync(hcon) hcidevlock hcidevlock hciconndel(hcon) v-------------------------------- hcidevunlock hciconnput(hcon) conn = hcon->l2capdata (UAF)