This is a note to let you know that I've just added the patch titled
Bluetooth: Fix L2CAP deadlock
to the 3.10-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-l2cap-deadlock.patch
and it can be found in the queue-3.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 8a96f3cd22878fc0bb564a8478a6e17c0b8dca73 Mon Sep 17 00:00:00 2001
From: Jukka Taimisto <jtt@xxxxxxxxxxxxxxx>
Date: Thu, 22 May 2014 10:02:39 +0000
Subject: Bluetooth: Fix L2CAP deadlock
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Jukka Taimisto <jtt@xxxxxxxxxxxxxxx>
commit 8a96f3cd22878fc0bb564a8478a6e17c0b8dca73 upstream.
-[0x01 Introduction
We have found a programming error causing a deadlock in Bluetooth subsystem
of Linux kernel. The problem is caused by missing release_sock() call when
L2CAP connection creation fails due full accept queue.
The issue can be reproduced with 3.15-rc5 kernel and is also present in
earlier kernels.
-[0x02 Details
The problem occurs when multiple L2CAP connections are created to a PSM which
contains listening socket (like SDP) and left pending, for example,
configuration (the underlying ACL link is not disconnected between
connections).
When L2CAP connection request is received and listening socket is found the
l2cap_sock_new_connection_cb() function (net/bluetooth/l2cap_sock.c) is called.
This function locks the 'parent' socket and then checks if the accept queue
is full.
1178 lock_sock(parent);
1179
1180 /* Check for backlog size */
1181 if (sk_acceptq_is_full(parent)) {
1182 BT_DBG("backlog full %d", parent->sk_ack_backlog);
1183 return NULL;
1184 }
If case the accept queue is full NULL is returned, but the 'parent' socket
is not released. Thus when next L2CAP connection request is received the code
blocks on lock_sock() since the parent is still locked.
Also note that for connections already established and waiting for
configuration to complete a timeout will occur and l2cap_chan_timeout()
(net/bluetooth/l2cap_core.c) will be called. All threads calling this
function will also be blocked waiting for the channel mutex since the thread
which is waiting on lock_sock() alread holds the channel mutex.
We were able to reproduce this by sending continuously L2CAP connection
request followed by disconnection request containing invalid CID. This left
the created connections pending configuration.
After the deadlock occurs it is impossible to kill bluetoothd, btmon will not
get any more data etc. requiring reboot to recover.
-[0x03 Fix
Releasing the 'parent' socket when l2cap_sock_new_connection_cb() returns NULL
seems to fix the issue.
Signed-off-by: Jukka Taimisto <jtt@xxxxxxxxxxxxxxx>
Reported-by: Tommi Mäkilä <tmakila@xxxxxxxxxxxxxxx>
Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
net/bluetooth/l2cap_sock.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -949,13 +949,16 @@ static struct l2cap_chan *l2cap_sock_new
/* Check for backlog size */
if (sk_acceptq_is_full(parent)) {
BT_DBG("backlog full %d", parent->sk_ack_backlog);
+ release_sock(parent);
return NULL;
}
sk = l2cap_sock_alloc(sock_net(parent), NULL, BTPROTO_L2CAP,
GFP_ATOMIC);
- if (!sk)
+ if (!sk) {
+ release_sock(parent);
return NULL;
+ }
bt_sock_reclassify_lock(sk, BTPROTO_L2CAP);
Patches currently in stable-queue which might be from jtt@xxxxxxxxxxxxxxx are
queue-3.10/bluetooth-fix-l2cap-deadlock.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html