In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO<\/p>\n
The RFCOMM_CONNINFO getsockopt handler accepts a socket that is not
\nconnected as long as deferred setup is enabled:<\/p>\n
\tif (sk->sk_state != BT_CONNECTED &&
\n\t\t\t\t!rfcomm_pi(sk)->dlc->defer_setup) {
\n\t\terr = -ENOTCONN;
\n\t\tbreak;
\n\t}
\n\tl2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;<\/p>\n
dlc->defer_setup is set in rfcomm_sock_init() when rfcomm_connect_ind()
\ncreates a child socket for an incoming connection on a listening socket
\nthat has BT_DEFER_SETUP enabled. It is never cleared afterwards. The
\nsession, however, can go away underneath it.<\/p>\n
rfcomm_recv_disc() forces the dlc state before tearing it down:<\/p>\n
\td->state = BT_CLOSED;
\n\t__rfcomm_dlc_close(d, err);<\/p>\n
The RFCOMM_DEFER_SETUP early return in __rfcomm_dlc_close() only covers
\nBT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2, so with the state
\nalready BT_CLOSED that switch does not match and the function falls
\nthrough to rfcomm_dlc_unlink(), which sets d->session = NULL, while
\nd->defer_setup stays 1.<\/p>\n
A getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket after
\nthat point therefore skips the -ENOTCONN path — sk->sk_state is
\nBT_CLOSED, but dlc->defer_setup is still set — and dereferences the
\nNULL session. No race is needed: once the DISC has been processed, the
\ndereference is unconditional.<\/p>\n
Reproduced on a KASAN kernel under QEMU with a BR\/EDR peer emulated over
\n\/dev\/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM
\nPSM, starts a session and sends SABM for a channel bound with
\nBT_DEFER_SETUP, and sends DISC for that dlci after the socket has been
\naccepted. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted
\nsocket then hits:<\/p>\n
Oops: general protection fault, probably for non-canonical address
\n 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
\n CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9
\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
\n RIP: 0010:rfcomm_sock_getsockopt+0x529\/0x780
\n Call Trace:<\/p>\n
do_sock_getsockopt+0x3ad\/0x7d0
\n __sys_getsockopt+0x10e\/0x1b0
\n __x64_sys_getsockopt+0xc2\/0x160
\n do_syscall_64+0xda\/0x4b0
\n entry_SYSCALL_64_after_hwframe+0x77\/0x7f<\/p>\n
0x10 is the offset of sock in struct rfcomm_session;
\nrfcomm_sock_getsockopt_old() is inlined into rfcomm_sock_getsockopt().<\/p>\n
Commit 43a556b2fd43 (“Bluetooth: RFCOMM: take rfcomm_mutex for the
\ndeferred setup accept”) fixed the same “a remote DISC clears the session
\nwhile deferred setup is still flagged” problem in rfcomm_dlc_accept();
\nthis is the remaining instance of it, in the getsockopt path.<\/p>\n
Deferred setup only leaves a socket usable here once it has reached
\nBT_CONNECT2, so restrict the exception to that state and check that a
\nsession is actually present before following it.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO<\/p>\n
The RFCOMM_CONNINFO getsockopt handler accepts a socket<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-40927","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/40927","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=40927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=40927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=40927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}