Live › vulnerability › CVE-2026-85035
Zephyr's CAN receive filter API can be given a dynamically allocated message queue that a user-mode thread can free while the CAN driver still holds a pointer to it. When a matching CAN frame arrives, the kernel writes into freed memory, which lets a user-mode thread corrupt kernel heap and escape the isolation that CONFIG_USERSPACE provides.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 14:21 UTC. All times on this page are UTC.
Applications built on Zephyr that use CAN receive filters with message queues and run user-mode threads on a build with dynamic kernel objects enabled. The risk comes from dynamically allocated queues passed to the filter API; applications that define all queues statically with CAN_MSGQ_DEFINE() are not exposed through this path. Builds without CONFIG_USERSPACE or without CONFIG_DYNAMIC_OBJECTS can skip it.
No product ranges from the sources yet.
CONFIG_USERSPACE=y and CONFIG_DYNAMIC_OBJECTS=y together with a CAN driver.can_add_rx_filter_msgq() and confirm the queues are defined with CAN_MSGQ_DEFINE(), not allocated at runtime.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
The can_add_rx_filter_msgq() system call installs a CAN RX filter whose callback (can_msgq_put() in drivers/can/can_common.c) is handed the caller's struct k_msgq * as user_data. The controller driver stores that raw pointer in its filter table and dereferences it from the RX path every time a matching frame arrives. The system call verifier z_vrfy_can_add_rx_filter_msgq() in drivers/can/can_handlers.c validated the queue only with K_SYSCALL_OBJ(), which is a point-in-time check of type, initialization and caller permission and says nothing about the object's lifetime.
On a build with CONFIG_USERSPACE=y and CONFIG_DYNAMIC_OBJECTS=y, an unprivileged user-mode thread that has been granted access to a CAN device can obtain a message queue whose lifetime it fully controls: k_object_alloc(K_OBJ_MSGQ) followed by k_msgq_alloc_init(). The lifetime of such an object is driven solely by its permission bitmask, and a pointer retained by the kernel is not represented there. After registering the filter, the thread calls k_object_release() — or simply terminates — and unref_check() frees the struct k_msgq storage while the CAN driver still holds the pointer.
The next matching CAN frame causes k_msgq_put() to run in supervisor context against freed memory that the attacker can have groomed with another kernel allocation: the frame payload is memcpy()d through the reused block's write_ptr, and the queue's wait_q (and poll_events under CONFIG_POLL) list nodes are manipulated. This yields kernel-heap corruption reachable from a user-mode thread, defeating the isolation CONFIG_USERSPACE is intended to provide; the same dangling pointer also arises benignly when an application thread exits without calling can_remove_rx_filter().
The fix validates the queue with K_SYSCALL_OBJ_STATIC(), which additionally rejects objects carrying K_OBJ_FLAG_ALLOC, so only statically defined queues (CAN_MSGQ_DEFINE()) may be registered from user mode. Supervisor-mode callers bypass the verifier and must themselves keep the queue valid until the filter is removed.
This page as .md · .json · in your agent: get_signal("CVE-2026-85035")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.