ZephyrProject Zephyr up to 4.3.1/4.4.x Thread Cleanup kernel/thread.c do_thread_cleanup denial of service

Summaryinfo

A vulnerability categorized as critical has been discovered in ZephyrProject Zephyr up to 4.3.1/4.4.x. This impacts the function do_thread_cleanup of the file kernel/thread.c of the component Thread Cleanup. Executing a manipulation can lead to denial of service. This vulnerability is registered as CVE-2026-90589. The attack needs to be launched locally. No exploit is available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in ZephyrProject Zephyr up to 4.3.1/4.4.x. It has been declared as critical. This vulnerability affects the function do_thread_cleanup of the file kernel/thread.c of the component Thread Cleanup. The manipulation with an unknown input leads to a denial of service vulnerability. The CWE definition for the vulnerability is CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use. As an impact it is known to affect availability. CVE summarizes:

When CONFIG_THREAD_STACK_MEM_MAPPED is enabled, each thread stack is mapped into the kernel virtual address space with a guard page on either side, and the mapping is released during abort cleanup. k_thread_abort_cleanup() in kernel/thread.c has two paths: a deferred one for self-abort, which stashes the mapping in thread_cleanup_stack_addr/thread_cleanup_stack_sz, and an immediate one for a thread aborted by some other thread. The immediate path called do_thread_cleanup(), which ignored its thread argument and only ever unmapped the stashed address — a value populated exclusively by the self-abort path. The mapped stack of a thread aborted by another thread was therefore never unmapped. Every k_thread_abort() of a non-current thread leaks the thread's stack region plus its two guard pages from the kernel virtual address space. Threads that end by returning from their entry function take the working self-abort path, so the leak is specific to explicit cancellation — k_thread_abort(), pthread_cancel(), osThreadTerminate(), or the kernel thread kill shell command. Both k_thread_create() and k_thread_abort() are system calls, so with CONFIG_USERSPACE an unprivileged user-mode thread that has been granted a thread object and a user-capable stack object can drive the leak from user mode, consuming a kernel-side resource it cannot otherwise touch. With CONFIG_KERNEL_VM_SIZE defaulting to 8 MB, a few hundred create/abort cycles exhaust the runtime mapping region. k_mem_map_phys_guard() then returns NULL, and map_thread_stack() guards that only with __ASSERT_NO_MSG(), which is compiled out of production builds; thread creation proceeds to write through a NULL-derived stack base and faults in kernel mode. The impact is a persistent denial of service — a kernel fatal error requiring a reboot — with no memory disclosure or corruption, and it is limited to configurations where memory-mapped thread stacks are enabled (x86 targets with X86_MMU and demand paging disabled, where the option is implied by default).

The advisory is shared for download at github.com. This vulnerability was named CVE-2026-90589 since 09/12/2026. The exploitation appears to be easy. The attack needs to be approached locally. There are known technical details, but no exploit is available.

Upgrading to version 4.3.2 or 4.5.0 eliminates this vulnerability. Applying the patch d9ec92ccb1d91f4ea5b15271d30169d5b27ba667 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• ZephyrProject

Name

• Zephyr

Version

• 4.0
• 4.1
• 4.2
• 4.3
• 4.3.0
• 4.3.1
• 4.4

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion