CVE-2026-46011

What it actually does

This is a local Linux kernel use-after-free in the MediaTek JPEG codec driver release path. The driver frees a per-file context while asynchronous JPEG work may still be pending or running on a kernel workqueue. If the device file is closed while encode or decode work is active, the worker can dereference memory that has already been freed. In the best case this causes a kernel crash; in the worst case, a local attacker who can access the affected media device may be able to manipulate freed kernel memory to achieve privilege escalation or kernel-mode code execution.

Why it matters to the business

Systems using affected Linux kernels with the MediaTek JPEG driver enabled may be vulnerable to local denial of service or privilege escalation. The practical risk is highest on MediaTek-based devices, embedded systems, appliances, mobile/edge platforms, and distributions that expose video/media device nodes to untrusted users or sandboxed applications. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS at this time, and has no known mature public exploit, but kernel privilege-escalation bugs can become operationally significant when chained after initial compromise.

How an attack unfolds

An attacker first needs local access to a system where the affected MediaTek JPEG driver is present and reachable, typically through a V4L2/media device node exposed under /dev. The attacker opens the JPEG codec device and triggers encode or decode operations that schedule work through the driver's workqueue. They then close the device at a carefully chosen time while the queued worker is pending or executing. Because the vulnerable release path frees the context without synchronously cancelling the worker first, the worker can continue using a dangling pointer. By repeatedly racing this sequence, an attacker may cause a kernel panic or attempt heap grooming so the freed memory is reallocated with attacker-influenced contents, potentially converting the use-after-free into local privilege escalation.

How to fix it

Upgrade to a kernel version or vendor kernel package that includes the fix for the mtk-jpeg release path, specifically the change that calls cancel_work_sync() before freeing the context and before taking the mutex in mtk_jpeg_release(). No exact fixed package versions were provided, so use the Linux distribution, device vendor, Android/BSP vendor, or embedded platform advisory for the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling or unloading the MediaTek JPEG driver if it is not required, restricting permissions on affected media device nodes, limiting access to video/media groups, and preventing untrusted workloads from accessing host /dev/video*, /dev/media*, or codec accelerator devices. For containerized environments, do not pass through affected media devices to untrusted containers unless patched.

How to confirm the fix worked

Confirm that the running kernel package includes the upstream or vendor fix for the MediaTek JPEG driver. Validate by checking vendor changelogs, kernel source, or backport metadata for the mtk_jpeg_release() change that invokes cancel_work_sync() before context free. On systems where source or symbols are available, verify the patched driver behavior rather than relying only on kernel version because vendors may backport fixes. Confirm whether the driver is present or loaded using lsmod, modinfo, kernel configuration, or device-tree/platform inventory. Confirm device exposure by reviewing permissions on /dev/video*, /dev/media*, and related codec device nodes. After remediation, monitor kernel logs during JPEG encode/decode and device close operations for absence of KASAN, slab, workqueue, or general protection fault messages referencing mtk-jpeg functions.

Typical attack path

1. Obtain local code execution as an unprivileged user or through a compromised application/container with access to the affected media device.
2. Confirm that the MediaTek JPEG codec driver is loaded or available and that the process can access the relevant /dev/media*, /dev/video*, or related V4L2 device node.
3. Open the JPEG codec device and issue encode/decode ioctls that cause the driver to queue asynchronous JPEG work.
4. Race the operation by closing the device while the queued work is pending or running.
5. Repeat the race to trigger use-after-free behavior, causing a kernel crash or attempting heap manipulation for privilege escalation.
6. If exploitation succeeds, execute code with elevated kernel-level privileges or disable the system through a denial-of-service crash.

How to detect it

Look for signs of attempted local exploitation in kernel logs, crash dumps, audit logs, and endpoint telemetry. Primary evidence will be kernel instability or memory-safety diagnostics around the MediaTek JPEG driver, V4L2/media device access, and rapid open/ioctl/close patterns against media device nodes. Review dmesg, journald, syslog, pstore/ramoops, kdump/vmcore data, KASAN reports, panic logs, and EDR process telemetry. Useful behavioral signals include untrusted processes repeatedly opening /dev/video*, /dev/media*, or codec devices; high-frequency VIDIOC_* ioctl calls followed by immediate close; crashes in mtk_jpeg_release(), mtk_jpegenc_worker(), mtk_jpegdec_worker(), or mtk_jpeg_device_run(); and KASAN or slab allocator reports indicating use-after-free in the mtk-jpeg driver. There are no known public threat actors or ransomware campaigns associated with this issue in the provided data, so detection should emphasize local exploit behavior and kernel forensic artifacts rather than network indicators.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in mtk_jpeg_release
• mtk_jpeg_release
• mtk_jpegenc_worker
• mtk_jpegdec_worker
• mtk_jpeg_device_run
• mtk-jpeg
• mtk_jpeg
• general protection fault
• kernel NULL pointer dereference
• Unable to handle kernel paging request
• slab-use-after-free
• workqueue:
• /dev/video
• /dev/media
• VIDIOC_QBUF
• VIDIOC_STREAMON
• VIDIOC_STREAMOFF

What your security team should do

• Prioritize patching MediaTek-based Linux, Android-derived, embedded, edge, and appliance systems where the mtk-jpeg driver is enabled and accessible to non-root users or applications.
• Inventory systems for the MediaTek JPEG codec driver and exposed media device nodes; focus first on multi-user systems and systems running untrusted workloads.
• Restrict access to /dev/video*, /dev/media*, and codec accelerator devices to only trusted users and services until patched.
• Do not pass host media codec devices into untrusted containers, sandboxes, or application runtimes unless the host kernel is confirmed fixed.
• Enable and review kernel crash, audit, and EDR telemetry for local privilege-escalation attempts involving V4L2/media devices.
• Treat kernel crashes referencing mtk_jpeg_release, mtk_jpegenc_worker, or mtk_jpeg_device_run as potentially security-relevant, not merely stability defects.
• Because this is not KEV-listed and currently has low EPSS and no known public exploit, schedule according to normal kernel security patch SLAs unless the affected device node is exposed to untrusted local users, in which case accelerate remediation.