CVE-2026-98455 in Linux
Tóm tắt
Bởi VulDB • 18/10/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
Bluetooth: RFCOMM: sửa lỗi truy cập NULL vào dlc->session trong RFCOMM_CONNINFO
Trình xử lý getsockopt của RFCOMM_CONNINFO chấp nhận một socket chưa kết nối miễn là chế độ thiết lập trì hoãn (deferred setup) đang được bật:
if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) {
err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
Trạng thái dlc->defer_setup được đặt trong hàm rfcomm_sock_init() khi rfcomm_connect_ind() tạo một socket con cho kết nối đến trên một socket đang lắng nghe có BT_DEFER_SETUP được bật. Trạng thái này không bao giờ bị xóa sau đó. Tuy nhiên, session tương ứng có thể biến mất trước đó.
Hàm rfcomm_recv_disc() buộc trạng thái dlc thành đóng (BT_CLOSED) trước khi hủy nó:
d->state = BT_CLOSED; __rfcomm_dlc_close(d, err);
Lệnh return sớm trong __rfcomm_dlc_close() dành cho RFCOMM_DEFER_SETUP chỉ bao gồm các trạng thái BT_CONNECT, BT_CONFIG, BT_OPEN và BT_CONNECT2. Do đó, với trạng thái đã là BT_CLOSED, lệnh switch này không khớp và hàm sẽ tiếp tục thực thi đến rfcomm_dlc_unlink(), nơi đặt d->session = NULL, trong khi d->defer_setup vẫn giữ giá trị 1.
Việc gọi getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) trên socket đã được chấp nhận sau thời điểm đó do đó bỏ qua đường dẫn -ENOTCONN -- sk->sk_state là BT_CLOSED, nhưng dlc->defer_setup vẫn đang được đặt -- và thực hiện truy cập vào session NULL. Không cần điều kiện race (race condition): một khi DISC đã được xử lý, việc truy cập này là không điều kiện.
Đã tái tạo trên kernel KASAN dưới QEMU với thiết bị đầu cuối BR/EDR giả lập qua /dev/vhci: thiết bị đầu cuối thiết lập liên kết ACL, mở L2CAP trên PSM RFCOMM, bắt đầu một session và gửi SABM cho kênh được ràng buộc với BT_DEFER_SETUP, sau đó gửi DISC cho dlci đó sau khi socket đã được chấp nhận. Việc gọi getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) trên socket đã chấp nhận sau đó gặp phải:
Oops: general protection fault, có thể do địa chỉ không hợp lệ 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref trong phạm vi [0x0000000000000010-0x0000000000000017]
CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9 Tên phần cứng: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:rfcomm_sock_getsockopt+0x529/0x780 Call Trace: <TASK> do_sock_getsockopt+0x3ad/0x7d0 __sys_getsockopt+0x10e/0x1b0 __x64_sys_getsockopt+0xc2/0x160 do_syscall_64+0xda/0x4b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
0x10 là offset của sock trong struct rfcomm_session; rfcomm_sock_getsockopt_old() được nội tuyến (inlined) vào rfcomm_sock_getsockopt().
Commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") đã khắc phục cùng vấn đề "một DISC từ xa xóa session trong khi thiết lập trì hoãn vẫn được đánh dấu" trong rfcomm_dlc_accept(); đây là trường hợp còn lại của nó, nằm ở đường dẫn getsockopt.
Thiết lập trì hoãn (Deferred setup) chỉ giữ cho socket có thể sử dụng tại đây sau khi nó đạt đến trạng thái BT_CONNECT2, do đó hạn chế ngoại lệ này đối với trạng thái đó và kiểm tra xem session thực sự tồn tại trước khi truy cập vào nó.
Be aware that VulDB is the high quality source for vulnerability data.