Answer in brief
CVE-2026-46011 records a High severity (CVSS 7.8) vulnerability in media: mtk-jpeg: fix use-after-free in release path due to uncancelled work. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=5fb1c2361e5630491d2a2f9359654eb022601bc0 <2209fdae5c2f615930c9af1379c1cfca199ec5d8 || >=5fb1c2361e5630491d2a2f9359654eb022601bc0 <0498b27a1542021d90269d58347501d4c3ccd84e || >=5fb1c2361e5630491d2a2f9359654eb022601bc0 <26506a30e0e26d612f82a7bf0e395626968a44e6 || >=5fb1c2361e5630491d2a2f9359654eb022601bc0 <e78c39f720679fcf3a2eacd82725ec3ea2648301 || >=5fb1c2361e5630491d2a2f9359654eb022601bc0 <34c519feef3e4fcff1078dc8bdb25fbbbd10303f | 2209fdae5c2f615930c9af1379c1cfca199ec5d8, 0498b27a1542021d90269d58347501d4c3ccd84e, 26506a30e0e26d612f82a7bf0e395626968a44e6, e78c39f720679fcf3a2eacd82725ec3ea2648301, 34c519feef3e4fcff1078dc8bdb25fbbbd10303f |
| Linux/Linuxgeneric | 6.2 | Not reported |
Published upstream
May 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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->jpeg_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->data // 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.
Quoted source text, attributed separately from HOL analysis.