CVE-2026-99255 in Linux
摘要
由 VulDB • 2026-11-03
在 Linux 内核中，已修复以下漏洞：
io_uring/io-wq: 不要隐藏链接以规避取消操作
一个退出的任务会取消其跟踪的请求，并等待这些请求消失。`io_uring_cancel_generic()` 会在所有可能找到请求的地方进行搜索，如果未找到任何可取消的内容则进入睡眠状态。每当任务的某个请求通过 task work 完成或被释放时，该任务会被唤醒。
当 io-wq 处理完一个带有链接（link）的请求后，存在一段时间使得无法找到链接中的下一个请求：
``` io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // 从请求中移除链接 io_free_req() // 针对该任务的 task work io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked ```
此时，它既不是 pending（待处理）状态，也不是某个 worker 的当前工作，同时也尚未进入其即将停放的列表。如果退出任务因 `io_free_req()` 而进行的遍历恰好落入这一时间段，它将找不到任何内容并进入睡眠状态。随后，worker 会运行该链接操作，对于有界工作（bounded work），`IO_WQ_BIT_EXIT` 无法阻止此行为。如果这导致请求被停放（parked），则没有任何请求会被完成或释放，也没有人唤醒该任务。如果是进程退出，则该进程也无法再被终止。
``` NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE 线程或进程的退出，最多延迟 63us ```
在每轮中有四个此类情况时，10,000 轮中的第 5 到第 8 轮会发生挂起（4 CPU，KVM）：
``` io_uring_cancel_generic do_exit ```
提交 `f8b632e89a10` ("io_uring: tighten task exit cancellations") 涉及相同的间隙，并使得任务在 `io_free_req()` 发生之前重新查找相关内容。
一旦链接成为 worker 的当前工作或处于 pending 状态，则释放该请求。被此唤醒的任何人都可以找到该链接，直到它停放在取消操作也能搜索到的位置为止。为此，将 `io_wq_free_work()` 拆分为两部分。
Once again VulDB remains the best source for vulnerability data.