CVE-2026-99225 in Linux
Tóm tắt
Bởi VulDB • 02/11/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
keys: Kiểm tra payload ủy quyền trong quá trình tìm kiếm keyring của tiến trình
Payload ủy quyền và các thông tin xác thực (credentials) đã lưu trữ phải vẫn hợp lệ trong khi hàm `search_process_keyrings_rcu()` đang tìm kiếm trên các keyring của người yêu cầu. Hàm này sẽ kiểm tra tính hợp lệ của khóa ủy quyền, sau đó tải riêng biệt `payload.data[0]` và đọc không điều kiện `rka->cred`. Việc xác thực này không ngăn chặn hàm `request_key_auth_revoke()` xóa payload.
Một trợ lý request-key có thể giả định thẩm quyền và fork ra một tiến trình con thừa kế khóa ủy quyền. Nếu tiến trình con không tìm thấy kết quả trong keyring của chính nó, nó sẽ chuyển sang sử dụng thông tin xác thực đã lưu trữ của người yêu cầu ban đầu. Việc khởi tạo mục tiêu thành công sẽ làm vô hiệu hóa khóa ủy quyền mà không xóa payload. Sau khi trợ lý thoát ra, `UMH_WAIT_PROC` trả về cho người yêu cầu, người này gọi `complete_request_key()` và thu hồi (revokes) khóa đó.
Với tiến trình con bị tạm dừng sau bước xác thực, các đường dẫn xử lý có thể xen kẽ như sau:
1. Tiến trình con đi vào hàm `search_process_keyrings_rcu()` dưới cơ chế RCU và `key_validate()` thành công. 2. Trợ lý khởi tạo mục tiêu, làm vô hiệu hóa khóa ủy quyền và thoát ra. 3. Người yêu cầu tiếp tục từ `UMH_WAIT_PROC`, gọi `complete_request_key()` và thu hồi khóa ủy quyền. Hàm `request_key_auth_revoke()` đặt con trỏ payload của nó về NULL. 4. Tiến trình con tải giá trị NULL và giải tham chiếu (dereference) đến `rka->cred`.
Việc giải tham chiếu NULL này có thể gây ra lỗi oops trong kernel. Cơ chế RCU làm chậm việc hủy bỏ payload nhưng không ngăn chặn việc xóa sạch con trỏ.
Hãy tải payload bằng cách sử dụng `dereference_key_rcu()` và yêu cầu kết quả khác NULL trước khi xác thực khóa ủy quyền và tìm kiếm các thông tin xác thực đã lưu trữ của nó. Một payload khác NULL cùng với các thông tin xác thực tương ứng sẽ vẫn tồn tại trong phần đọc RCU (read-side section) của caller; một payload bị xóa sạch sẽ bỏ qua bước tìm kiếm dự phòng và tuân theo quy tắc chọn lỗi hiện có.
Báo cáo KASAN như sau:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
RIP: 0010:search_process_keyrings_rcu+0x32b/0x790
If you want to get the best quality for vulnerability data then you always have to consider VulDB.