{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.86-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.4-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  media: mtk-jpeg: fix use-after-free in release path due to uncancelled work  The mtk_jpeg_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx-\u003ejpeg_work. This creates a race window where the workqueue callback may still be accessing the context memory after it has been freed.  Race condition:      CPU 0 (release)                    CPU 1 (workqueue)     ----------------                   ------------------     close()       mtk_jpeg_release()                                        mtk_jpegenc_worker()                                          ctx = work-\u003edata                                          // accessing ctx          kfree(ctx)  // freed!                                          access ctx  // UAF!  The work is queued via queue_work() during JPEG encode/decode operations (via mtk_jpeg_device_run). If the device is closed while work is pending or running, the work handler will access freed memory.  Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This ordering is critical: if cancel_work_sync() is called after mutex_lock(), and the work handler also tries to acquire the same mutex, it would cause a deadlock.  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 ioctl operations.",
  "id": "DEBIAN-CVE-2026-46011",
  "modified": "2026-09-14T16:47:35.748697770Z",
  "published": "2026-05-27T14:17:19.250Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-46011"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-46011"
  ]
}