CVE-2026-12365
Received Received - Intake

Use-After-Free in Zephyr RTOS Work Queue

Vulnerability report for CVE-2026-12365, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-08-14

Last updated on: 2026-08-14

Assigner: Zephyr Project

Description

A use-after-free exists in the Zephyr second-generation work queue (kernel/work.c) in the handling of delayable work timeouts. When a delayable work item's timeout has been dequeued and its handler work_timeout() is in flight (blocked acquiring the work-queue spinlock), a concurrent cancellation does not wait for that handler to finish. In unschedule_locked() the pre-fix code called z_abort_timeout(), which for an already-announcing record returns -EINVAL without removing it; cancel_async_locked() then observes the work as idle, so even k_work_cancel_delayable_sync() and k_work_flush_delayable() return without blocking on the in-flight handler. Because those are the APIs the kernel header documents as the safe way to cancel before freeing a k_work_delayable, a caller that frees the object immediately after a successful sync cancel can race the still-pending handler. work_timeout() subsequently dereferences the freed record: it reads to->dticks via z_is_timeout_handler_canceled() and, if the freed slot has been reused so the bail check fails, performs a read-modify-write of wp->flags (K_WORK_DELAYED_BIT) and submits work against a stale dw->queue pointer β€” a use-after-free read and write. The k_work API is kernel-mode only (no __syscall entry point), so this is a kernel-internal concurrency defect rather than a userspace privilege escalation. Triggering it requires an SMP build and a subsystem that schedules and then frees (or reschedules) a delayable work item in the narrow window while its timeout is announcing; an attacker able to influence the timing of such teardown (for example via connection churn driving subsystem timers) has a plausible but probabilistic path. The impact is kernel memory corruption or crash (denial of service). The fix makes unschedule_locked() wait, by spinning on z_try_abort_timeout() returning -EAGAIN while releasing and re-acquiring the work spinlock, until any in-flight handler completes before returning, and switches work_timeout() to atomic K_WORK_DELAYED_BIT ownership. This closes both the free-then-handler use-after-free and the related reschedule early-fire race.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-14
Last Modified
2026-08-14
Generated
2026-08-14
AI Q&A
2026-08-14
EPSS Evaluated
N/A
NVD
EUVD

Affected Vendors & Products

Showing 3 associated CPEs
Vendor Product Version / Range
zephyrproject zephyr 4.5.0
zephyrproject zephyr From 2.6.0 (inc) to 4.4.2 (inc)
zephyr_project zephyr *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This is a use-after-free vulnerability in the Zephyr RTOS kernel's second-generation work queue (kernel/work.c). It occurs when a delayable work item's timeout handler is blocked while trying to acquire a spinlock. A concurrent cancellation does not wait for the handler to finish, allowing the work item to be freed while the handler is still running. The handler then tries to access the freed memory, causing a use-after-free read and write. The issue requires an SMP build and precise timing conditions to exploit.

Detection Guidance

This vulnerability is specific to the Zephyr RTOS kernel and requires kernel-level access to detect. There are no direct network commands to detect it. Instead, check if your Zephyr RTOS version is between 2.6.0 and 4.4.2. If so, the system is vulnerable. Use the Zephyr build system to verify the version or inspect the kernel/work.c file for the affected code paths.

Impact Analysis

The vulnerability can lead to kernel memory corruption or a crash (denial of service). Since the k_work API is kernel-mode only, this is not a userspace privilege escalation. An attacker would need to influence the timing of work item teardown, such as through connection churn driving subsystem timers, to exploit it. The impact is primarily on system availability.

Mitigation Strategies

Upgrade Zephyr RTOS to version 4.5.0 or later to apply the patch. If upgrading is not immediately possible, review and apply the commit 59cf34bf212eeb5c7ea88b97e15842b1e7c1a6b7 manually to the kernel/work.c file. Ensure all delayable work items are properly synchronized and avoid freeing work items while handlers may still be running.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-12365. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart