OpenSynergy BlueSDK (aka Blue SDK) through 6.x has Improper Input Validation. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of proper validation of remote L2CAP channel ID (CID). An attacker can leverage this to create an L2CAP channel with the null identifier assigned as a remote CID.

OpenSynergy BlueSDK (aka Blue SDK) through 6.x mishandles a function call. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from an incorrect variable used as a function argument. An attacker can leverage this to cause unexpected behavior or obtain sensitive information.

OpenSynergy BlueSDK (aka Blue SDK) through 6.x has Incorrect Control Flow Scoping. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of proper return control flow after detecting an unusual condition. An attacker can leverage this to bypass a security validation and make the incoming data be processed.

OpenSynergy BlueSDK (aka Blue SDK) through 6.x has a Use-After-Free. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of validating the existence of an object before performing operations on the object (aka use after free). An attacker can leverage this to achieve remote code execution in the context of a user account under which the Bluetooth process runs.

The L2CAP signaling channel implementation and SDP server implementation in OpenSynergy Blue SDK 3.2 through 6.0 allow remote, unauthenticated attackers to execute arbitrary code or cause a denial of service via malicious L2CAP configuration requests, in conjunction with crafted SDP communication over maliciously configured L2CAP channels. The attacker must have connectivity over the Bluetooth physical layer, and must be able to send raw L2CAP frames. This is related to L2Cap_HandleConfigReq in core/stack/l2cap/l2cap_sm.c and SdpServHandleServiceSearchAttribReq in core/stack/sdp/sdpserv.c.