Zephyr RTOS EUVD-2026-58751

Exploitation requires an SMP (multi-processor) Zephyr kernel build-the race is physically impossible on uniprocessor (UP) builds where only one CPU core executes at a time. Additionally, the k_work API has no __syscall entry point, so exploitation is restricted to kernel-mode code; userspace processes cannot directly trigger this path. The specific vulnerable window requires a k_work_delayable timeout to have been dequeued by sys_clock_announce() (placing work_timeout() in-flight and blocked on the work-queue spinlock) while a concurrent kernel thread on another CPU executes k_work_cancel_delayable_sync() or k_work_flush_delayable() and then immediately frees the k_work_delayable object. An attacker must have influence over a kernel subsystem's work-item teardown timing-for example, via network connection churn driving a protocol stack that arms and cancels subsystem timers. Exploitation is probabilistic, not deterministic. Limiting factors that reduce realistic risk: mandatory SMP build requirement, kernel-mode-only attack surface, narrow and non-deterministic timing window, and the need to influence a specific subsystem's internal lifecycle rather than sending arbitrary input.

The CVSS 3.1 score of 5.8 (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H) is consistent with the described exploitation conditions: local kernel-mode access, high attack complexity driven by a narrow SMP timing race, and limited confidentiality and integrity impact alongside high availability impact from a potential kernel crash. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, and no public proof-of-concept has been identified. EPSS data is not available in the provided intelligence. The source intelligence tags include 'Privilege Escalation,' which conflicts with the CVE description's explicit statement that this is a kernel-internal concurrency defect without a userspace escalation path; the CVE description is treated as authoritative. Real-world risk is further constrained because the k_work API has no __syscall entry point, preventing direct userspace triggering. The primary realistic impact is a kernel panic or memory corruption in an embedded or IoT device running a Zephyr SMP image with a subsystem (e.g., network stack, BLE controller) that schedules and rapidly cancels or frees delayable work objects under load. For such devices, this represents a meaningful denial-of-service risk if an adversary can generate sufficient protocol-layer churn, but deterministic kernel compromise is unlikely given the probabilistic nature of the race.

An attacker with local kernel-mode code execution on an SMP Zephyr system running a network-connected subsystem generates rapid connection churn, causing the protocol stack to repeatedly arm and cancel delayable work timers. In the narrow window where a k_work_delayable timeout has been dequeued by sys_clock_announce() and work_timeout() is in-flight awaiting the work-queue spinlock, the attacker's concurrent thread completes a sync-cancel, observes the item as idle, and frees the object; work_timeout() then dereferences the freed memory, potentially corrupting a reused allocation or crashing the kernel. No public proof-of-concept exploit exists; timing the race is probabilistic and requires SMP hardware.