CVE-2026-31584

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: fix use-after-free in encoder release path<br /> <br /> The fops_vcodec_release() function frees the context structure (ctx)<br /> without first cancelling any pending or running work in ctx-&gt;encode_work.<br /> This creates a race window where the workqueue handler (mtk_venc_worker)<br /> may still be accessing the context memory after it has been freed.<br /> <br /> Race condition:<br /> <br /> CPU 0 (release path) CPU 1 (workqueue)<br /> --------------------- ------------------<br /> fops_vcodec_release()<br /> v4l2_m2m_ctx_release()<br /> v4l2_m2m_cancel_job()<br /> // waits for m2m job "done"<br /> mtk_venc_worker()<br /> v4l2_m2m_job_finish()<br /> // m2m job "done"<br /> // BUT worker still running!<br /> // post-job_finish access:<br /> other ctx dereferences<br /> // UAF if ctx already freed<br /> // returns (job "done")<br /> kfree(ctx) // ctx freed<br /> <br /> Root cause: The v4l2_m2m_ctx_release() only waits for the m2m job<br /> lifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle.<br /> After v4l2_m2m_job_finish() is called, the m2m framework considers<br /> the job complete and v4l2_m2m_ctx_release() returns, but the worker<br /> function continues executing and may still access ctx.<br /> <br /> The work is queued during encode operations via:<br /> queue_work(ctx-&gt;dev-&gt;encode_workqueue, &amp;ctx-&gt;encode_work)<br /> The worker function accesses ctx-&gt;m2m_ctx, ctx-&gt;dev, and other ctx<br /> fields even after calling v4l2_m2m_job_finish().<br /> <br /> This vulnerability was confirmed with KASAN by running an instrumented<br /> test module that widens the post-job_finish race window. KASAN detected:<br /> <br /> BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180<br /> Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12<br /> <br /> Workqueue: mtk_vcodec_enc_wq mtk_venc_worker<br /> <br /> Allocated by task 47:<br /> __kasan_kmalloc+0x7f/0x90<br /> fops_vcodec_open+0x85/0x1a0<br /> <br /> Freed by task 47:<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0xee/0x3a0<br /> fops_vcodec_release+0xb7/0x190<br /> <br /> Fix this by calling cancel_work_sync(&amp;ctx-&gt;encode_work) before kfree(ctx).<br /> This ensures the workqueue handler is both cancelled (if pending) and<br /> synchronized (waits for any running handler to complete) before the<br /> context is freed.<br /> <br /> Placement rationale: The fix is placed after v4l2_ctrl_handler_free()<br /> and before list_del_init(&amp;ctx-&gt;list). At this point, all m2m operations<br /> are done (v4l2_m2m_ctx_release() has returned), and we need to ensure<br /> the workqueue is synchronized before removing ctx from the list and<br /> freeing it.<br /> <br /> Note: The open error path does NOT need cancel_work_sync() because<br /> INIT_WORK() only initializes the work structure - it does not schedule<br /> it. Work is only scheduled later during device_run() operations.