linux-kernel - [PATCH 4.2.y-ckt 077/305] Bluetooth: Fix l2cap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1452902519-2754-78-git-send-email-kamal@canonical.com>
Date:	Fri, 15 Jan 2016 15:58:11 -0800
From:	Kamal Mostafa <kamal@...onical.com>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	kernel-team@...ts.ubuntu.com
Cc:	Johan Hedberg <johan.hedberg@...el.com>,
	Marcel Holtmann <marcel@...tmann.org>,
	Kamal Mostafa <kamal@...onical.com>
Subject: [PATCH 4.2.y-ckt 077/305] Bluetooth: Fix l2cap_chan leak in SMP

4.2.8-ckt2 -stable review patch.  If anyone has any objections, please let me know.

---8<------------------------------------------------------------

From: Johan Hedberg <johan.hedberg@...el.com>

commit 7883746bc663150e8acd7a57397fc889698b0b33 upstream.

The L2CAP core expects channel implementations to manage the reference
returned by the new_connection callback. With sockets this is already
handled with each channel being tied to the corresponding socket. With
SMP however there's no context to tie the pointer to in the
smp_new_conn_cb function. The function can also not just drop the
reference since it's the only one at that point.

For fixed channels (like SMP) the code path inside the L2CAP core from
new_connection() to ready() is short and straight-forwards. The
crucial difference is that in ready() the implementation has access to
the l2cap_conn that SMP needs associate its l2cap_chan. Instead of
taking a new reference in smp_ready_cb() we can simply assume to
already own the reference created in smp_new_conn_cb(), i.e. there is
no need to call l2cap_chan_hold().

Signed-off-by: Johan Hedberg <johan.hedberg@...el.com>
Signed-off-by: Marcel Holtmann <marcel@...tmann.org>
Signed-off-by: Kamal Mostafa <kamal@...onical.com>
---
 net/bluetooth/smp.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 0510a57..d29fda2 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -3001,8 +3001,13 @@ static void smp_ready_cb(struct l2cap_chan *chan)

 	BT_DBG("chan %p", chan);

+	/* No need to call l2cap_chan_hold() here since we already own
+	 * the reference taken in smp_new_conn_cb(). This is just the
+	 * first time that we tie it to a specific pointer. The code in
+	 * l2cap_core.c ensures that there's no risk this function wont
+	 * get called if smp_new_conn_cb was previously called.
+	 */
 	conn->smp = chan;
-	l2cap_chan_hold(chan);

 	if (hcon->type == ACL_LINK && test_bit(HCI_CONN_ENCRYPT, &hcon->flags))
 		bredr_pairing(chan);
-- 
1.9.1