CVE-2026-31584 in Linux
要約
〜によって VulDB • 2026年05月12日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
media: mediatek: vcodec: エンコーダ解放パスにおけるuse-after-freeを修正
fops_vcodec_release()関数は、ctx->encode_work内の保留中または実行中の作業をキャンセルすることなく、コンテキスト構造体(ctx)を解放しています。これにより、ctxが解放された後にworkqueueハンドラ(mtk_venc_worker)がまだコンテキストメモリにアクセスする可能性があるrace condition（競合状態）が生じます。
競合状態:
CPU 0 (解放パス) CPU 1 (workqueue) ------ ------ ------- -- ------ ------ ------ fops_vcodec_release() v4l2_m2m_ctx_release() v4l2_m2m_cancel_job() // m2mジョブの「完了」を待機 mtk_venc_worker() v4l2_m2m_job_finish() // m2mジョブ「完了」 // ただしワーカーは依然として実行中！ // ジョブ完了後のアクセス: other ctx dereferences // ctxが既に解放されている場合、UAF発生 // 戻る（ジョブ「完了」） kfree(ctx) // ctx解放
根本原因: v4l2_m2m_ctx_release()は、m2mジョブのライフサイクル（TRANS_RUNNINGフラグ経由）のみを待機し、workqueueのライフサイクルは待機しません。v4l2_m2m_job_finish()が呼び出された後、m2mフレームワークはジョブが完了したと見なしてv4l2_m2m_ctx_release()が戻りますが、ワーカー関数は実行を継続し、ctxにアクセスし続ける可能性があります。
作業は、エンコード操作中に以下のようにキューに追加されます: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work) ワーカー関数は、v4l2_m2m_job_finish()を呼び出した後も、ctx->m2m_ctx、ctx->dev、および他のctxフィールドにアクセスします。
この脆弱性は、ジョブ完了後の競合状態を拡大する計測済みテストモジュールを実行することでKASANを用いて確認されました。KASANは以下を検出しました:
BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12
Workqueue: mtk_vcodec_enc_wq mtk_venc_worker
タスク47によって割り当て: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0
タスク47によって解放: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190
kfree(ctx)の前にcancel_work_sync(&ctx->encode_work)を呼び出すことでこれを修正します。これにより、コンテキストが解放される前に、workqueueハンドラがキャンセル済み（保留中の場合）かつ同期済み（実行中のハンドラの完了を待機）であることが保証されます。
配置の理由: 修正はv4l2_ctrl_handler_free()の後、list_del_init(&ctx->list)の前に配置されます。この時点では、すべてのm2m操作が完了しており（v4l2_m2m_ctx_release()が戻っている）、ctxをリストから削除して解放する前にworkqueueを同期させる必要があります。
注: オープン時のエラーパスではcancel_work_sync()は不要です。INIT_WORK()は作業構造体を初期化するだけで、スケジュールしないためです。作業は、device_run()操作中にのみ後からスケジュールされます。
If you want to get best quality of vulnerability data, you may have to visit VulDB.