On Tue, Jun 30, 2026 at 7:40 AM Pedro Falcato <[email protected]> wrote: > > Just as a quick FYI, it's good LKML ettiquette to keep people who engaged with > the previous threads on CC for new versions :) > Thanks so much for the tip. I'll remember that. > 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.
Good point. That would make the structure cleaner. > > (you can find the concrete stack allocation functions in kernel/fork.c) > > -- > Pedro
