Homepage

Use After Free Affecting kernel-syms package, versions <6.12.0-160000.35.1

Severity

 Recommended
0.0
high
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.13% (3rd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Use After Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES1600-KERNELSYMS-17354570
  • published17 Jun 2026
  • disclosed15 Jun 2026
Report a new vulnerability Found a mistake?

Introduced: 15 Jun 2026

NewCVE-2026-31584  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade SLES:16.0.0 kernel-syms to version 6.12.0-160000.35.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-syms package and not the kernel-syms package as distributed by SLES. See How to fix? for SLES:16.0.0 relevant fixed versions and status.

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 &#34;done&#34;
                                    mtk_venc_worker()
                                      v4l2_m2m_job_finish()
                                      // m2m job &#34;done&#34;
                                      // BUT worker still running!
                                      // post-job_finish access:
                                    other ctx dereferences
                                      // UAF if ctx already freed
    // returns (job &#34;done&#34;)
  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.

CVSS Base Scores

version 3.1