CVE-2026-31584
Published: 24 April 2026
Summary
CVE-2026-31584 is a high-severity Use After Free (CWE-416) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 2.9th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified are NIST 800-53 RA-5 (Vulnerability Monitoring and Scanning) and SI-2 (Flaw Remediation).
Deeper analysis
CVE-2026-31584 is a use-after-free vulnerability in the Linux kernel's MediaTek VCodec driver, affecting the encoder release path in the fops_vcodec_release() function. The issue arises because the context structure (ctx) is freed without first cancelling any pending or running work queued to ctx->encode_work. This creates a race condition where the workqueue handler, mtk_venc_worker, continues accessing ctx fields such as ctx->m2m_ctx and ctx->dev even after v4l2_m2m_job_finish() signals job completion to the V4L2 mem2mem framework. The vulnerability was confirmed using KASAN, which detected slab-use-after-free during post-job accesses in an instrumented test that widened the race window.
A local attacker with low privileges can exploit this vulnerability due to its CVSS v3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). By triggering encode operations and racing the release path—such as through rapid open/release cycles on the V4L2 device—the attacker can cause the workqueue to dereference freed ctx memory, potentially leading to arbitrary code execution, denial of service via crash, or data corruption with high confidentiality, integrity, and availability impacts.
Kernel stable patch commits address the issue by inserting cancel_work_sync(&ctx->encode_work) in fops_vcodec_release() after v4l2_m2m_ctx_release() and v4l2_ctrl_handler_free(), but before list_del_init(&ctx->list) and kfree(ctx). This ensures any pending work is cancelled and running handlers complete before freeing the context. The fix is available in commits such as 76e35091ffc7, 93d9a58961a9, 9a9bdaf9dc42, a8a55913552a, and f1692337c6fa on git.kernel.org/stable. Note that open error paths do not require this, as INIT_WORK does not schedule the work.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-25477
Vulnerability details
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Local kernel UAF in MediaTek VCodec driver (fops_vcodec_release race with mtk_venc_worker) directly enables privilege escalation via arbitrary code execution from low-privileged context.
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Directly mandates timely remediation of the use-after-free flaw in the MediaTek VCodec driver via application of the available kernel stable patches.
Provides memory protection mechanisms that mitigate exploitation of the use-after-free vulnerability by preventing unauthorized code execution due to memory corruption.
Requires vulnerability scanning to identify systems running vulnerable kernel versions affected by CVE-2026-31584 for prompt patching.