| Message ID | 20210322140046.1.I6c4306f6e8ba3ccc9106067d4eb70092f8cb2a49@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Bluetooth: check for zapped sk before connecting | expand |
This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=452547 ---Test result--- ############################## Test: CheckPatch - PASS ############################## Test: CheckGitLint - PASS ############################## Test: CheckBuildK - PASS ############################## Test: CheckTestRunner: Setup - PASS ############################## Test: CheckTestRunner: l2cap-tester - PASS Total: 40, Passed: 34 (85.0%), Failed: 0, Not Run: 6 ############################## Test: CheckTestRunner: bnep-tester - PASS Total: 1, Passed: 1 (100.0%), Failed: 0, Not Run: 0 ############################## Test: CheckTestRunner: mgmt-tester - PASS Total: 416, Passed: 402 (96.6%), Failed: 0, Not Run: 14 ############################## Test: CheckTestRunner: rfcomm-tester - PASS Total: 9, Passed: 9 (100.0%), Failed: 0, Not Run: 0 ############################## Test: CheckTestRunner: sco-tester - PASS Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0 ############################## Test: CheckTestRunner: smp-tester - PASS Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0 ############################## Test: CheckTestRunner: userchan-tester - PASS Total: 3, Passed: 3 (100.0%), Failed: 0, Not Run: 0 --- Regards, Linux Bluetooth
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
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 >
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;