Skip to content
Fencer Vulns
high 7.8

CVE-2026-31584 json

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

published 2026-04-24 6 mo ago modified 2026-08-05 3 mo ago also EUVD-2026-25477

cvss
7.8
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.1%
EPSS 0.1% chance of exploitation in 30 days, percentile 2%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 6.6.136, 6.12.83, 6.18.24, 6.19.14, 7.0.1, 7.1
  • linux Debian 13 6.12.85-1
  • linux Debian 14 6.19.14-1

debian advisories DEBIAN-CVE-2026-31584

  • linux Ubuntu 24.04 LTS 6.8.0-136.136
  • linux Ubuntu 26.04 LTS 7.0.0-27.27
  • linux-aws Ubuntu 24.04 LTS 6.8.0-1061.64
  • linux-aws Ubuntu 26.04 LTS 7.0.0-1008.8
  • linux-gcp Ubuntu 24.04 LTS 6.8.0-1064.72
  • linux-gcp Ubuntu 26.04 LTS 7.0.0-1007.7
  • linux-gke Ubuntu 24.04 LTS 6.8.0-1059.67
  • linux-ibm Ubuntu 24.04 LTS 6.8.0-1061.62

ubuntu advisories UBUNTU-CVE-2026-31584

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel-rt Linux Micro 6.2 6.12.0-160000.35.1
  • kernel-64kb SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.35.1
  • kernel-source SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.35.1
  • kernel-default SLES 16.0, SLE High Availability Extension 16.0, Linux Micro 6.2 +1 more 6.12.0-160000.35.1
  • kernel-default-base SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.35.1.160000.2.16
  • kernel-syms SLES 16.0, Linux Micro Extras 6.2, SLES for SAP applications 16.0 6.12.0-160000.35.1
  • kernel-azure SLES for SAP applications 16.0, SLES 16.0 6.12.0-160000.35.1
  • kernel-obs-qa SLES for SAP applications 16.0, SLES 16.0 6.12.0-160000.35.1

suse advisories SUSE-SU-2026:22112-1SUSE-SU-2026:22127-1SUSE-SU-2026:22117-1SUSE-SU-2026:22099-1

  • kernel-rt openSUSE Leap 16.0 6.12.0-160000.35.1
  • dtb-aarch64 openSUSE Leap 16.0 6.12.0-160000.35.1
  • kernel-64kb openSUSE Leap 16.0 6.12.0-160000.35.1
  • kernel-syms openSUSE Leap 16.0 6.12.0-160000.35.1
  • kernel-azure openSUSE Leap 16.0 6.12.0-160000.35.1
  • kernel-obs-qa openSUSE Leap 16.0 6.12.0-160000.35.1
  • kernel-source openSUSE Leap 16.0 6.12.0-160000.35.1
  • kernel-default openSUSE Leap 16.0 6.12.0-160000.35.1

opensuse advisories openSUSE-SU-2026:20965-1openSUSE-SU-2026:10703-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-31584 updated

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

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.13% chance of exploitation in the next 30 days, higher than 2% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Affected products

  • Linux Linux

Classification

Weakness
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.