Zephyr RTOS EUVD-2026-115823

Requires a Zephyr build with both CONFIG_USERSPACE=y and CONFIG_DYNAMIC_OBJECTS=y; CONFIG_DYNAMIC_OBJECTS is default-off (arch/Kconfig:475-486, kernel/Kconfig:208-212) but is automatically selected when CONFIG_DYNAMIC_THREAD is enabled alongside CONFIG_USERSPACE, making this a realistic production configuration for dynamic-thread Zephyr deployments. The attacker must control a user-mode thread that has been explicitly granted access to a CAN device via k_object_access_grant() or equivalent before the vulnerability can be triggered - this grant is a deliberate application-level decision, not a default. Within those prerequisites, no further special configuration is required: the attacker uses only standard userspace syscalls (k_object_alloc, k_msgq_alloc_init, can_add_rx_filter_msgq, k_object_release) available to any granted user-mode thread. Exploitation is additionally bounded by the need to deliver a matching CAN frame, achievable via CAN_MODE_LOOPBACK (demonstrated in the PoC) or physical bus access. No user interaction is required once the thread is running. Supervisor-mode callers are not protected by the fix and must themselves ensure queue lifetime exceeds filter lifetime.

CVSS 8.8 with AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H accurately characterizes this as a local privilege escalation that crosses the user-to-kernel boundary. The scope change (S:C) is the key signal: a low-privilege user-mode thread with CAN device access can corrupt kernel heap in supervisor context, fully defeating the isolation that CONFIG_USERSPACE is intended to provide. No EPSS score was provided in the input; no CISA KEV listing is present at time of analysis. However, a detailed, functional PoC demonstrating cross-privilege frame delivery on qemu_x86_64 is embedded in the GHSA advisory - this is confirmed working exploit code. The decision label 'this_week' is consistent with a high-severity but conditionally exploitable issue: not an emergency requiring same-day response, but patching within the week is warranted for affected configurations. Two conditions substantially reduce real-world blast radius: (1) the build must have both CONFIG_USERSPACE=y and CONFIG_DYNAMIC_OBJECTS=y - the latter is default-off, though it is auto-selected by CONFIG_DYNAMIC_THREAD when userspace is enabled; and (2) the attacker must already possess a user-mode thread executing on the target device with explicit CAN device access granted. For Zephyr deployments that use dynamic thread support and expose CAN bus access to unprivileged code - a realistic profile for automotive or industrial IoT gateways - this is a genuine, straightforward privilege escalation path. The same dangling pointer can also be triggered non-adversarially when an application thread exits without removing its filter, meaning non-malicious triggering is a realistic concern for reliability as well.

An attacker controlling a low-privilege Zephyr user-mode thread with granted CAN device access allocates a dynamic message queue via k_object_alloc(K_OBJ_MSGQ), registers it with can_add_rx_filter_msgq(), then releases it via k_object_release() - causing unref_check() to free the struct k_msgq storage while the CAN driver retains the stale pointer. The attacker then grooms the freed heap slot by allocating a supervisor-owned kernel object at the same address. When a matching CAN frame arrives (via loopback or physical bus), can_msgq_put() executes in supervisor context against the reused memory, memcpy-ing the frame payload through the recycled block's write_ptr and manipulating wait_q and poll_events list nodes - yielding kernel heap corruption and a privilege escalation path to supervisor mode. A complete PoC demonstrating cross-privilege frame delivery on qemu_x86_64 is included in the GHSA advisory.