5.8 MEDIUM
- CVSS version (CVSS): 3.1
- Attack Vector (AV): Local (L)
- Attack Complexity (AC): High (H)
- Privileges Required (PR): Low (L)
- User Interaction (UI): None (N)
- Scope (S): Unchanged (U)
- Confidentiality (C): Low (L)
- Integrity (I): Low (L)
- Availability (A): High (H)
- Modified Attack Vector (MAV): Local (L)
- Modified Attack Complexity (MAC): High (H)
- Modified Privileges Required (MPR): Low (L)
- Modified User Interaction (MUI): None (N)
- Modified Confidentiality (MC): Low (L)
- Modified Scope (MS): Unchanged (U)
- Modified Integrity (MI): Low (L)
- Modified Availability (MA): High (H)
Activity log
- Created suggestion
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 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.
References
Affected products
- <4.5.0
Matching in nixpkgs
pkgs.python313Packages.smoke-zephyr
Python utility collection
pkgs.python314Packages.smoke-zephyr
Python utility collection
pkgs.python313Packages.zephyr-python-api
Set of wrappers for Zephyr Scale (TM4J) REST API
pkgs.python314Packages.zephyr-python-api
Set of wrappers for Zephyr Scale (TM4J) REST API
pkgs.python313Packages.zephyr-test-management
Wrappers for both Zephyr Scale and Zephyr Squad (TM4J) REST APIs
Package maintainers
-
@fabaff Fabian Affolter <mail@fabian-affolter.ch>
-
@Steinhagen Viorel-Cătălin Răpițeanu <rapiteanu.catalin@gmail.com>