CVE-2026-12365: Use-after-free in Zephyr delayable work-queue cancellation under SMP timing race
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 worktimeout() is in flight (blocked acquiring the work-queue spinlock), a concurrent cancellation does not wait for that handler to finish. In unschedulelocked() the pre-fix code called zaborttimeout(), which for an already-announcing record returns -EINVAL without removing it; cancelasynclocked() then observes the work as idle, so even kworkcanceldelayablesync() and kworkflushdelayable() 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 kworkdelayable, a caller that frees the object immediately after a successful sync cancel can race the still-pending handler. worktimeout() subsequently dereferences the freed record: it reads to->dticks via zistimeouthandlercanceled() and, if the freed slot has been reused so the bail check fails, performs a read-modify-write of wp->flags (KWORKDELAYEDBIT) and submits work against a stale dw->queue pointer — a use-after-free read and write.
The kwork 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 unschedulelocked() wait, by spinning on ztryaborttimeout() returning -EAGAIN while releasing and re-acquiring the work spinlock, until any in-flight handler completes before returning, and switches worktimeout() to atomic KWORKDELAYEDBIT ownership. This closes both the free-then-handler use-after-free and the related reschedule early-fire race.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the fix in kernel/work.c: modify unschedule_locked() to wait for any in-flight delayable-work timeout handler to complete (spin on z_try_abort_timeout() while it returns -EAGAIN, releasing and re-acquiring the work spinlock) before returning, rather than using the pre-fix behavior where z_abort_timeout() could leave an announcing record in place and allow cancellation/flush to return without blocking.
Zephyr kernel (k_work_delayable / second-generation work queue, kernel/work.c) unschedule_locked() timeout abort behavior = wait for in-flight handler by spinning on z_try_abort_timeout() returning -EAGAIN while releasing/re-acquiring the work spinlock until completion - Configuration
Apply the fix in kernel/work.c: change work_timeout() to switch to atomic K_WORK_DELAYED_BIT ownership to prevent the race where work_timeout subsequently dereferences a freed record and performs read-modify-write of wp->flags and submission against a stale dw->queue pointer.
Zephyr kernel (kernel/work.c) work_timeout() ownership of K_WORK_DELAYED_BIT = use atomic K_WORK_DELAYED_BIT ownership
Event History
Frequently Asked Questions
What is the severity of CVE-2026-12365?
The severity of CVE-2026-12365 is classified as medium with a score of 5.8.
What type of vulnerability is CVE-2026-12365?
CVE-2026-12365 is a use-after-free vulnerability found in the Zephyr work queue management.
How do I fix CVE-2026-12365?
To fix CVE-2026-12365, update to the latest version of Zephyr where the vulnerability has been addressed.
What impact does CVE-2026-12365 have on system security?
CVE-2026-12365 can lead to potential denial-of-service conditions due to its use-after-free nature.
In what component of Zephyr does CVE-2026-12365 occur?
CVE-2026-12365 occurs in the kernel/work.c component, specifically in delayable work-queue management.