* [PATCH] Bluetooth: check for zapped sk before connecting
@ 2021-03-22 6:01 Archie Pusaka
2021-03-22 15:53 ` Marcel Holtmann
0 siblings, 1 reply; 3+ messages in thread
From: Archie Pusaka @ 2021-03-22 6:01 UTC (permalink / raw)
To: linux-bluetooth, Marcel Holtmann
Cc: CrosBT Upstreaming, Archie Pusaka, syzbot+abfc0f5e668d4099af73,
Alain Michaud, Abhishek Pandit-Subedi, Guenter Roeck,
David S. Miller, Jakub Kicinski, Johan Hedberg,
Luiz Augusto von Dentz, linux-kernel, netdev
From: Archie Pusaka <apusaka@chromium.org>
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 <apusaka@chromium.org>
Reported-by: syzbot+abfc0f5e668d4099af73@syzkaller.appspotmail.com
Reviewed-by: Alain Michaud <alainm@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
---
net/bluetooth/l2cap_sock.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index f1b1edd0b697..b86fd8cc4dc1 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -182,6 +182,13 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr,
BT_DBG("sk %p", sk);
+ lock_sock(sk);
+ if (sock_flag(sk, SOCK_ZAPPED)) {
+ release_sock(sk);
+ return -EINVAL;
+ }
+ release_sock(sk);
+
if (!addr || alen < offsetofend(struct sockaddr, sa_family) ||
addr->sa_family != AF_BLUETOOTH)
return -EINVAL;
--
2.31.0.rc2.261.g7f71774620-goog
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] Bluetooth: check for zapped sk before connecting
2021-03-22 6:01 [PATCH] Bluetooth: check for zapped sk before connecting Archie Pusaka
@ 2021-03-22 15:53 ` Marcel Holtmann
2021-03-23 8:42 ` Archie Pusaka
0 siblings, 1 reply; 3+ messages in thread
From: Marcel Holtmann @ 2021-03-22 15:53 UTC (permalink / raw)
To: Archie Pusaka
Cc: linux-bluetooth, CrosBT Upstreaming, Archie Pusaka,
syzbot+abfc0f5e668d4099af73, Alain Michaud,
Abhishek Pandit-Subedi, Guenter Roeck, David S. Miller,
Jakub Kicinski, Johan Hedberg, Luiz Augusto von Dentz, LKML,
netdev
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 <apusaka@chromium.org>
> Reported-by: syzbot+abfc0f5e668d4099af73@syzkaller.appspotmail.com
> Reviewed-by: Alain Michaud <alainm@chromium.org>
> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> Reviewed-by: Guenter Roeck <groeck@chromium.org>
> ---
>
> net/bluetooth/l2cap_sock.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> index f1b1edd0b697..b86fd8cc4dc1 100644
> --- a/net/bluetooth/l2cap_sock.c
> +++ b/net/bluetooth/l2cap_sock.c
> @@ -182,6 +182,13 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr,
>
> BT_DBG("sk %p", sk);
>
> + lock_sock(sk);
> + if (sock_flag(sk, SOCK_ZAPPED)) {
> + release_sock(sk);
> + return -EINVAL;
> + }
> + release_sock(sk);
> +
hmmm. I wonder if this would look better and easy to see that the locking is done correctly.
lock_sock(sk);
zapped = sock_flag(sk, SOCK_ZAPPED);
release_sock(sk);
if (zapped)
return -EINVAL;
Regards
Marcel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Bluetooth: check for zapped sk before connecting
2021-03-22 15:53 ` Marcel Holtmann
@ 2021-03-23 8:42 ` Archie Pusaka
0 siblings, 0 replies; 3+ messages in thread
From: Archie Pusaka @ 2021-03-23 8:42 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth, CrosBT Upstreaming, syzbot+abfc0f5e668d4099af73,
Alain Michaud, Abhishek Pandit-Subedi, Guenter Roeck,
David S. Miller, Jakub Kicinski, Johan Hedberg,
Luiz Augusto von Dentz, LKML, open list:NETWORKING [GENERAL]
Hi Marcel,
Thanks for your suggestion. I implemented it in v2, please take another look.
On Mon, 22 Mar 2021 at 23:53, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> 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 <apusaka@chromium.org>
> > Reported-by: syzbot+abfc0f5e668d4099af73@syzkaller.appspotmail.com
> > Reviewed-by: Alain Michaud <alainm@chromium.org>
> > Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> > Reviewed-by: Guenter Roeck <groeck@chromium.org>
> > ---
> >
> > net/bluetooth/l2cap_sock.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> > index f1b1edd0b697..b86fd8cc4dc1 100644
> > --- a/net/bluetooth/l2cap_sock.c
> > +++ b/net/bluetooth/l2cap_sock.c
> > @@ -182,6 +182,13 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr,
> >
> > BT_DBG("sk %p", sk);
> >
> > + lock_sock(sk);
> > + if (sock_flag(sk, SOCK_ZAPPED)) {
> > + release_sock(sk);
> > + return -EINVAL;
> > + }
> > + release_sock(sk);
> > +
>
> hmmm. I wonder if this would look better and easy to see that the locking is done correctly.
>
> lock_sock(sk);
> zapped = sock_flag(sk, SOCK_ZAPPED);
> release_sock(sk);
>
> if (zapped)
> return -EINVAL;
>
> Regards
>
> Marcel
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-03-23 8:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-22 6:01 [PATCH] Bluetooth: check for zapped sk before connecting Archie Pusaka
2021-03-22 15:53 ` Marcel Holtmann
2021-03-23 8:42 ` Archie Pusaka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).