CVE-2026-53256

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()<br /> <br /> rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock,<br /> but returns the selected listener after dropping that lock without<br /> taking a reference. rfcomm_connect_ind() then locks the listener,<br /> queues a child socket on it, and may notify it after unlocking it.<br /> <br /> The buggy scenario involves two paths, with each column showing the<br /> order within that path:<br /> <br /> rfcomm_connect_ind(): listener close:<br /> 1. Find parent in 1. close() enters<br /> rfcomm_get_sock_by_channel() rfcomm_sock_release().<br /> 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown()<br /> without pinning parent. closes the listener.<br /> 3. Call lock_sock(parent) and 3. rfcomm_sock_kill()<br /> bt_accept_enqueue(parent, unlinks and puts parent.<br /> sk, true).<br /> 4. Read parent flags and may 4. parent can be freed.<br /> call sk_state_change().<br /> <br /> If close wins the race, parent can be freed before<br /> rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the<br /> deferred-setup callback.<br /> <br /> Take a reference on the listener before leaving rfcomm_sk_list.lock.<br /> After lock_sock() succeeds, recheck that it is still in BT_LISTEN<br /> before queueing a child, cache the deferred-setup bit while the parent<br /> is locked, and drop the reference after the last parent use.<br /> <br /> KASAN reported a slab-use-after-free in lock_sock_nested() from<br /> rfcomm_connect_ind(), with the freeing stack going through<br /> rfcomm_sock_kill() and rfcomm_sock_release().