procfs_rwmem ignores kmem_alloc_pageable failure — kva=0 reaches pmap_kenter_quick(0,pa), overwriting pml4[0] of the current user pmap (page-table pivot) plus uiomove on VA 0

Summary

kmem_alloc_pageable() documents returning 0 on failure (vm_map_find error → return 0, vm_kern.c:176-178). procfs_rwmem() stores the result in kva without any check (procfs_mem.c:101). Every unprivileged user reaches this via pread/pwrite on /proc//mem (CHECKIO/p_trespass pass for curp==p). If the allocation fails, kva=0 flows into: (a) pmap_kenter_quick(0, VM_PAGE_TO_PHYS(m)) at :147 — on pc64, vtopte(0)=PTmap+0 and PTmap=KVADDR(PML4PML4I,0,0,0), i.e. the recursive self-map aliasing the PML4 page itself, so atomic_swap_long in pmap.c overwrites pml4[0] of the current user pmap with pa|RW|V where pa is the traced process's page whose contents the attacker fully controls (trace yourself) — a fake-PDPT pivot giving arbitrary physical-memory R/W from userspace (full uid=0 ceiling) if ever triggered; (b) uiomove on VA 0; (c) kmem_free(kernel_map, 0, PAGE_SIZE) — verified harmless (range clamp no-ops). Trigger requires kernel_map KVA exhaustion (vm_map_entry_reserve blocks rather than fails; x86_64 KVA far beyond unpriv reach) — Low, speculative trigger, page-table-pivot consequence.

Recommended fix

if (kva == 0) { vmspace_drop(vm); return (ENOMEM); } after :101.

Timeline

• 2026-09-02 Discovered during pass-2 audit of vm_kern.c (GLM 5.3); caller-discipline defect, consequence verified by code trace.