media: mtk-jpeg: fix use-after-free in release path due to uncancelled work
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.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.86, 6.18.27, 6.6.140, 7.0.4
- CVEs
- CVE-2026-46011
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 17:36 UTC · Revision 1
Source evidence
media: mtk-jpeg: fix use-after-free in release path due to uncancelled work
core-osv · Original sourcePublished 27 May 2026, 12:56 UTC
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.
osv:CVE-2026-46011
Kernel
Fixed versions: 6.6.140, 6.12.86, 6.18.27, 7.0.4
Complete source record
{
"id": "66f14f8ef6fe45f995624daeac1ea36c4e88e2b4bfc40ea20aa66e4042f7f1a2",
"url": "https://osv.dev/vulnerability/CVE-2026-46011",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "media: mtk-jpeg: fix use-after-free in release path due to uncancelled work",
"summary": "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.",
"evidence": "osv:CVE-2026-46011",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.140",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.86",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.27",
"evidence": "/affected/1/ranges"
},
{
"value": "7.0.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2026-46011",
"aliases": [
"CVE-2026-46011"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "5fb1c2361e5630491d2a2f9359654eb022601bc0"
},
{
"fixed": "2209fdae5c2f615930c9af1379c1cfca199ec5d8"
},
{
"fixed": "0498b27a1542021d90269d58347501d4c3ccd84e"
},
{
"fixed": "26506a30e0e26d612f82a7bf0e395626968a44e6"
},
{
"fixed": "e78c39f720679fcf3a2eacd82725ec3ea2648301"
},
{
"fixed": "34c519feef3e4fcff1078dc8bdb25fbbbd10303f"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-46011.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.140"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.86"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.27"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.0.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-46011.json"
}
}
],
"modified": "2026-10-28T02:30:31.276715375Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/0498b27a1542021d90269d58347501d4c3ccd84e",
"https://git.kernel.org/stable/c/2209fdae5c2f615930c9af1379c1cfca199ec5d8",
"https://git.kernel.org/stable/c/26506a30e0e26d612f82a7bf0e395626968a44e6",
"https://git.kernel.org/stable/c/34c519feef3e4fcff1078dc8bdb25fbbbd10303f",
"https://git.kernel.org/stable/c/e78c39f720679fcf3a2eacd82725ec3ea2648301",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46011.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-46011",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46011.json"
}
},
"related_cves": [
{
"value": "CVE-2026-46011",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 497894,
"published_at": "2026-05-27T12:56:13.198+00:00"
}