CVE-2026-64358

What it actually does

This is a Linux kernel driver flaw in the MediaTek JPEG codec driver. On platform variants that do not use the driver's workqueue, the release path still calls cancel_work_sync() against work that has no callback initialized. That causes a kernel WARN_ON condition in the workqueue flushing path. In normal configurations this may create repeated kernel warnings and log noise; in hardened or production configurations where kernel warnings are treated as fatal, such as panic_on_warn=1, a local user or process able to open and release the affected media device could trigger a kernel panic and denial of service.

Why it matters to the business

The main operational risk is system instability or outage on Linux systems using affected MediaTek JPEG hardware and driver builds. The risk is most relevant for embedded devices, appliances, mobile/edge systems, and multimedia workloads that expose the affected media device to local processes or sandboxed applications. Because EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, broad internet-scale exploitation is unlikely; however, affected systems configured to panic on kernel warnings may be susceptible to an easy local crash once an attacker or untrusted workload has local device access.

How an attack unfolds

An attacker first needs local code execution or the ability to interact with the affected V4L2/media device exposed by the MediaTek JPEG driver. The attacker opens the affected device node and then closes or otherwise releases it on a platform variant where the driver's jpeg_worker callback is not initialized. During release, the vulnerable kernel code unconditionally calls cancel_work_sync(). Because the associated work item has no valid callback, the kernel workqueue code emits a WARN_ON. If the system is configured to continue after warnings, exploitation mainly results in kernel warning messages and potential service degradation through repeated triggering. If the system is configured to panic on warnings, the same action can crash the kernel and force a reboot, causing denial of service.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the MediaTek JPEG driver release path. The corrected behavior is to call cancel_work_sync() only when the platform data defines a valid workqueue callback. If vendor fixed versions are not available, update to the latest supported kernel package from the operating system, device, BSP, or SoC vendor that includes this driver fix. As interim mitigation, restrict access to affected media/V4L2 device nodes to trusted users and services only, remove unnecessary device exposure from containers or sandboxes, disable or unload the affected driver if JPEG hardware acceleration is not required, and review whether panic_on_warn=1 is appropriate for systems where local untrusted workloads can access media devices.

How to confirm the fix worked

Confirm that the running kernel includes the patched MediaTek JPEG driver logic by checking the installed kernel package changelog, vendor advisory, or source tree for the conditional cancel_work_sync() behavior in the mtk_jpeg_release path. Verify the running kernel version after reboot, not only the installed package version. On affected hardware, perform a controlled open/release test of the MediaTek JPEG device node and confirm that no WARN_ON or __flush_work warning is generated in dmesg or kernel logs. Also verify that untrusted users, containers, and application sandboxes do not have unnecessary read/write access to the affected /dev/media* or /dev/video* device nodes.

Typical attack path

1. Gain local execution on a Linux system using an affected MediaTek JPEG driver variant.
2. Identify accessible media/V4L2 device nodes associated with the MediaTek JPEG codec driver.
3. Open the affected device node from a local process or sandboxed workload with sufficient permissions.
4. Close or release the device so the driver's vulnerable release handler runs.
5. Trigger the unconditional cancel_work_sync() call against an uninitialized workqueue callback.
6. Cause a kernel WARN_ON; on systems with panic_on_warn enabled, trigger a kernel panic and denial of service.
7. Optionally repeat the action to create recurring outages or log flooding until the kernel is patched or access is restricted.

How to detect it

To determine whether this was already triggered, review kernel logs and persistent system journals for warning stacks related to the MediaTek JPEG driver release path and Linux workqueue flushing. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump records, pstore/ramoops logs on embedded systems, and any centralized syslog or EDR telemetry that collects kernel events. Look for WARN_ON entries mentioning __flush_work, cancel_work_sync, mtk_jpeg_release, mtk-jpeg, or MediaTek JPEG shortly before a reboot, kernel panic, watchdog reset, or service outage. Correlate timestamps with local process execution, container activity, application sandbox activity, and accesses to /dev/media* or /dev/video* device nodes. If auditd or eBPF-based device access telemetry is available, search for processes repeatedly opening and closing media device nodes immediately before the warning or crash.

• WARNING: CPU:
• WARN_ON
• __flush_work
• cancel_work_sync
• mtk_jpeg_release
• mtk-jpeg
• mtk_jpeg
• MediaTek JPEG
• panic_on_warn
• Kernel panic - not syncing
• /dev/media
• /dev/video

What your security team should do

• Prioritize patching Linux systems using MediaTek JPEG hardware acceleration, especially embedded, appliance, kiosk, mobile, edge, and multimedia-processing devices.
• Inventory systems that load the mtk-jpeg or related MediaTek JPEG codec driver and determine whether affected device nodes are reachable by untrusted users or workloads.
• Apply the latest vendor-supported kernel or BSP update that contains the driver fix; reboot systems to ensure the patched kernel is active.
• Until patched, restrict permissions on relevant media device nodes and avoid passing affected devices into containers, browsers, mobile app sandboxes, or other untrusted execution contexts.
• Review kernel boot/runtime settings such as panic_on_warn; understand that enabling warning-induced panic can turn this warning condition into a full system crash.
• Monitor kernel logs for WARN_ON events involving cancel_work_sync, __flush_work, mtk_jpeg_release, or the MediaTek JPEG driver, particularly on systems that have experienced unexplained reboots.
• Because this issue is not currently KEV-listed, has very low EPSS, and has no reported exploit maturity, handle it as a targeted local denial-of-service risk rather than an active mass-exploitation emergency.