Description

dynamic_object_create() in kernel/userspace/userspace.c computed the backing allocation for a dynamically allocated kernel object as obj_size_get(otype) + size, and for thread stack elements as STACK_ELEMENT_DATA_SIZE(size) (a round-up plus fixed overhead), without checking either expression for unsigned wrap-around. A size close to SIZE_MAX makes the computed total wrap to a very small value, so the heap chunk handed out is a few bytes while the object descriptor is still tagged with the full requested type and registered in the kernel object table. The size argument reaches that arithmetic directly from user mode. k_object_alloc_size() is declared __syscall in include/zephyr/sys/kobject.h, its verifier z_vrfy_k_object_alloc_size() in kernel/userspace/userspace_handler.c is a bare pass-through, and z_object_alloc() only range-checks otype — nothing bounds size. The stack-element branch is additionally reachable through the k_thread_stack_alloc() syscall via kernel/dynamic.c. Because subsequent kernel-object validation checks only the object's type and initialization state, the undersized handle passes K_SYSCALL_OBJ_INIT()/K_SYSCALL_OBJ_NEVER_INIT(), and the matching init syscall (for example k_mutex_init(), k_sem_init(), or k_thread_create()) then writes a complete object over the truncated allocation. An unprivileged user-mode thread can therefore trigger a supervisor-mode out-of-bounds write into the kernel resource-pool heap, of a size and content it substantially controls, corrupting sys_heap chunk metadata and adjacent kernel objects. Under CONFIG_GEN_PRIV_STACKS the thread-stack branch additionally stores an attacker-influenced wild pointer as a user thread's privileged stack base. The practical result is escape from the CONFIG_USERSPACE sandbox — kernel-level code execution or at minimum kernel memory corruption and system compromise. Exploitation requires CONFIG_USERSPACE together with CONFIG_DYNAMIC_OBJECTS (also selected by CONFIG_DYNAMIC_THREAD under userspace), and a calling thread with an assigned resource pool. The fix rejects both overflowing computations and frees the partially built descriptor.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-09T08:16:54.563Z",
  "pubdate": "2026-10-09T08:16:54.563Z",
  "executiveSummary": "This vulnerability is an integer wrap-around flaw within the Zephyr kernel's dynamic object allocation subsystem, specifically affecting the management of kernel objects and thread stacks under the CONFIG_USERSPACE configuration.\nBy supplying a maliciously crafted size argument to syscalls such as k_object_alloc_size() or k_thread_stack_alloc(), an unprivileged user-mode thread can trigger an integer overflow during heap allocation size calculation.\nThis results in the allocation of an undersized heap buffer that does not accommodate the full object size while the kernel registers the object with its original, larger requested size.\nThe primary impact is a kernel-level out-of-bounds write, enabling an attacker to corrupt sys_heap metadata or adjacent kernel objects. Under specific configurations like CONFIG_GEN_PRIV_STACKS, this can result in the corruption of privileged thread stack pointers.\nSuccessful exploitation leads to a complete bypass of the CONFIG_USERSPACE sandbox, granting the attacker kernel-level code execution or systemic memory corruption, effectively escalating privileges from user-mode to supervisor-mode.\nExploitation requires the target system to have CONFIG_USERSPACE and CONFIG_DYNAMIC_OBJECTS (or CONFIG_DYNAMIC_THREAD) enabled, and the calling thread must be assigned a resource pool.",
  "technicalDetails": "The root cause is a failure to validate integer bounds when calculating backing allocation sizes for dynamic kernel objects in kernel/userspace/userspace.c. The function dynamic_object_create() performs arithmetic operations using obj_size_get(otype) + size and STACK_ELEMENT_DATA_SIZE(size) without checking for unsigned wrap-around.\nWhen an attacker provides a size value near SIZE_MAX, the result of the addition wraps around to a small value. Consequently, the heap allocator reserves an insufficient number of bytes for the kernel object. Despite this truncation, the kernel's object management table tags the descriptor with the original, larger size.\nThe attack flow begins in user-mode via syscalls that reach the vulnerable arithmetic. In k_object_alloc_size(), the verifier z_vrfy_k_object_alloc_size() in kernel/userspace/userspace_handler.c acts as a bare pass-through, and z_object_alloc() only performs range checks on the otype, neglecting the size parameter entirely. The stack-element variant is similarly exposed through k_thread_stack_alloc() in kernel/dynamic.c.\nOnce the undersized heap chunk is allocated, subsequent kernel-level object validation procedures, such as K_SYSCALL_OBJ_INIT() or K_SYSCALL_OBJ_NEVER_INIT(), successfully pass because they only verify the object's type and initialization state rather than the physical size of the backing store.\nThe final stage of exploitation occurs during the subsequent initialization syscall (e.g., k_mutex_init() or k_thread_create()). The kernel writes a complete object structure over the undersized buffer, resulting in an out-of-bounds write. This allows the attacker to corrupt sys_heap chunk metadata, facilitating heap grooming or redirection of control flow.\nIn environments using CONFIG_GEN_PRIV_STACKS, the vulnerability allows for the injection of an attacker-influenced wild pointer as a thread's privileged stack base. This effectively creates an arbitrary write primitive in supervisor mode, leading to a total compromise of the kernel's security domain and sandbox escape."
}