CVE-2026-98166 in Linux
Tóm tắt
Bởi VulDB • 06/10/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
drm/ttm: sửa lỗi tài nguyên bị swap ra không bao giờ rời khỏi phạm vi bulk_move của chúng
Hàm ttm_tt_swapout() trả về số trang đã được swap thành công và một mã lỗi âm khi thất bại; đối với một ttm có dữ liệu (populated), nó không bao giờ trả về 0. Commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") đã di chuyển việc quản lý bulk_move trong ttm_bo_swapout_cb() vào bên trong điều kiện "if (!ret)", do đó cặp hàm ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() bị bỏ qua trong mọi lần swap thành công. Thay đổi tương tự cho shrinker trong commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") kiểm tra "lret > 0", đây cũng là hành vi dự định ban đầu.
Trước b2ed01e7ad3d, tài nguyên được lấy ra khỏi bulk_move trước khi swap; kể từ đó, một tài nguyên bị swap vẫn nằm trong phạm vi bulk_move của BO (và trên LRU của manager) mặc dù nó không thể evictable. Khi nó sau đó được giải phóng hoặc BO rời khỏi bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() thông qua amdgpu_vm_bo_del()), hàm ttm_resource_del_bulk_move() bỏ qua nó do guard !ttm_resource_unevictable(), khiến một điểm cuối của phạm vi trong pos->first / pos->last trỏ đến bộ nhớ đã được giải phóng. Lệnh gọi tiếp theo tới ttm_lru_bulk_move_tail() hoặc ttm_resource_add_bulk_move() trên con trỏ đó là lỗi use-after-free, xuất hiện dưới dạng cảnh báo resv (WARN) trong ttm_lru_bulk_move_add(), "list_del corruption" trong ttm_resource_move_to_lru_tail() hoặc một NULL dereference trong ttm_resource_manager_next() -- vài phút đến vài giờ sau khi hibernate, hoặc tại thời điểm thoát tiến trình / khởi động lại sau đó. Phân tích của Samuel Ainsworth về vấn đề drm/amd 5387 (xem Link) đã xác định con trỏ treo; việc thiếu loại bỏ ở thời điểm swap là lý do khiến nó bị treo.
Kiểm tra điều kiện thành công khôi phục hành vi loại bỏ. Trên một AMD Phoenix APU (ASUS UM3406GA, gfx1103) chạy chế độ suspend-then-hibernate trên kernel ổn định 7.0.y có chứa backport (Ubuntu 7.0.0-31), lỗi này đã gây crash trong 5/18 chu kỳ hibernation; một profile hàm của một lần hibernation cho thấy 336 lệnh gọi ttm_tt_swapout() và không có lệnh gọi nào tới ttm_resource_del_bulk_move_unevictable(). Với thay đổi này, việc loại bỏ xảy ra với mọi tài nguyên bị swap và 12 chu kỳ tiếp theo diễn ra sạch sẽ.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.