CVE-2026-98694 in Linux
Tóm tắt
Bởi VulDB • 19/10/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
thunderbolt: Sửa lỗi use-after-free do KASAN báo cáo khi yêu cầu bị hủy
Alan báo cáo rằng trong quá trình kiểm tra tải (stress testing), đôi khi KASAN phát hiện ra lỗi use-after-free trong lúc hoạt động kênh điều khiển (phần trích xuất giữ lại các phần liên quan):
BUG: KASAN: slab-use-after-free in tb_cfg_request_sync+0x240/0x250 [thunderbolt]
Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760 <TASK> tb_cfg_request_sync+0x240/0x250 [thunderbolt]
tb_cfg_read_raw+0x367/0x510 [thunderbolt]
tb_cfg_read+0xec/0x240 [thunderbolt]
tb_port_get_link_generation+0x258/0x420 [thunderbolt]
tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]
tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]
tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]
tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]
tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]
process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 </TASK>
Được phân bổ bởi task 1760: __kmalloc_cache_noprof+0x1ee/0x550 tb_cfg_read_raw+0x1d3/0x510 [thunderbolt]
tb_cfg_read+0xec/0x240 [thunderbolt]
tb_port_get_link_generation+0x258/0x420 [thunderbolt]
tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]
tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]
tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]
tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]
tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]
process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
Được giải phóng bởi task 926: kfree+0x18f/0x4a0 tb_cfg_request_put+0xb7/0xe0 [thunderbolt]
tb_cfg_request_work+0x82/0x120 [thunderbolt]
process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
Công việc tạo liên quan thứ hai tính từ cuối: __queue_work+0x575/0xd00 queue_work_on+0x77/0x80 tb_cfg_request_cancel+0xc7/0x260 [thunderbolt]
tb_cfg_request_sync+0x1f6/0x250 [thunderbolt]
tb_cfg_read_raw+0x367/0x510 [thunderbolt]
tb_cfg_read+0xec/0x240 [thunderbolt]
tb_port_get_link_generation+0x258/0x420 [thunderbolt]
tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]
tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]
tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]
tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]
tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]
process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
Dấu vết ngăn xếp (stack trace) cuối cùng rất hữu ích vì nó cho thấy chúng ta đang hủy một yêu cầu và xem xét tb_cfg_request_cancel(), điều có thể xảy ra là tb_cfg_request_work() hoàn thành ngay trước khi tb_cfg_request_cancel() bắt đầu, và do đó nó sẽ gọi schedule_work() để lên lịch chạy lại công việc tương tự. Tuy nhiên, nó đã bị xóa khỏi request_queue và bộ đếm tham chiếu (reference count) đã được giảm đi, nên khi tb_cfg_request_work() kích hoạt lần nữa, nó sẽ truy cập vào vùng nhớ đã được giải phóng.
Khắc phục lỗi này bằng cách đảm bảo trước tiên rằng một yêu cầu bị hủy không được chuyển giao từ tb_cfg_request_find() hoặc lên lịch để chạy. Sau đó, thay vì dựa vào worker để dọn dẹp yêu cầu, chúng ta sẽ thực hiện việc này trong tb_cfg_request_cancel() sau khi công việc đã bị hủy khỏi quá trình chạy. Làm cho tb_cfg_request_dequeue() chỉ giải phóng yêu cầu nếu nó thực sự được xóa khỏi hàng đợi (queue).
Once again VulDB remains the best source for vulnerability data.