Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp10437331ybi; Wed, 24 Jul 2019 23:12:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqylU0gfiNrOCOIIKlVcUuiVdmo+qnH9WnZ4A5landK5itD/RI9DYujsxlKU1ZjJrZVy/naV X-Received: by 2002:a63:6901:: with SMTP id e1mr54667209pgc.390.1564035121421; Wed, 24 Jul 2019 23:12:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564035121; cv=none; d=google.com; s=arc-20160816; b=FGd5Ap6r3glQ7uy8tix5bULmPSZfRK0V/vH+PBwdK8d39UeYv+WHplwO56kklql0Lh tXLOsVahB7HdTcRwLh9RJvLhOPtiiN7hQBv/6/M8oRIyVWpiSf2CoNaWX4Qk5J+He3Qa apUak8W6R19LVqAQiSUZcOOcPrCK2/MBFF4O8vrhLvO4YqboXwR5b7T80dQlyUZgf6YA CYv36YtZ+TIvByyFr8seUKS37X3zuflMEGeHY/zz96W5dNGzIYb6PvUTCSBt4QNjNwVc PVYV83HyoxkvJUMZ/Wq+UGeULSuAkwKE1tLvg0X6a4y7CN/iWJ/eML/ADx7sYrkpJ0T0 b1sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=+lLwejNYV2WIlTfwonpmc/48bMm6hSoN3Peddx0VtzQ=; b=yhyvntZ9hZFD09sM6j1pi7FRnUFSw6/9tio67Ty1UN/ZMdJVhA7aRe+2C3CxorONh3 FawY0iiJx73zuheiY+4LMXprYUFov2vUZVbUKR4WW55sTPETFAYeci1S5o/lDezwtALg LpGYucsJsXE0PHQp0oulfvcbZyrK5e8/8fPHLRTKlR6kb6A1F6YV4Is9hdIKhOm69lwn /RnYniv3LHn5HOeGyFRu3fRdwEnXcx8kG2OoSe0TD9yJ0NxttFN/XgtO41NaQNsPweFw PK6eYejhTUQdcBtN/14qQ9TZ3uvk1AYq1NDahl6VMAq5/MFsscxITMpH284t48EaaPJR iKMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VQ5IF1BA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c8si17996605pfo.42.2019.07.24.23.11.47; Wed, 24 Jul 2019 23:12:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VQ5IF1BA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404616AbfGYFlW (ORCPT + 99 others); Thu, 25 Jul 2019 01:41:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:56108 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404607AbfGYFlU (ORCPT ); Thu, 25 Jul 2019 01:41:20 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F2F0922CD0; Thu, 25 Jul 2019 05:41:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564033279; bh=pD2B3Ve0o9u8g836uw9nTkuj+LCSS0V4eNE5JGQihvs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VQ5IF1BAsu3jMNB1N8X2Q/oSRezq59C26t+1yVhQ3y3+2BKKKM53KnIuExi7V80Bu xq+8ivS2or8xpX++Q0NbQrCXA+0P9qJaqYThTas6d5EgiYwNlMdqkM9G1D8wZb9UI4 jeu3UJ4rNYwxiAdzacVl4uaekfVyAEJ0Ogl5A5CI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Carey Sonsino , Marcel Holtmann , Sasha Levin Subject: [PATCH 4.19 153/271] Bluetooth: validate BLE connection interval updates Date: Wed, 24 Jul 2019 21:20:22 +0200 Message-Id: <20190724191708.317880875@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190724191655.268628197@linuxfoundation.org> References: <20190724191655.268628197@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Upstream commit c49a8682fc5d298d44e8d911f4fa14690ea9485e ] Problem: The Linux Bluetooth stack yields complete control over the BLE connection interval to the remote device. The Linux Bluetooth stack provides access to the BLE connection interval min and max values through /sys/kernel/debug/bluetooth/hci0/ conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval. These values are used for initial BLE connections, but the remote device has the ability to request a connection parameter update. In the event that the remote side requests to change the connection interval, the Linux kernel currently only validates that the desired value is within the acceptable range in the Bluetooth specification (6 - 3200, corresponding to 7.5ms - 4000ms). There is currently no validation that the desired value requested by the remote device is within the min/max limits specified in the conn_min_interval/conn_max_interval configurations. This essentially leads to Linux yielding complete control over the connection interval to the remote device. The proposed patch adds a verification step to the connection parameter update mechanism, ensuring that the desired value is within the min/max bounds of the current connection. If the desired value is outside of the current connection min/max values, then the connection parameter update request is rejected and the negative response is returned to the remote device. Recall that the initial connection is established using the local conn_min_interval/conn_max_interval values, so this allows the Linux administrator to retain control over the BLE connection interval. The one downside that I see is that the current default Linux values for conn_min_interval and conn_max_interval typically correspond to 30ms and 50ms respectively. If this change were accepted, then it is feasible that some devices would no longer be able to negotiate to their desired connection interval values. This might be remedied by setting the default Linux conn_min_interval and conn_max_interval values to the widest supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same behavior as the current implementation, where the remote device could request to change the connection interval value to any value that is permitted by the Bluetooth specification, and Linux would accept the desired value. Signed-off-by: Carey Sonsino Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin --- net/bluetooth/hci_event.c | 5 +++++ net/bluetooth/l2cap_core.c | 9 ++++++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 3e7badb3ac2d..0adcddb211fa 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -5545,6 +5545,11 @@ static void hci_le_remote_conn_param_req_evt(struct hci_dev *hdev, return send_conn_param_neg_reply(hdev, handle, HCI_ERROR_UNKNOWN_CONN_ID); + if (min < hcon->le_conn_min_interval || + max > hcon->le_conn_max_interval) + return send_conn_param_neg_reply(hdev, handle, + HCI_ERROR_INVALID_LL_PARAMS); + if (hci_check_conn_params(min, max, latency, timeout)) return send_conn_param_neg_reply(hdev, handle, HCI_ERROR_INVALID_LL_PARAMS); diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 260ef5426e0c..a54dadf4a6ca 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -5287,7 +5287,14 @@ static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn, memset(&rsp, 0, sizeof(rsp)); - err = hci_check_conn_params(min, max, latency, to_multiplier); + if (min < hcon->le_conn_min_interval || + max > hcon->le_conn_max_interval) { + BT_DBG("requested connection interval exceeds current bounds."); + err = -EINVAL; + } else { + err = hci_check_conn_params(min, max, latency, to_multiplier); + } + if (err) rsp.result = cpu_to_le16(L2CAP_CONN_PARAM_REJECTED); else -- 2.20.1