CVE-2026-99253 in Linux
Tóm tắt
Bởi VulDB • 03/11/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
io_uring/cancel: kích hoạt lại việc đánh thức công việc cục bộ trước khi ngủ
Hàm `io_uring_try_cancel_requests()` đặt biến `->cq_wait_nr` thành 1 để nhiệm vụ đang hủy bỏ (`cancelling task`) sẽ được đánh thức bởi lần gọi tiếp theo đến `io_req_local_work_add()`. Chỉ có lệnh thêm (add) làm cho bộ đếm về 0 mới thực hiện việc đánh thức; các lệnh thêm sau đó thấy bộ đếm <= 0 và trả về. Tuy nhiên, hàm `io_uring_cancel_generic()` chỉ chuyển sang trạng thái `TASK_INTERRUPTIBLE` ở một thời điểm muộn hơn nhiều, do đó lần đánh thức duy nhất có thể bị lãng phí cho một nhiệm vụ đang chạy. Điều này ổn miễn là mục của lệnh thêm đó vẫn còn được xếp hàng (queued), vì kiểm tra `io_local_work_pending()` khi đó sẽ bỏ qua bước ngủ. Tuy nhiên, điều này không đúng nếu việc thêm đã bị trì hoãn sau khi mục nhập của nó được đưa vào hàng đợi:
CPU0 (người gửi trong exec hoặc exit) CPU1 (`io_req_local_work_add`) mpscq_push(req A) `io_uring_try_cancel_requests()` `io_run_local_work()` // chạy req A `io_uring_try_cancel_requests()` `atomic_set(&ctx->cq_wait_nr, 1)` `atomic_read(&ctx->cq_wait_nr) == 1` count taken, `wake_up_state()` // task is running, no-op `prepare_to_wait(TASK_INTERRUPTIBLE)` `io_local_work_pending() == false` `scheduled()` mpscq_push(req B) cq_wait_nr <= 0, return
Chỉ có nhiệm vụ đang ngủ mới có thể chạy req B, do đó nó bị mắc kẹt trong `execve()` cho đến khi một tín hiệu xảy ra để đánh thức nó. Một nhiệm vụ đang thoát (exiting task) thậm chí còn không nhận được điều đó.
Kích hoạt lại bộ đếm ngay sau khi trạng thái nhiệm vụ đã được đặt và trước khi kiểm tra danh sách công việc, đối với các vòng lặp mà nhiệm vụ này là người sẽ thực thi công việc cục bộ.
If you want to get best quality of vulnerability data, you may have to visit VulDB.