原文

Linuxカーネルにおいて、以下の脆弱性が修正されました。Bluetoothに関するもので、l2cap_sock_cleanup_listen()とl2cap_conn_del()間のUse-After-Free（UAF）に関する修正です。bt_accept_dequeue()は、まだ受け入れられていない子ソケットを親のacceptキューから切り離し、リターン前にrelease_sock()を呼び出します。そのため、戻り値のskは呼び出し元の参照を持たず、ロックが解除された状態になります。l2cap_sock_cleanup_listen()は、リスニングソケットのクローズ時にこれらの子ソケットを処理します。一方で、並行して発生するHCI切断によりhci_rx_work -＞ l2cap_conn_del()が呼ばれ、l2cap_chan_del()およびl2cap_sock_kill()が実行され、子ソケットとそのl2capチャネルが解放されます。cleanup_listen()はその後、これら解放済みのオブジェクトを使用してしまいます。BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close 解放元: l2cap_conn_del -＞ l2cap_sock_close_cb -＞ l2cap_sock_kill。この問題は、この領域で既に行われている2つの修正とは異なります。コミットe83f5e24da741（"Bluetooth: serialize accept_q access"）はaccept_qのリスト/ポーリングを直列化し、bt_accept_dequeue()内で一時的参照を取得しています。また、CVE-2025-39860ではl2cap_sock_release()でlock_sock()のもとにcleanup_listen()を呼び、ユーザースペースのclose()/accept()競合を直列化しています。しかしどちらもhci_rx_workから実行されるl2cap_conn_del()はカバーしておらず、このUAFは現行のbluetooth/masterブランチ上で再現可能でした。ソース側で参照を取得する部分は、bt_accept_dequeue()がskをロックした状態でsock_hold()を行い、その後release_sock()を呼び出すことです。呼び出し元はsock_put()を行います。cleanup_listen()は子skを短時間ロックした状態でl2cap_chan_hold_unless_zero()によりチャネルを固定し（l2cap_sock_teardown_cb()との直列化を図り）、その後l2cap_chan_lock()の前にロックを解除し、SOCK_DEAD状態に対する重複したl2cap_sock_kill()をスキップします。conn-＞lockは取得せず、cleanup_listen()は親skロック下で実行されるため、conn-＞lock -＞ chan-＞lock -＞ sk_lockのデッドロックを避けています。KASAN/SMP環境において、権限のないリスニング/クローズとHCI切断の競合は、この修正前には1回の実行あたり12件のUse-After-Freeレポートを生成していました。しかしこの修正後は、bluetooth/masterブランチ上で1600回以上の競合試行にもかかわらず0件のレポートとなり、かつlockdepレポートも発生していません。