Just as a quick FYI, it's good LKML ettiquette to keep people who engaged with the previous threads on CC for new versions :)
On Mon, Jun 29, 2026 at 04:28:19PM -0700, Xiang Mei wrote: > On Mon, Jun 29, 2026 at 3:29 PM Dave Hansen <[email protected]> wrote: > > > > On 6/29/26 14:47, Xiang Mei wrote: > > > With CONFIG_VMAP_STACK, kernel stacks are allocated in the vmalloc area, > > > which an unprivileged user can surround with attacker-controlled data by > > > spraying vmap allocations adjacent to a target stack (for example via > > > XDP_UMEM_REG, though other vmalloc spray paths work too). Today each > > > guarded vmalloc allocation is followed by a single unmapped guard page. ...snip... > > To even be considered, this series needs to be refactored properly. > > Making this VMAP_GUARD_PAGES a separate patch is the bare minimum. > > > Good suggestion, I will do it in v3: > > 1/3 - introduce VMAP_GUARD_PAGES > 2/3 - mark percpu vmap areas VM_NO_GUARD I would suggest you create a VMAP_STACK flag and condition these guard regions bsaed on that. Otherwise it's a bit arbitrary as to what callers get 0x11 guard pages, and which don't. (you can find the concrete stack allocation functions in kernel/fork.c) -- Pedro
