Re: [PATCH] [RFC] ntfs: disable for 64KB because of stack overflow risk

From: Arnd Bergmann
Date: Tue Sep 28 2021 - 04:20:25 EST

On Tue, Sep 28, 2021 at 1:21 AM Anton Altaparmakov <anton@xxxxxxxxxx> wrote:
> Hi Arnd,
> Thanks for the patch but what is the problem with the stack usage exceeding 2048 bytes?
> I am not aware of any architectures that implements kernel stack size (THREAD_SIZE)
> less than page size and by default most architectures with 4kiB page size even use two
> pages to make the stack 8kiB.

The two are decoupled these days unless CONFIG_VMAP_STACK is enabled at build
time, in which case the THREAD_SIZE is always a multiple of STACK_SIZE.
No architecture currently forces the use of VMAP_STACK though, so the allocation
is done in alloc_thread_stack_node() using this kmem_cache:

thread_stack_cache = kmem_cache_create_usercopy("thread_stack",

64K pages are allowed on arm64, powerpc, mips, microblaze, ia64, sh, hexagon
and the upcoming loongarch port. The respective THREAD_SHIFT/THREAD_SIZE
values on these are

arch/arm64/include/asm/memory.h:#define MIN_THREAD_SHIFT (14 +
arch/powerpc/Kconfig:config THREAD_SHIFT
arch/powerpc/Kconfig- default "14" if PPC64
arch/mips/include/asm/thread_info.h:#define THREAD_SIZE_ORDER (0)
arch/mips/include/asm/thread_info.h:#define THREAD_SIZE (PAGE_SIZE <<
arch/microblaze/include/asm/thread_info.h:#define THREAD_SHIFT 13
arch/ia64/include/asm/ptrace.h:# define KERNEL_STACK_SIZE_ORDER 0
arch/ia64/include/asm/ptrace.h:#define IA64_STK_OFFSET
arch/ia64/include/asm/ptrace.h:#define KERNEL_STACK_SIZE
arch/ia64/include/asm/thread_info.h:#define THREAD_SIZE
arch/sh/include/asm/thread_info.h:#define THREAD_SHIFT 12
arch/hexagon/include/asm/thread_info.h:#define THREAD_SHIFT 12

As far as I can tell, only mips and ia64 require the kernel stack to
be a multiple
of the page size here, and I would consider that a bug: This is extremely
wasteful, especially considering that those machines typically won't have the
vast amounts of RAM that modern arm64 and powerpc64 servers have.

On a hexagon or sh system with 4KB stacks, using over 2KB in one function
is definitely excessive. Those machines wouldn't normally need NTFS support,
but that was kind-of the point of my patch.