Ying Hsu 17511bd848 Bluetooth: Fix possible deadlock in rfcomm_sk_state_change ... [ Upstream commit 1d80d57ffc ] syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow: rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock() rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk) This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes. Reported-by: syzbot+d7ce59...@syzkaller.appspotmail.com Fixes: 1804fdf6e4 ("Bluetooth: btintel: Combine setting up MSFT extension") Link: https://syzkaller.appspot.com/bug?extid=d7ce59b06b3eb14fd218 [1] Signed-off-by: Ying Hsu <yinghsu@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>		2023-02-01 08:34:22 +01:00
..
core.c	Bluetooth: RFCOMM: don't call kfree_skb() under spin_lock_irqsave()	2022-12-31 13:32:29 +01:00
Kconfig
Makefile
sock.c	Bluetooth: Fix possible deadlock in rfcomm_sk_state_change	2023-02-01 08:34:22 +01:00
tty.c	Driver core changes for 6.1-rc1	2022-10-07 17:04:10 -07:00