@@ -4661,6 +4661,19 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev, void *data,
struct hci_ev_sync_conn_complete *ev = data;
struct hci_conn *conn;
+ switch (ev->link_type) {
+ case SCO_LINK:
+ case ESCO_LINK:
+ break;
+ default:
+ /* As per Core 5.3 Vol 4 Part E 7.7.35 (p.2219), Link_Type
+ * for HCI_Synchronous_Connection_Complete is limited to
+ * either SCO or eSCO
+ */
+ bt_dev_err(hdev, "Ignoring connect complete event for invalid link type");
+ return;
+ }
+
bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
hci_dev_lock(hdev);
This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL. Signed-off-by: Soenke Huster <soenke.huster@eknoes.de> --- v3: Replace if with switch, reference spec I found this null pointer dereference while fuzzing bluetooth-next. On the described behaviour, a null ptr deref in line 4723 happens, as conn->link is NULL. According to the Core spec, Link_Type must be SCO or eSCO, all other values are reserved for future use. Checking that mitigates a null pointer dereference. net/bluetooth/hci_event.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)