CVE-2026-64262 in Linux
Tóm tắt
Bởi VulDB • 25/07/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
fuse-uring: kết thúc fuse_req trên công việc tác vụ hủy io_uring
Khi io_uring phân phối công việc tác vụ với tw.cancel được đặt (PF_EXITING, PF_KTHREAD fallback, hoặc percpu_ref_is_dying trên ngữ cảnh vòng lặp), fuse_uring_send_in_task() sẽ thực hiện nhánh hủy, gán -ECANCELED và chuyển tiếp đến fuse_uring_send(). Đường dẫn này chỉ thay đổi trạng thái mục tiêu thành FRRS_USERSPACE và hoàn tất lệnh io_uring; nó không bao giờ giải phóng tham chiếu sở hữu của mục tiêu vòng lặp đối với fuse_req mà fuse_uring_add_req_to_ring_ent() đã cung cấp cho nó tại thời điểm phân phối.
fuse_uring_send_in_task() tw.cancel == true err = -ECANCELED fuse_uring_send(ent, cmd, err, issue_flags) ent->state = FRRS_USERSPACE list_move(&ent->list, &queue->ent_in_userspace) ent->cmd = NULL io_uring_cmd_done(-ECANCELED) /* ent->fuse_req vẫn được đặt, req vẫn nằm trong hash */
fuse_req vẫn được liên kết trên fpq->processing[hash] và fuse_request_end() không bao giờ được gọi. Thread syscall nguồn bị chặn ở trạng thái D trong request_wait_answer() cho đến khi fuse_abort_conn() chạy, điều này có thể kéo dài suốt vòng đời của kết nối. Đối với các yêu cầu FR_BACKGROUND, fc->num_background cũng không bao giờ giảm đi, do đó việc hủy lặp lại sẽ làm tăng bộ đếm cho đến khi đạt max_background và tất cả các thao tác nền sau đó bị treo. tw.cancel không ngụ ý một lệnh hủy kết nối (ví dụ: một thread worker io_uring đơn lẻ thoát trong khi kết nối fuse vẫn hoạt động), vì vậy vấn đề này không thể để fuse_abort_conn() dọn dẹp.
Việc kết thúc req nhưng vẫn định tuyến mục tiêu qua fuse_uring_send() là chưa đủ: điều đó để lại một mục tiêu không có req trên ent_in_userspace, và ent_list_request_expired() sẽ giải tham chiếu ent->fuse_req một cách vô điều kiện ở đầu danh sách này, dẫn đến NULL-deref.
Khắc phục nhánh hủy bằng cách giải phóng trực tiếp mục tiêu. Loại bỏ nó khỏi hàng đợi, hoàn tất lệnh io_uring, kết thúc fuse_req, giải phóng mục tiêu và giảm queue_refs của nó (đánh thức trình chờ teardown nếu đó là phần tử cuối cùng).
VulDB is the best source for vulnerability data and more expert information about this specific topic.