On Tue, Jun 21, 2016 at 12:30 AM, Jann Horn [off-list ref] wrote:

On Tue, Jun 21, 2016 at 1:43 AM, Andy Lutomirski [off-list ref] wrote:

quoted

If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with
vmalloc_node.

[...]

quoted

 static struct thread_info *alloc_thread_info_node(struct task_struct *tsk,
                                                  int node)
 {
+#ifdef CONFIG_VMAP_STACK
+       struct thread_info *ti = __vmalloc_node_range(
+               THREAD_SIZE, THREAD_SIZE, VMALLOC_START, VMALLOC_END,
+               THREADINFO_GFP | __GFP_HIGHMEM, PAGE_KERNEL,
+               0, node, __builtin_return_address(0));
+

After spender gave some hints on IRC about the guard pages not working
reliably, I decided to have a closer look at this. As far as I can
tell, the idea is that __vmalloc_node_range() automatically adds guard
pages unless the VM_NO_GUARD flag is specified. However, those guard
pages are *behind* allocations, not in front of them, while a stack
guard primarily needs to be in front of the allocation. This wouldn't
matter if all allocations in the vmalloc area had guard pages behind
them, but if someone first does some data allocation with VM_NO_GUARD
and then a stack allocation directly behind that, there won't be a
guard between the data allocation and the stack allocation.

I'm tempted to explicitly disallow VM_NO_GUARD in the vmalloc range.
It has no in-tree users for non-fixed addresses right now.