CVE-2026-98917 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
parisc: Increase kernel stack size to 32kb
For 64-bit Linux kernels, increase the default kernel stack size (THREAD_SIZE_ORDER) to 32 kB, in order to avoid kernel crashes which have been triggered recently when building the debian vtk9 package with gcc 17:
stackcheck: kworker/u128:0 will most likely overflow kernel stack (sp:179a83af0, stk bottom-top:179a80000-179a84000) Kernel panic - not syncing: low stack detected by irq handler - check messages CPU: 2 UID: 0 PID: 30760 Comm: kworker/u128:0 Tainted: G W 6.18.46-dirty #1 NONE Tainted: [W]=WARN
Hardware name: 9000/800/rp3440 Workqueue: writeback wb_workfn (flush-259:0) Backtrace: [<000000004022f050>] show_stack+0x70/0x90
[<000000004022378c>] dump_stack_lvl+0x124/0x190
[<000000004022382c>] dump_stack+0x34/0x48
[<000000004020212c>] vpanic+0x204/0x648
[<00000000402025c4>] panic+0x54/0x58
[<0000000040232230>] do_cpu_irq_mask+0x3f8/0x440
[<0000000040227070>] intr_return+0x0/0xc
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The Linux kernel for the parisc architecture has addressed a critical stability issue by increasing the default kernel stack size from its previous configuration to 32 kilobytes. This modification specifically targets 64-bit kernels and is designed to prevent kernel panics caused by stack overflow conditions that have been observed during intensive computational tasks, such as building specific software packages like vtk9 using newer compiler versions like gcc 17. The vulnerability stems from the inherent limitations of fixed-size kernel stacks in complex execution paths where deep call chains or large local variable allocations can exhaust available memory space within the interrupt context.
The technical flaw is classified under CWE-121, which denotes a stack-based buffer overflow, although in this specific instance, it manifests as an exhaustion of the allocated kernel stack rather than a traditional overwrite of adjacent memory structures that leads to code execution. The operational impact involves system instability and potential denial of service through kernel panics. When the stack pointer approaches the bottom boundary of the allocated region, the kernel's internal checks detect low stack space during interrupt handling routines. This triggers an immediate halt via vpanic, resulting in a complete loss of availability for the affected system. The error logs indicate that workqueues processing tasks such as writeback operations can trigger these conditions if they involve deep recursion or substantial local data structures within interrupt contexts.
From a threat modeling perspective, this issue aligns with ATT&CK techniques related to resource exhaustion and denial of service, specifically under T1499 which covers endpoint disruption via system crashes. While the primary motivation for increasing stack size is stability rather than security against malicious exploitation, insufficient stack sizes can sometimes be leveraged by attackers in conjunction with other vulnerabilities to achieve arbitrary code execution if they can force deep call stacks or large allocations within kernel space. Therefore, mitigating this issue also reduces the attack surface for potential privilege escalation attempts that rely on manipulating control flow through corrupted return addresses located near the top of a small stack frame.
The recommended mitigation is straightforward and involves applying the upstream Linux kernel patch that adjusts the THREAD_SIZE_ORDER constant to allocate 32 kilobytes per thread context on parisc systems. System administrators should ensure their kernels are updated to versions containing this fix, particularly if they perform heavy compilation or data processing workloads involving large local variables in interrupt handlers. Regular monitoring of system logs for stack check warnings can help identify instances where the previous limits were being approached, allowing for proactive intervention before a full panic occurs. Maintaining up-to-date kernel packages is essential to preserve both the integrity and availability of parisc-based systems against these resource exhaustion events.