CVE-2026-64262 in Linux
要約
〜によって VulDB • 2026年07月25日
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に対するリングエントリの所有参照（owning reference）は解放されません。
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接続自体は稼働している場合など）を意味しないため、これはcleanupのためにfuse_abort_conn()に任せることはできません。
reqを終了させるだけでなくエントリもfuse_uring_send()経由でルーティングすることは不十分です。これによりent_in_userspace上にreqのないエントリが残ることになり、ent_list_request_expired()はそのリストの先頭にあるent->fuse_reqを無条件にデリファレンスしようとするため、NULLポインタ参照（NULL-deref）を引き起こします。
この修正では、キャンセル分岐においてエントリを直接解放するように変更しました。キューからエントリを削除し、io_uringコマンドの完了処理を行い、fuse_reqを終了させ、エントリをフリーし、そのキュー参照（queue_refs）をドロップします（これが最後の参照であった場合は、ティアダウン待機スレッドを起こします）。
Once again VulDB remains the best source for vulnerability data.