CVE-2026-19569: Integer overflow in dynamic kernel object allocation allows user-mode threads to corrupt the kernel heap
dynamicobjectcreate() in kernel/userspace/userspace.c computed the backing allocation for a dynamically allocated kernel object as objsizeget(otype) + size, and for thread stack elements as STACKELEMENTDATASIZE(size) (a round-up plus fixed overhead), without checking either expression for unsigned wrap-around. A size close to SIZEMAX 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. kobjectallocsize() is declared syscall in include/zephyr/sys/kobject.h, its verifier zvrfykobjectallocsize() in kernel/userspace/userspacehandler.c is a bare pass-through, and zobjectalloc() only range-checks otype — nothing bounds size. The stack-element branch is additionally reachable through the kthreadstackalloc() syscall via kernel/dynamic.c. Because subsequent kernel-object validation checks only the object's type and initialization state, the undersized handle passes KSYSCALLOBJINIT()/KSYSCALLOBJNEVERINIT(), and the matching init syscall (for example kmutexinit(), kseminit(), or kthreadcreate()) 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 sysheap chunk metadata and adjacent kernel objects. Under CONFIGGENPRIVSTACKS 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 CONFIGUSERSPACE sandbox — kernel-level code execution or at minimum kernel memory corruption and system compromise.
Exploitation requires CONFIGUSERSPACE together with CONFIGDYNAMICOBJECTS (also selected by CONFIGDYNAMICTHREAD under userspace), and a calling thread with an assigned resource pool. The fix rejects both overflowing computations and frees the partially built descriptor.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to exploitation?
Deployments in which user-mode threads can invoke the affected allocation interfaces are exposed. The size argument reaches the vulnerable arithmetic directly from user mode through k_object_alloc_size(), and the stack-element path is also reachable through k_thread_stack_alloc().
What does an attacker need to provide?
An attacker needs local user-mode execution with permission to make the relevant syscalls and must supply a size close to SIZE_MAX. This causes unsigned arithmetic to wrap, producing a small backing allocation for an object that remains registered as the requested full type.
Do kernel object validation checks prevent use of the malformed allocation?
No. The affected object is tagged with the requested type and registered in the kernel object table, while subsequent validation checks only its type and initialization state. As a result, the undersized handle can pass the initialization-related syscall object checks.