From: Archie Pusaka <[email protected]>
There is a possibility of receiving a zapped sock on
l2cap_sock_connect(). This could lead to interesting crashes, one
such case is tearing down an already tore l2cap_sock as is happened
with this call trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0xc4/0x118 lib/dump_stack.c:56
register_lock_class kernel/locking/lockdep.c:792 [inline]
register_lock_class+0x239/0x6f6 kernel/locking/lockdep.c:742
__lock_acquire+0x209/0x1e27 kernel/locking/lockdep.c:3105
lock_acquire+0x29c/0x2fb kernel/locking/lockdep.c:3599
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:137 [inline]
_raw_spin_lock_bh+0x38/0x47 kernel/locking/spinlock.c:175
spin_lock_bh include/linux/spinlock.h:307 [inline]
lock_sock_nested+0x44/0xfa net/core/sock.c:2518
l2cap_sock_teardown_cb+0x88/0x2fb net/bluetooth/l2cap_sock.c:1345
l2cap_chan_del+0xa3/0x383 net/bluetooth/l2cap_core.c:598
l2cap_chan_close+0x537/0x5dd net/bluetooth/l2cap_core.c:756
l2cap_chan_timeout+0x104/0x17e net/bluetooth/l2cap_core.c:429
process_one_work+0x7e3/0xcb0 kernel/workqueue.c:2064
worker_thread+0x5a5/0x773 kernel/workqueue.c:2196
kthread+0x291/0x2a6 kernel/kthread.c:211
ret_from_fork+0x4e/0x80 arch/x86/entry/entry_64.S:604
Signed-off-by: Archie Pusaka <[email protected]>
Reported-by: [email protected]
Reviewed-by: Alain Michaud <[email protected]>
Reviewed-by: Abhishek Pandit-Subedi <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
---
Changes in v2:
* Modify locking order for better visibility
net/bluetooth/l2cap_sock.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index f1b1edd0b697..c99d65ef13b1 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -179,9 +179,17 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr,
struct l2cap_chan *chan = l2cap_pi(sk)->chan;
struct sockaddr_l2 la;
int len, err = 0;
+ bool zapped;
BT_DBG("sk %p", sk);
+ lock_sock(sk);
+ zapped = sock_flag(sk, SOCK_ZAPPED);
+ release_sock(sk);
+
+ if (zapped)
+ return -EINVAL;
+
if (!addr || alen < offsetofend(struct sockaddr, sa_family) ||
addr->sa_family != AF_BLUETOOTH)
return -EINVAL;
--
2.31.0.291.g576ba9dcdaf-goog
Hi Archie,
> There is a possibility of receiving a zapped sock on
> l2cap_sock_connect(). This could lead to interesting crashes, one
> such case is tearing down an already tore l2cap_sock as is happened
> with this call trace:
>
> __dump_stack lib/dump_stack.c:15 [inline]
> dump_stack+0xc4/0x118 lib/dump_stack.c:56
> register_lock_class kernel/locking/lockdep.c:792 [inline]
> register_lock_class+0x239/0x6f6 kernel/locking/lockdep.c:742
> __lock_acquire+0x209/0x1e27 kernel/locking/lockdep.c:3105
> lock_acquire+0x29c/0x2fb kernel/locking/lockdep.c:3599
> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:137 [inline]
> _raw_spin_lock_bh+0x38/0x47 kernel/locking/spinlock.c:175
> spin_lock_bh include/linux/spinlock.h:307 [inline]
> lock_sock_nested+0x44/0xfa net/core/sock.c:2518
> l2cap_sock_teardown_cb+0x88/0x2fb net/bluetooth/l2cap_sock.c:1345
> l2cap_chan_del+0xa3/0x383 net/bluetooth/l2cap_core.c:598
> l2cap_chan_close+0x537/0x5dd net/bluetooth/l2cap_core.c:756
> l2cap_chan_timeout+0x104/0x17e net/bluetooth/l2cap_core.c:429
> process_one_work+0x7e3/0xcb0 kernel/workqueue.c:2064
> worker_thread+0x5a5/0x773 kernel/workqueue.c:2196
> kthread+0x291/0x2a6 kernel/kthread.c:211
> ret_from_fork+0x4e/0x80 arch/x86/entry/entry_64.S:604
>
> Signed-off-by: Archie Pusaka <[email protected]>
> Reported-by: [email protected]
> Reviewed-by: Alain Michaud <[email protected]>
> Reviewed-by: Abhishek Pandit-Subedi <[email protected]>
> Reviewed-by: Guenter Roeck <[email protected]>
> ---
>
> Changes in v2:
> * Modify locking order for better visibility
>
> net/bluetooth/l2cap_sock.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel