PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-46011 Linux CVE debrief

A use-after-free vulnerability exists in the Linux kernel's MediaTek JPEG driver (mtk-jpeg). The `mtk_jpeg_release()` function frees the context structure (`ctx`) without first cancelling pending or running work in `ctx->jpeg_work`. This creates a race condition where the workqueue callback (`mtk_jpegenc_worker`) may access freed memory if the device is closed while JPEG encode/decode operations are pending or active. The vulnerability is triggered when `close()` is called on a JPEG device file descriptor while `queue_work()` has scheduled but not completed work. The fix adds `cancel_work_sync()` before mutex acquisition in the release path to ensure all pending work completes before context deallocation.

Vendor
Linux
Product
Unknown
CVSS
Unknown
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-27
Original CVE updated
2026-05-27
Advisory published
2026-05-27
Advisory updated
2026-05-27

Who should care

Linux kernel maintainers, embedded systems developers using MediaTek SoCs, security teams managing IoT/edge devices with hardware JPEG acceleration, and organizations running custom kernel builds with V4L2 MediaTek drivers

Technical summary

The MediaTek JPEG driver in the Linux kernel contains a use-after-free vulnerability in its release path. The `mtk_jpeg_release()` function deallocates the driver context structure without ensuring that pending workqueue items have completed. The `ctx->jpeg_work` workqueue item, scheduled via `queue_work()` during JPEG encode/decode operations in `mtk_jpeg_device_run()`, may still be executing when `kfree(ctx)` is called. This race condition allows the work handler `mtk_jpegenc_worker()` to access freed memory when it dereferences `ctx` from `work->data`. The fix requires calling `cancel_work_sync()` before acquiring the driver's mutex and before context deallocation, with specific ordering to avoid deadlock: `cancel_work_sync()` must precede `mutex_lock()` because the work handler itself attempts to acquire the same mutex. The vulnerability affects systems using the mtk-jpeg driver for hardware JPEG acceleration on MediaTek SoCs.

Defensive priority

high

Recommended defensive actions

  • Apply kernel patches from stable branches referenced in CVE record
  • Verify mtk-jpeg driver is updated on MediaTek-based systems
  • Monitor for kernel updates addressing CVE-2026-46011
  • Review custom kernel builds for missing cancel_work_sync() in release paths
  • Audit similar V4L2 drivers for comparable workqueue lifecycle issues

Evidence notes

Vulnerability description and race condition analysis derived from official CVE record and kernel commit references. The fix involves calling `cancel_work_sync()` before `mutex_lock()` to prevent both use-after-free and potential deadlock scenarios. Multiple stable kernel branch commits indicate backports to affected versions.

Official resources

2026-05-27