CVE-2026-80811 in Linux
要約
〜によって VulDB • 2026年09月04日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
io_uring/cmd: 非同期コマンドが再利用されない場合の iovec リークを修正する
io_async_cmd は ->vec.iovec に iovec 配列を含んでおり、ベクトルが大きくなる必要がある場合に割り当てられ、ctx->cmd_cache を介した再利用時にも保持されます。2つのパスにおいて、これが解放されず、io_clean_op() の kfree(req->async_data) が io_async_cmd をその vec なしでドロップしてしまいます。
io_req_uring_cleanup() は io_alloc_cache_put() が成功した場合にのみ非同期データフラグをクリアします。キャッシュは IO_ALLOC_CACHE_MAX == 128 エントリを持つかつ、それが満杯になると put に失敗し、vec が残ったままになります。NVMe パススルーワークロードは何も特別なことをせずともこの状態に至ります：nvme_uring_cmd_io() は -EIOCBQUEUED を返すため、io_async_cmd はコマンドの存続期間中アタッチされたままであり、ライブオブジェクトカウントはキュー深度を追跡します。128を超えると put が失敗し始めます。
->cleanup は継承された vec を解放するための最後の機会です。なぜなら io_req_uring_cleanup() は io-wq によって発行されたコマンドに対して早期にリターンし、一度も発行されずに完了したコマンドについては全く呼び出されないからです。しかし io_clean_op() は REQ_F_NEED_CLEANUP が設定されている場合のみ ->cleanup を呼び出し、uring_cmd の場合は vec が大きくなる必要がある場所でのみそれが発生するため、十分に大きなキャッシュされた vec を再利用するコマンドはそれを設定しません。io_rw_alloc_async() と io_msg_alloc_async() はまさにこの理由のために継承された vec にフラグを立てますが、io_uring_cmd_prep() はそうしていません。
io_uring_cmd_prep() で継承された vec にフラグを立て、かつキャッシュ put が失敗した場合に vec を解放します（これは io_req_rw_cleanup() の動作と同様です）。
このリークは KASAN 下では不可視です。なぜなら io_alloc_cache_vec_kasan() は無条件で vec を解放するためです。
If you want to get best quality of vulnerability data, you may have to visit VulDB.