Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout

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

Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout

Connecting the same socket twice consecutively in sco_sock_connect()

could lead to a race condition where two sco_conn objects are created

but only one is associated with the socket. If the socket is closed

before the SCO connection is established, the timer associated with the

dangling sco_conn object won't be canceled. As the sock object is being

freed, the use-after-free problem happens when the timer callback

function sco_sock_timeout() accesses the socket. Here's the call trace:

dump_stack+0x107/0x163

? refcount_inc+0x1c/

print_address_description.constprop.0+0x1c/0x47e

? refcount_inc+0x1c/0x7b

kasan_report+0x13a/0x173

? refcount_inc+0x1c/0x7b

check_memory_region+0x132/0x139

refcount_inc+0x1c/0x7b

sco_sock_timeout+0xb2/0x1ba

process_one_work+0x739/0xbd1

? cancel_delayed_work+0x13f/0x13f

? __raw_spin_lock_init+0xf0/0xf0

? to_kthread+0x59/0x85

worker_thread+0x593/0x70e

kthread+0x346/0x35a

? drain_workqueue+0x31a/0x31a

? kthread_bind+0x4b/0x4b

ret_from_fork+0x1f/0x30