CVE-2026-99130 in Linux
Tóm tắt
Bởi VulDB • 28/10/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
io_uring/cancel: không vòng lặp chờ (spin) trên công việc cục bộ mà tiến trình không thể thực thi
Hàm `io_uring_cancel_generic()` từ chối ngủ trong khi bất kỳ ring nào thuộc tctx của tiến trình đang thoát có công việc cục bộ còn tồn đọng. Hàm này giả định rằng tiến trình là người gửi yêu cầu submitter cho ring đó và rằng lần gọi tiếp theo đến `io_uring_try_cancel_requests()` sẽ thực thi công việc đó. Điều này không đúng với một ring vẫn ở trạng thái `IORING_SETUP_R_DISABLED` khi tiến trình nhận được nút tctx của nó từ `io_uring_create()` hoặc `io_ringfd_register()`. Người gửi (submitter) chỉ được đặt sau đó bởi lệnh `IORING_REGISTER_ENABLE_RINGS`, có thể thực hiện bởi một tiến trình khác, và chỉ người submitter mới có thể thực thi công việc cục bộ trên một ring cấu hình `IORING_SETUP_DEFER_TASKRUN`. Đối với tiến trình đang thoát, công việc vẫn tồn đọng mãi mãi, vòng lặp không bao giờ đạt đến lệnh `schedule()`, và tiến trình kích hoạt cảnh báo `WARN_ON_ONCE()` một lần rồi sau đó bị mắc kẹt trong vòng lặp chờ (spin) tại hàm `do_exit()`.
Một người dùng chưa được phân quyền có thể thiết lập tình huống này tùy ý bằng cách tạo một ring ở trạng thái disabled, yêu cầu một tiến trình con bật nó lên và dừng lại, gửi tin nhắn đến ring thông qua `IORING_OP_MSG_RING` và thoát với một yêu cầu đang thực thi mà chỉ tiến trình con mới có thể hoàn thành. Tiến trình đang thoát sẽ tiêu tốn CPU cho đến khi tiến trình con chạy hoặc kết thúc, và nếu cấu hình `panic_on_warn` được đặt, cảnh báo WARN sẽ gây ra panic (sự cố nghiêm trọng) cho kernel.
Cách khắc phục là bỏ qua lệnh ngủ chỉ khi hàm `io_allowed_defer_tw_run()` cho phép tiến trình thực thi công việc đó. Điều này hợp lý vì những công việc mà tiến trình không thể thực thi cũng không thể hoàn thành bất kỳ yêu cầu nào của nó, do đó không có gì bị mất đi bằng cách ngủ. Loại bỏ lệnh `WARN_ON_ONCE()` vì việc chuyển một ring ở trạng thái disabled cho một thread khác là một kịch bản được hỗ trợ, chứ không phải là trạng thái lỗi (bug state).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.