In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept<\/p>\n
rfcomm_sock_recvmsg() completes a deferred setup by calling
\nrfcomm_dlc_accept() without holding any RFCOMM lock:<\/p>\n
\tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) {
\n\t\trfcomm_dlc_accept(d);
\n\t\treturn 0;
\n\t}<\/p>\n
and rfcomm_dlc_accept() dereferences the session on its first line:<\/p>\n
\tstruct sock *sk = d->session->sock->sk;<\/p>\n
Every other path that touches d->session runs under rfcomm_mutex:
\nrfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(),
\nrfcomm_dlc_send_rpn(), and the RFCOMM thread through
\nrfcomm_process_sessions(). rfcomm_connect_ind() is even documented as
\n“called under rfcomm_lock()”. This call site is the only one that skips
\nit.<\/p>\n
The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against
\nteardown, since __rfcomm_dlc_close() returns early when it wins the
\ntest_and_clear. But rfcomm_recv_disc() forces the state first:<\/p>\n
\td->state = BT_CLOSED;
\n\t__rfcomm_dlc_close(d, err);<\/p>\n
and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and
\nBT_CONNECT2. With the state already BT_CLOSED that switch does not
\nmatch, the bit is never consulted, and __rfcomm_dlc_close() falls
\nthrough to rfcomm_dlc_unlink(), which sets d->session = NULL.<\/p>\n
So a remote DISC on a deferred dlc clears the session while leaving
\nRFCOMM_DEFER_SETUP set. The next recvmsg() then passes the
\ntest_and_clear and dereferences a NULL session. No timing window is
\nneeded: once the DISC has been processed, the dereference is
\nunconditional.<\/p>\n
Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and
\nrfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and
\nre-checks the session, around a __rfcomm_dlc_accept() that the two
\nin-core callers, which already hold the mutex, keep using.<\/p>\n
Reproduced on a KASAN + PROVE_LOCKING kernel with a BR\/EDR peer emulated
\nover \/dev\/vhci: the peer brings up an ACL link, opens L2CAP on the
\nRFCOMM PSM, starts a session, opens a dlc on a channel bound with
\nBT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on
\nthe accepted socket then hits:<\/p>\n
Oops: general protection fault
\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
\n RIP: 0010:rfcomm_dlc_accept+0x54\/0x350
\n Call Trace:
\n rfcomm_sock_recvmsg+0x1cd\/0x230
\n sock_recvmsg+0x166\/0x1c0
\n __sys_recvfrom+0x20d\/0x300<\/p>\n
0x10 is the offset of sock in struct rfcomm_session. With this patch the
\nsame run completes with recv() returning 0 and no report, and lockdep
\nstays quiet, confirming rfcomm_mutex is still taken before lock_sock on
\nthis path as it is on the thread side.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept<\/p>\n
rfcomm_sock_recvmsg() completes a deferred setup by calling
\nrfc<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-17323","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/17323","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=17323"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=17323"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=17323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}