| Message ID | 20220113090553.40362-1-soenke.huster@eknoes.de |
|---|---|
| State | Accepted |
| Commit | 3afee2118132e93e5f6fa636dfde86201a860ab3 |
| Headers | show |
| Series | Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt | expand |
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index fc30f4c03d29..fc3f29d195d2 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -4661,6 +4661,11 @@ 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; + if (ev->link_type != SCO_LINK || ev->link_type != ESCO_LINK) { + 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 specified just 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> --- 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 | 5 +++++ 1 file changed, 5 insertions(+)