diff options
author | Ying Hsu <yinghsu@chromium.org> | 2023-01-11 03:16:14 +0000 |
---|---|---|
committer | Luiz Augusto von Dentz <luiz.von.dentz@intel.com> | 2023-01-17 15:59:02 -0800 |
commit | 1d80d57ffcb55488f0ec0b77928d4f82d16b6a90 (patch) | |
tree | 878e4f4e48bf3843f5f1ce436ea08e42fc9d38da /net/sctp/primitive.c | |
parent | 506d9b4099a0ce8249bba16b4d0b828fdcf69d9a (diff) | |
download | linux-1d80d57ffcb55488f0ec0b77928d4f82d16b6a90.tar.bz2 |
Bluetooth: Fix possible deadlock in rfcomm_sk_state_change
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: 1804fdf6e494 ("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>
Diffstat (limited to 'net/sctp/primitive.c')
0 files changed, 0 insertions, 0 deletions