CVE-2026-64262 in Linux
摘要
由 VulDB • 2026-07-26
在 Linux 内核中，已修复以下漏洞：
fuse-uring: 在处理 io-uring 取消任务工作时结束 fuse_req
当 io_uring 交付带有 tw.cancel 标志设置的任务工作（即 PF_EXITING、PF_KTHREAD 回退机制，或环上下文上的 percpu_ref_is_dying）时，fuse_uring_send_in_task() 会进入取消分支，分配 -ECANCELED 错误码，并继续执行 fuse_uring_send()。该路径仅将条目状态翻转为 FRRS_USERSPACE 并完成 io_uring 命令；它从未释放由 fuse_uring_add_req_to_ring_ent() 在分发时交给环条目的对 fuse_req 的所有权引用。
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 仍被设置，req 仍在哈希表中 */
fuse_req 仍然链接在 fpq->processing[hash] 上，且从未调用 fuse_request_end()。发起系统调用的线程在 request_wait_answer() 中以 D-state（不可中断睡眠状态）阻塞，直到运行 fuse_abort_conn()，这可能会持续整个连接的生命周期。对于 FR_BACKGROUND 请求，fc->num_background 也永远不会递减，因此重复的取消操作会使计数器膨胀，直至达到 max_background 限制，导致所有后续后台操作停滞。tw.cancel 并不隐含连接中止（例如，单个 io_uring 工作线程退出而 fuse 连接保持活跃），因此不能将此清理任务留给 fuse_abort_conn() 处理。
仅结束 req 但仍通过 fuse_uring_send() 路由条目是不够的：这会在 ent_in_userspace 上留下一个没有关联 req 的条目，且 ent_list_request_expired() 会无条件地解引用该列表头部的 ent->fuse_req，从而导致 NULL 指针解引用错误。
修复取消分支以直接释放条目。将其从队列中移除，完成 io_uring 命令，结束 fuse_req，释放条目，并减少其 queue_refs（如果这是最后一个引用，则唤醒拆除等待者）。
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.