bluetooth L2CAPSockOpt UAF

Vulnerability analysis

After a prior fix began holding a reference on the L2CAP connection object, the connection pointer in an L2CAP channel remained non-NULL even after the underlying HCI connection was deleted. The socket option handlers only checked whether the connection pointer was non-NULL before dereferencing it to access the HCI connection's device handle and other fields, so a getsockopt or setsockopt call that raced with connection teardown would access freed memory. The fix adds a check for a flag that the connection deletion path sets before removing the HCI connection, returning an error if the connection is being torn down, and holds the channel lock across the entire option access to prevent the race. A local user who can create and use Bluetooth L2CAP sockets can trigger this; no special privileges beyond a local account are required, though the race window is narrow.