CVE-2026-90589: Memory-mapped thread stack is never unmapped when a thread is aborted by another thread, exhausting kernel virtual address space
When CONFIGTHREADSTACKMEMMAPPED 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. kthreadabortcleanup() in kernel/thread.c has two paths: a deferred one for self-abort, which stashes the mapping in threadcleanupstackaddr/threadcleanupstacksz, and an immediate one for a thread aborted by some other thread. The immediate path called dothreadcleanup(), 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 kthreadabort() 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 — kthreadabort(), pthreadcancel(), osThreadTerminate(), or the kernel thread kill shell command. Both kthreadcreate() and kthreadabort() are system calls, so with CONFIGUSERSPACE 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 CONFIGKERNELVMSIZE defaulting to 8 MB, a few hundred create/abort cycles exhaust the runtime mapping region. kmemmapphysguard() then returns NULL, and mapthreadstack() guards that only with ASSERTNOMSG(), 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 X86MMU and demand paging disabled, where the option is implied by default).