Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - media：mediatek：vcodec：修复编码器版本路径中的释放后使用 fops_vcodec_release（） 函数释放上下文结构 （ctx），而无需首先取消 ctx->encode_work 中的任何待定或正在运行的工作。这将创建一个争用窗口，工作队列处理程序 （mtk_venc_worker） 在释放上下文内存后可能仍在访问上下文内存。争用条件：CPU 0（释放路径） CPU 1（工作队列） --------------------- ------------------ fops_vcodec_release（） v4l2_m2m_ctx_release（） v4l2_m2m_cancel_job（） // 等待 m2m 作业完成 mtk_venc_worker（） v4l2_m2m_job_finish（） // m2m 作业完成 // 但工作仍在运行！ post-job_finish access：其他 ctx 取消引用 // 如果 ctx 已释放则为 UAF // 返回（作业完成） kfree（ctx） // ctx 已释放 根本原因：v4l2_m2m_ctx_release（） 仅等待 m2m 作业生命周期（通过TRANS_RUNNING标记），而不等待工作队列生命周期。调用 v4l2_m2m_job_finish（） 后，m2m 框架会认为作业完成并返回 v4l2_m2m_ctx_release（），但工作线程函数会继续执行，并且可能仍会访问 ctx。在编码操作期间，工作通过以下方式排队：queue_work（ctx->dev->encode_workqueue， &ctx->encode_work） 工作线程函数会访问 ctx->m2m_ctx、ctx->dev 和其他 ctx 字段，即使在调用 v4l2_m2m_job_finish（） 之后也是如此。通过运行可扩大 post-job_finish 争用窗口的检测测试模块，KASAN 已确认此漏洞。KASAN 检测到： 缺陷： KASAN： mtk_venc_worker+0x159/0x180 中的释放后使用 任务 kworker/u8：0/12 在地址 ffff88800326e000 处读取了大小为 4 的工作队列： mtk_vcodec_enc_wq mtk_venc_worker 按任务 47 分配：__kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 由任务 47 释放：__kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190 通过在调用 kfree（ctx） 之前调用 cancel_work_sync（&ctx->encode_work） 来修复此问题。这可确保在释放上下文之前取消工作队列处理程序（如果待处理）和同步（等待任何正在运行的处理程序完成）。放置理由：该补丁位于 v4l2_ctrl_handler_free（） 之后和 list_del_init（&ctx->list） 之前。此时，所有 m2m 操作已完成（v4l2_m2m_ctx_release（） 已返回），我们需要确保工作队列已同步，然后再从列表中删除 ctx 并将其释放。注意：打开错误路径不需要 cancel_work_sync（），因为 INIT_WORK（） 只是初始化工作结构，它不会对其进行计划。稍后在 device_run（） 操作期间才会安排工作。（CVE-2026-31584）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-31584

high Nessus 插件 ID 310308

版本 1.16