CVE-2026-31584

In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: fix use-after-free in encoder release path

The fopsvcodecrelease() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->encodework. This creates a race window where the workqueue handler (mtkvenc_worker) may still be accessing the context memory after it has been freed.

Race condition:

CPU 0 (release path)               CPU 1 (workqueue)
---------------------               ------------------
fops_vcodec_release()
  v4l2_m2m_ctx_release()
    v4l2_m2m_cancel_job()
    // waits for m2m job "done"
                                    mtk_venc_worker()
                                      v4l2_m2m_job_finish()
                                      // m2m job "done"
                                      // BUT worker still running!
                                      // post-job_finish access:
                                    other ctx dereferences
                                      // UAF if ctx already freed
    // returns (job "done")
  kfree(ctx)  // ctx freed

Root cause: The v4l2m2mctxrelease() only waits for the m2m job lifecycle (via TRANSRUNNING flag), not the workqueue lifecycle. After v4l2m2mjobfinish() is called, the m2m framework considers the job complete and v4l2m2mctxrelease() returns, but the worker function continues executing and may still access ctx.

The work is queued during encode operations via: queuework(ctx->dev->encodeworkqueue, &ctx->encodework) The worker function accesses ctx->m2mctx, ctx->dev, and other ctx fields even after calling v4l2m2mjob_finish().

This vulnerability was confirmed with KASAN by running an instrumented test module that widens the post-job_finish race window. KASAN detected:

BUG: KASAN: slab-use-after-free in mtkvencworker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12

Workqueue: mtkvcodecencwq mtkvenc_worker

Allocated by task 47: _kasankmalloc+0x7f/0x90 fopsvcodecopen+0x85/0x1a0

Freed by task 47: __kasanslabfree+0x43/0x70 kfree+0xee/0x3a0 fopsvcodecrelease+0xb7/0x190

Fix this by calling cancelworksync(&ctx->encode_work) before kfree(ctx). This ensures the workqueue handler is both cancelled (if pending) and synchronized (waits for any running handler to complete) before the context is freed.

Placement rationale: The fix is placed after v4l2ctrlhandlerfree() and before listdelinit(&ctx->list). At this point, all m2m operations are done (v4l2m2mctxrelease() has returned), and we need to ensure the workqueue is synchronized before removing ctx from the list and freeing it.

Note: The open error path does NOT need cancelworksync() because INITWORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during devicerun() operations.