From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:51047 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932238AbbLGMTz (ORCPT ); Mon, 7 Dec 2015 07:19:55 -0500 Subject: Patch "Bluetooth: Fix removing connection parameters when unpairing" has been added to the 4.3-stable tree To: johan.hedberg@intel.com, gregkh@linuxfoundation.org, marcel@holtmann.org Cc: , From: Date: Mon, 07 Dec 2015 00:31:05 -0800 Message-ID: <14494770652271@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled Bluetooth: Fix removing connection parameters when unpairing to the 4.3-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: bluetooth-fix-removing-connection-parameters-when-unpairing.patch and it can be found in the queue-4.3 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From a6ad2a6b9cc1d9d791aee5462cfb8528f366f1d4 Mon Sep 17 00:00:00 2001 From: Johan Hedberg Date: Mon, 19 Oct 2015 10:51:47 +0300 Subject: Bluetooth: Fix removing connection parameters when unpairing From: Johan Hedberg commit a6ad2a6b9cc1d9d791aee5462cfb8528f366f1d4 upstream. The commit 89cbb0638e9b7 introduced support for deferred connection parameter removal when unpairing by removing them only once an existing connection gets disconnected. However, it failed to address the scenario when we're *not* connected and do an unpair operation. What makes things worse is that most user space BlueZ versions will first issue a disconnect request and only then unpair, meaning the buggy code will be triggered every time. This effectively causes the kernel to resume scanning and reconnect to a device for which we've removed all keys and GATT database information. This patch fixes the issue by adding the missing call to the hci_conn_params_del() function to a branch which handles the case of no existing connection. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman --- net/bluetooth/mgmt.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -3090,6 +3090,11 @@ static int unpair_device(struct sock *sk } else { u8 addr_type; + if (cp->addr.type == BDADDR_LE_PUBLIC) + addr_type = ADDR_LE_DEV_PUBLIC; + else + addr_type = ADDR_LE_DEV_RANDOM; + conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &cp->addr.bdaddr); if (conn) { @@ -3105,13 +3110,10 @@ static int unpair_device(struct sock *sk */ if (!cp->disconnect) conn = NULL; + } else { + hci_conn_params_del(hdev, &cp->addr.bdaddr, addr_type); } - if (cp->addr.type == BDADDR_LE_PUBLIC) - addr_type = ADDR_LE_DEV_PUBLIC; - else - addr_type = ADDR_LE_DEV_RANDOM; - hci_remove_irk(hdev, &cp->addr.bdaddr, addr_type); err = hci_remove_ltk(hdev, &cp->addr.bdaddr, addr_type); Patches currently in stable-queue which might be from johan.hedberg@intel.com are queue-4.3/bluetooth-fix-missing-hdev-locking-for-le-scan-cleanup.patch queue-4.3/bluetooth-fix-removing-connection-parameters-when-unpairing.patch