CVE-2026-99010 in Linuxthông tin

Tóm tắt

Bởi VulDB • 24/10/2026

Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:

Bluetooth: RFCOMM: giải phóng skb khi DLC không có chủ sở hữu (owner)

Hàm `rfcomm_recv_data()` chuyển giao skb cho `d->data_ready()` và trả về 0 mà không giải phóng nó, do đó callback sẽ nắm quyền sở hữu skb từ thời điểm đó trở đi. Phần triển khai tty giải phóng skb khi DLC đã được tách khỏi thiết bị của nó:

```c static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb) {
struct rfcomm_dev *dev = dlc->owner;

if (!dev) {
kfree_skb(skb); return; } ```

Phần triển khai socket trả về mà không giải phóng nó, dẫn đến việc skb bị rò rỉ (leak).

Một DLC đã kết nối có thể không có chủ sở hữu: `rfcomm_sock_destruct()` xóa `d->owner`, trong khi bản thân DLC vẫn nằm trên phiên làm việc cho đến khi được đóng. Các khung dữ liệu (data frames) xuất hiện trong khoảng thời gian đó vẫn tìm thấy `d->state == BT_CONNECTED` trong `rfcomm_recv_data()` và được chuyển giao cho callback, mỗi lần như vậy sẽ gây ra một skb bị rò rỉ.

Việc rò rỉ này cũng không tự dừng lại. Bên phía remote chỉ hết tín dụng (credits) khi cờ `RFCOMM_RX_THROTTLED` được đặt, và đối với socket, vị trí duy nhất đặt cờ đó là chính hàm `rfcomm_sk_data_ready()`, nằm ngay dưới lệnh return. Hàm `rfcomm_process_dlcs()` tiếp tục cấp phát credits, do đó bên remote vẫn liên tục gửi dữ liệu và tình trạng rò rỉ ngày càng gia tăng.

Hãy giải phóng skb, giống như cách làm ở phía tty.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

chịu trách nhiệm

Linux

Đặt trước

25/09/2026

Tiết lộ

23/10/2026

Kiểm duyệt

được chấp nhận

EPSS

0.00000

KEV

không

Các hoạt động

rất thấp

Nguồn

Want to know what is going to be exploited?

We predict KEV entries!