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

High 7.8 Published Updated

A use-after-free in the Linux kernel's MediaTek video encoder allows local attackers to execute arbitrary code or escalate privileges via a race condition.

Exploited in the wild
Not known
Login needed
Any signed-in user
Attackable
Local or same network only
Victim action needed
Not needed
Fix
Available

What is CVE-2026-31584?

CVE-2026-31584 is a high-severity use after free vulnerability in Linux kernel, published on 24 Apr 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official description

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

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

The fops_vcodec_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->encode_work. This creates a race window where the workqueue handler (mtk_venc_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 v4l2_m2m_ctx_release() only waits for the m2m job lifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle. After v4l2_m2m_job_finish() is called, the m2m framework considers the job complete and v4l2_m2m_ctx_release() returns, but the worker function continues executing and may still access ctx.

The work is queued during encode operations via: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work) The worker function accesses ctx->m2m_ctx, ctx->dev, and other ctx fields even after calling v4l2_m2m_job_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 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

Allocated by task 47: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0

Freed by task 47: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190

Fix this by calling cancel_work_sync(&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 v4l2_ctrl_handler_free() and before list_del_init(&ctx->list). At this point, all m2m operations are done (v4l2_m2m_ctx_release() 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 cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during device_run() operations.

Weakness: CWE-416

Which versions are affected by CVE-2026-31584?

It affects 1 product.

Products include Linux kernel.

How do I fix CVE-2026-31584?

Apply the vendor's patch.

Upgrade to the fixed version. These bugs are found with fuzzing and sanitisers and avoided by memory-safe languages. More about Use after free.

Is CVE-2026-31584 being exploited?

There is no known exploitation of CVE-2026-31584 in the wild and no public exploit code.

All Linux kernel vulnerabilities

Sources

Also known as BELL-CVE-2026-31584, DEBIAN-CVE-2026-31584, GHSA-5g36-g7f3-8q34, ROOT-OS-UBUNTU-2404-CVE-2026-31584, UBUNTU-CVE-2026-31584.

Is CVE-2026-31584 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free