Zephyr RTOS EUVD-2026-43244

Exploitation requires the target to be built with all three of CONFIG_SMP, CONFIG_USERSPACE, and CONFIG_DYNAMIC_OBJECTS enabled - remove any one and the bug is unreachable. The attacker must already be able to execute a deprivileged user-mode thread on the device and must invoke the relevant system calls: k_object_alloc/k_object_alloc_size and k_object_release (removals via unref_check()) concurrently with k_thread_abort or thread creation (iteration via k_thread_perms_all_clear()/k_thread_perms_inherit()). Limiting factors: it is a local-only attack (AV:L, PR:L - an unprivileged but authenticated on-device thread), success depends on winning a narrow SMP timing window (AC:H) so it is probabilistic rather than deterministic, and single-core or non-dynamic-object builds are entirely immune.

The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H, base 7.8) is internally consistent with the description: local attack from an on-device user thread, high complexity because success depends on winning a narrow SMP race window, low privileges since the attacker is an already-running deprivileged user thread, and scope change because corruption crosses from userspace into the kernel with full C/I/A impact. Modeling with SSVC: exploitation is 'none' (no KEV, no public POC), the attack is arguably automatable (the race can be hammered in a tight loop) but the technical impact is 'total' given potential kernel privilege escalation. No EPSS score was provided in the input, and there is no KEV listing, so real-world exploitation pressure is currently unproven. The practical priority is moderate: the impact ceiling is severe (kernel compromise), but exploitation requires local code execution as a user thread AND the specific CONFIG_SMP+CONFIG_USERSPACE+CONFIG_DYNAMIC_OBJECTS build combination, which sharply narrows the exposed population. No conflicting signals were detected between the vector and the description.

An attacker who can run a deprivileged user-mode thread on an SMP Zephyr device (for example, malicious or compromised application code loaded onto the target) spawns two threads that concurrently churn kernel objects - one repeatedly calling k_object_alloc/k_object_release to drive node removal, the other repeatedly triggering thread creation/abort to drive list iteration. By hammering these system calls in a tight loop they eventually win the race so the SAFE iterator dereferences a freed dyn_obj node, corrupting kernel object-tracking structures to escalate privileges or crash the kernel. No public exploit code is identified, and the high attack complexity (AC:H) reflects the timing precision required.