-
Notifications
You must be signed in to change notification settings - Fork 1
[PW_SID:1031538] [RFC,v2] Bluetooth: sco: Serialize state check in sco_sock_connect to fix UAF #3207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: workflow
Are you sure you want to change the base?
Conversation
This patch adds workflow files for ci: [sync.yml] - The workflow file for scheduled work - Sync the repo with upstream repo and rebase the workflow branch - Review the patches in the patchwork and creates the PR if needed [ci.yml] - The workflow file for CI tasks - Run CI tests when PR is created Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Concurrent sco_sock_connect() calls could race on the same socket since the
state checks (BT_OPEN/BT_BOUND) were done without holding the socket lock.
This allowed two parallel connects to proceed and end up binding two
separate sco_conn objects to the same sk. Later, when sk->conn had been
updated to point to the second conn, closing the socket could free the
second conn and the socket, while the first conn's connect confirm path
still referenced the stale sk/conn, triggering a KASAN use-after-free.
Fix by taking lock_sock(sk) before checking sk->sk_state and sk->sk_type,
performing the destination address assignment under the lock, and releasing
it before invoking sco_connect() (which will acquire the lock as needed).
This serializes concurrent connect attempts for the same sk and prevents the
interleaving that caused the double-attachment and subsequent UAF.
Thread 1: Thread 2: Thread3:
check sk_state check sk_state
sco_sock_connect(sk) sco_sock_connect(sk) sco_connect_cfm(sk->conn)
conn1->sk = sk
conn2->sk = sk
sk->conn = conn1
sk->conn = conn2
sco_sock_release
free conn2 and sk
sco_connect_cfm
sco_conn_del
sco_conn_free
UAF on sk
The representative KASAN report excerpt:
BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:94
...
Write of size 8 at addr ffff88810d2be350 by task kworker/u25:1/88
...
Call Trace:
sco_conn_free net/bluetooth/sco.c:94 [inline]
kref_put include/linux/kref.h:65 [inline]
sco_conn_put+0x49d/0xfc0 net/bluetooth/sco.c:115
sco_conn_del+0x46d/0x8d0 net/bluetooth/sco.c:280
sco_connect_cfm+0x83d/0x1ee0 net/bluetooth/sco.c:1468
hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline]
...
Allocated by task 294:
...
sco_sock_create+0x22d/0xc00 net/bluetooth/sco.c:616
...
Freed by task 295:
__sk_destruct+0x4b0/0x630 net/core/sock.c:2373
sock_put include/net/sock.h:1962 [inline]
sco_sock_kill+0x64d/0x9b0 net/bluetooth/sco.c:526
sco_sock_release+0x770/0xa50 net/bluetooth/sco.c:1359
...
|
CheckPatch |
|
GitLint |
|
SubjectPrefix |
|
BuildKernel |
|
CheckAllWarning |
|
CheckSparse |
|
BuildKernel32 |
|
TestRunnerSetup |
|
TestRunner_l2cap-tester |
|
TestRunner_iso-tester |
|
TestRunner_bnep-tester |
|
TestRunner_mgmt-tester |
|
TestRunner_rfcomm-tester |
|
TestRunner_sco-tester |
|
TestRunner_ioctl-tester |
|
TestRunner_mesh-tester |
|
TestRunner_smp-tester |
|
TestRunner_userchan-tester |
|
IncrementalBuild |
dbdc24e to
7b93eea
Compare
8eabaf6 to
b7ba526
Compare
Concurrent sco_sock_connect() calls could race on the same socket since the
state checks (BT_OPEN/BT_BOUND) were done without holding the socket lock.
This allowed two parallel connects to proceed and end up binding two
separate sco_conn objects to the same sk. Later, when sk->conn had been
updated to point to the second conn, closing the socket could free the
second conn and the socket, while the first conn's connect confirm path
still referenced the stale sk/conn, triggering a KASAN use-after-free.
Fix by taking lock_sock(sk) before checking sk->sk_state and sk->sk_type,
performing the destination address assignment under the lock, and releasing
it before invoking sco_connect() (which will acquire the lock as needed).
This serializes concurrent connect attempts for the same sk and prevents the
interleaving that caused the double-attachment and subsequent UAF.
Thread 1: Thread 2: Thread3:
check sk_state check sk_state
sco_sock_connect(sk) sco_sock_connect(sk) sco_connect_cfm(sk->conn)
conn1->sk = sk
conn2->sk = sk
sk->conn = conn1
sk->conn = conn2
sco_sock_release
free conn2 and sk
sco_connect_cfm
sco_conn_del
sco_conn_free
UAF on sk
The representative KASAN report excerpt:
BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:94
...
Write of size 8 at addr ffff88810d2be350 by task kworker/u25:1/88
...
Call Trace:
sco_conn_free net/bluetooth/sco.c:94 [inline]
kref_put include/linux/kref.h:65 [inline]
sco_conn_put+0x49d/0xfc0 net/bluetooth/sco.c:115
sco_conn_del+0x46d/0x8d0 net/bluetooth/sco.c:280
sco_connect_cfm+0x83d/0x1ee0 net/bluetooth/sco.c:1468
hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline]
...
Allocated by task 294:
...
sco_sock_create+0x22d/0xc00 net/bluetooth/sco.c:616
...
Freed by task 295:
__sk_destruct+0x4b0/0x630 net/core/sock.c:2373
sock_put include/net/sock.h:1962 [inline]
sco_sock_kill+0x64d/0x9b0 net/bluetooth/sco.c:526
sco_sock_release+0x770/0xa50 net/bluetooth/sco.c:1359
...
v2: Try to resolve the issue of incorrect lock usage.
Signed-off-by: Cen Zhang zzzccc427@gmail.com
net/bluetooth/sco.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)