CVE-2026-12365: use-after-free in zephyrproject zephyr
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.
AI Analysis
Technical Summary
This vulnerability 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 handler is in progress and a concurrent cancellation occurs, the cancellation does not wait for the handler to complete. This can lead to a use-after-free condition where the handler dereferences freed memory, causing kernel memory corruption or crash. The issue requires SMP builds and specific timing to trigger. The fix involves making the cancellation wait for the handler to finish and switching to atomic ownership of the delayed work bit, preventing the race conditions.
Potential Impact
The vulnerability can cause kernel memory corruption or a denial of service (kernel crash). It does not provide a path for userspace privilege escalation since the affected API is kernel-mode only. Exploitation requires specific timing and concurrency conditions in SMP builds, making it a probabilistic attack vector rather than a straightforward exploit.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix involves changes to the kernel work queue code to wait for in-flight handlers before cancellation completes and to use atomic ownership flags. Until an official fix is released, users should avoid scenarios that trigger concurrent cancellation and freeing of delayable work items in SMP environments.
CVE-2026-12365: use-after-free in zephyrproject zephyr
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 v3.1
Score 5.8medium
Affected software
zephyrproject
zephyr
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
This vulnerability 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 handler is in progress and a concurrent cancellation occurs, the cancellation does not wait for the handler to complete. This can lead to a use-after-free condition where the handler dereferences freed memory, causing kernel memory corruption or crash. The issue requires SMP builds and specific timing to trigger. The fix involves making the cancellation wait for the handler to finish and switching to atomic ownership of the delayed work bit, preventing the race conditions.
Potential Impact
The vulnerability can cause kernel memory corruption or a denial of service (kernel crash). It does not provide a path for userspace privilege escalation since the affected API is kernel-mode only. Exploitation requires specific timing and concurrency conditions in SMP builds, making it a probabilistic attack vector rather than a straightforward exploit.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix involves changes to the kernel work queue code to wait for in-flight handlers before cancellation completes and to use atomic ownership flags. Until an official fix is released, users should avoid scenarios that trigger concurrent cancellation and freeing of delayable work items in SMP environments.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- zephyr
- Date Reserved
- 2026-06-16T03:53:45.082Z
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 6a7f5a78bf8831d539821041
Added to database: 08/14/2026, 18:12:08 UTC
Last enriched: 08/14/2026, 18:29:19 UTC
Last updated: 09/29/2026, 01:47:40 UTC
Views: 66
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.