{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2023-52491",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2023-52491"
  ],
  "published": "2024-02-29T16:05:49Z",
  "summary": "media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run\n\nIn mtk_jpeg_probe, &jpeg->job_timeout_work is bound with\nmtk_jpeg_job_timeout_work.\n\nIn mtk_jpeg_dec_device_run, if error happens in\nmtk_jpeg_set_dec_dst, it will finally start the worker while\nmark the job as finished by invoking v4l2_m2m_job_finish.\n\nThere are two methods to trigger the bug. If we remove the\nmodule, it which will call mtk_jpeg_remove to make cleanup.\nThe possible sequence is as follows, which will cause a\nuse-after-free bug.\n\nCPU0                  CPU1\nmtk_jpeg_dec_...    |\n  start worker\t    |\n                    |mtk_jpeg_job_timeout_work\nmtk_jpeg_remove     |\n  v4l2_m2m_release  |\n    kfree(m2m_dev); |\n                    |\n                    | v4l2_m2m_get_curr_priv\n                    |   m2m_dev->curr_ctx //use\n\nIf we close the file descriptor, which will call mtk_jpeg_release,\nit will have a similar sequence.\n\nFix this bug by starting timeout worker only if started jpegdec worker\nsuccessfully. Then v4l2_m2m_job_finish will only be called in\neither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.76",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-52491"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:24:39Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The bug is reached via the Mediatek JPEG V4L2 m2m device node (/dev/videoN) through ordinary open/ioctl/STREAMON/qbuf and close() paths in mtk_jpeg_dec_device_run, requiring local process access rather than network or adjacent packet delivery.\nAC:L - An attacker can deterministically force the mtk_jpeg_set_dec_dst error path (plane/size mismatch under their control), which schedules the 1s job_timeout_work and then job_finish; they fully control the subsequent close or a second decode session that races the dangling timeout, so success does not depend on conditions outside their control.\nPR:L - mtk_jpeg_open has no capability checks; triggering the path only needs access to the JPEG codec video node at unprivileged video-group/media-process level, not real root or init-namespace admin rights.\nUI:N - The attacker performs the entire open, queue, intentional decode-error, and close/second-session sequence themselves; no victim mount, open, or other interactive action is required.\nS:U - The use-after-free corrupts host-kernel m2m/context/buffer state within a single kernel security authority and does not cross a VM, IOMMU, or sandbox boundary.\nC:H - The dangling timeout worker calls v4l2_m2m_get_curr_priv and operates on freed or wrong-context m2m/buffer objects after release or cross-session reuse, enabling reclaim-based arbitrary kernel memory disclosure as with other heap UAFs.\nI:H - The same worker path can double-finish jobs, reset HW, and manipulate freed or concurrently active buffer/context state, providing heap corruption and control-flow hijack primitives consistent with UAF guidance.\nA:H - Use-after-free or NULL dereference in mtk_jpeg_job_timeout_work reliably causes kernel oops/panic, so availability impact is High."
    }
  }
}