DF-0940 — vm_map_growstack int grow_amount truncation

Verdict: NOT REPRODUCED (false positive for the claimed threat model)

The int grow_amount truncation described in the finding is real in the C source (a 64-bit roundup() result is stored into a 32-bit int), but it is not reachable from an unprivileged user under the default kernel configuration, so the claimed local-DoS / kernel-memory-exhaustion impact does not manifest.

Why it does not reproduce (path:line evidence)

The finding's threat model assumes a user can create a MAP_STACK mapping with an attacker-controlled max_ssize > 2^32. That assumption is wrong:

1. Userland MAP_STACK is stripped. sys/vm/vm_mmap.c:429-436 (inside the mmap syscall path) explicitly removes MAP_STACK and substitutes MAP_ANON for every userland caller:

c /* The only remaining true MAP_STACK we allow is the user stack as * created by the exec code. All userland MAP_STACK's are converted * to normal mmap()s right here. */ if (flags & MAP_STACK) { ... flags &= ~MAP_STACK; flags |= MAP_ANON; upos = 0; }

This is verified empirically: mmap(NULL, 8 GiB, ..., MAP_STACK|MAP_ANON, -1, 0) succeeds and returns a region whose /proc/curproc/map shows two normal anon entries (0x2180 / 0x0 subsys, no growable-stack semantics) — see map_dump.txt. The vulnerable vm_map_growstack path is never entered for this mapping.

2. The only live caller of vm_map_stack() uses a kernel-controlled max_ssize. sys/kern/kern_exec.c:991 invokes it for the main process stack with max_ssize = (vm_size_t)maxssiz. maxssiz is a boot-time tunable, default 512 MiB on pc64 (sys/platform/pc64/include/vmparam.h:69 + subr_param.c:225), and is exported read-only (CTLFLAG_RD, subr_param.c:102):

$ sysctl kern.maxssiz kern.maxssiz: 536870912 # 512 MiB

3. avail_ssize is therefore always ≤ 512 MiB − 128 KiB, far below INT_MAX (2 GiB). For any fault on the main stack, the 64-bit roundup(stack_entry->ba.start - addr, PAGE_SIZE) always fits in int, so the truncation at vm_map.c:4173 never fires. The dead user-mmap caller at vm_mmap.c:1463 is the only path that ever passed a user-controlled max_ssize to vm_map_stack, and it is unreachable.

4. RLIMIT_STACK cannot rescue it. kern_plimit.c:324-327 clamps RLIMIT_STACK to maxssiz:

c if (limp->rlim_cur > maxssiz) limp->rlim_cur = maxssiz; if (limp->rlim_max > maxssiz) limp->rlim_max = maxssiz;

And in any case RLIMIT_STACK only affects the runtime check at vm_map.c:4206-4210, not the avail_ssize set at exec time.

What the original PoC actually does

trig.c mmaps 8 GiB MAP_STACK|MAP_ANON, then dereferences deep pointers. Because MAP_STACK is stripped, the region is a normal anon mapping — the deep read just returns 0x00 from a zero-filled anon page, the process exits 0, and the kernel is unaffected. Verified over 3 consecutive runs (see run.log, run.2.log, run.3.log); guest stayed up after each.

A separate deep-recursion test on the main stack (deeprec.c) confirms the real growstack path is exercised on the main stack and behaves correctly — SIGSEGV cleanly at the maxssiz boundary, kernel healthy.

Defense-in-depth fix

The int grow_amount declaration at vm_map.c:4110 is genuinely wrong — it truncates a 64-bit value. The truncation is currently latent (unreachable from userspace), but it is a real code defect that would resurface if userland MAP_STACK were ever re-enabled or if maxssiz were tuned above 2 GiB. The fix is a one-line type widening: int grow_amount; → vm_size_t grow_amount;. All subsequent comparisons are already against unsigned 64-bit lvalues, so the widening is semantics-preserving. See fix.diff.

Build & run

./build.sh     # cc -O0 -o trig trig.c
./run.sh       # ./trig   (exits 0, no effect — demonstrates the FP)

DF-0940 — vm_map_growstack int grow_amount truncation — VERDICT

Verdict: NOT REPRODUCED (false positive for the claimed threat model)

The C-level truncation defect is real: at sys/vm/vm_map.c:4110 an int grow_amount; receives the 64-bit result of roundup(stack_entry->ba.start - addr, PAGE_SIZE) at :4173, silently dropping the high 32 bits. However, the finding's claimed impact (unprivileged local DoS via mmap of an >4 GiB MAP_STACK) does not manifest, because the only path that ever fed a user-controlled max_ssize into vm_map_stack() — and thus the only way to produce aux.avail_ssize > 2^32 — is dead code. The vulnerability is unreachable from an unprivileged user on the default GENERIC kernel.

Why the PoC does not trigger it (path:line)

(1) Userland MAP_STACK is stripped before vm_map_stack runs

sys/vm/vm_mmap.c:425-439 (inside the mmap syscall) explicitly removes MAP_STACK and substitutes MAP_ANON for every userland caller, with a comment naming the intent:

/* The only remaining true MAP_STACK we allow is the user stack as
 * created by the exec code.  All userland MAP_STACK's are converted
 * to normal mmap()s right here.  */
if (flags & MAP_STACK) {
    if (uap->fd != -1)
        return (EINVAL);
    if ((uap->prot & (PROT_READ|PROT_WRITE)) !=
        (PROT_READ|PROT_WRITE)) {
        return (EINVAL);
    }
    flags &= ~MAP_STACK;
    flags |= MAP_ANON;
    upos = 0;
}

Therefore the vm_map_stack() call at sys/vm/vm_mmap.c:1463 is never reached with user-controlled max_ssize — by the time control reaches kern_mmap at vm_mmap.c:1248+, MAP_STACK has been stripped and the mapping is dispatched as a normal anon vm_map_find at vm_mmap.c:1478.

Empirical confirmation: the PoC's mmap(NULL, 8 GiB, ..., MAP_STACK|MAP_ANON, -1, 0) returns a region whose /proc/curproc/map shows a single normal anon entry — 0x0000000800a00000 0x0000000a00a00000 -1 -1 0 rw- 0 0 0x0000 NCOW NNC none - (no VM_SUBSYS_STACK, no aux.avail_ssize, no growable semantics). See run.log / map_dump.txt.

(2) The only live vm_map_stack caller uses kernel-controlled max_ssize

sys/kern/kern_exec.c:991 is the sole live caller, invoked during exec to create the main process stack:

error = vm_map_stack(&vmspace->vm_map, &stack_addr, (vm_size_t)maxssiz, ...);

maxssiz is a boot-time tunable, read-only at runtime:

• Declared u_quad_t maxssiz; (sys/kern/subr_param.c:95).
• Default MAXSSIZ = 512 MiB on pc64 (sys/platform/pc64/include/vmparam.h:69).
• SYSCTL_QUAD(_kern, OID_AUTO, maxssiz, CTLFLAG_RD, ...) at subr_param.c:102 — CTLFLAG_RD, not writable.
• Only set at boot via TUNABLE_QUAD_FETCH("kern.maxssiz", ...) at subr_param.c:226.

Verified on the guest: sysctl kern.maxssiz ⇒ 536870912 (512 MiB).

(3) avail_ssize is therefore always < INT_MAX

For the main stack, aux.avail_ssize = max_ssize - init_ssize = maxssiz - sgrowsiz = 512 MiB − 128 KiB = 536821760 (well below INT_MAX = 2^31 − 1 ≈ 2 GiB). Any addr inside the growable stack region yields ba.start - addr ≤ avail_ssize < 2^31, so roundup(ba.start - addr, PAGE_SIZE) always fits in int — the truncation at :4173 never fires for any realistic fault. The bounds check at :4166-4170 already excludes any addr outside [ba.start - avail_ssize, ba.start), so a wild pointer can't sneak a large distance in either.

(4) RLIMIT_STACK cannot rescue it

sys/kern/kern_plimit.c:324-327 clamps RLIMIT_STACK to maxssiz:

if (limp->rlim_cur > maxssiz) limp->rlim_cur = maxssiz;
if (limp->rlim_max > maxssiz) limp->rlim_max = maxssiz;

And in any case RLIMIT_STACK only governs the runtime check at vm_map.c:4206-4210 (and the cap at :4217-4220); it does not influence aux.avail_ssize, which is fixed at exec time.

What the original PoC actually does

The finding's PoC (trig.c as delivered) mmaps 8 GiB MAP_STACK|MAP_ANON, writes the lowest byte, and reads an address ~5 GiB "below" the top. Because MAP_STACK is stripped, the entire 8 GiB is a normal anon mapping; every access is satisfied by the anon pager. The deep read returns 0x00 (zero-filled page). The process exits 0. vm_map_growstack is never called (no VM_SUBSYS_STACK entry exists). No panic, no memory growth, no DoS.

Verified over 3 consecutive runs (run.log, run.2.log, run.3.log); guest stayed up after each.

A second test (deeprec.c) exercises the real growstack path via deep recursion on the main stack — it SIGSEGVs cleanly at the maxssiz boundary, kernel unaffected. This is the expected behavior of a correctly-functioning bounded stack.

Impact assessment

• Claimed impact: Local DoS — unbounded kernel memory growth / panic from mapentzone exhaustion via RetryFault loop.
• Actual impact: none. The triggering precondition (MAP_STACK mmap with size > 2^32) is unreachable from userspace; and even were it reachable (e.g. by an admin tuning kern.maxssiz above 4 GiB in /boot/loader.conf), the analysis shows the typical failure mode is a single wrong-size fragment followed by SIGSEGV, not an unbounded loop — because once D (= ba.start - addr) drops below 2^32 after one truncated growth, the next truncated value becomes negative-as-int, which compares (after promotion to u64) greater than avail_ssize and bails at :4174. The finding's "RetryFault loops indefinitely" premise is incorrect; vm_map_insert at :1275-1277 returns KERN_INVALID_ADDRESS for zero-size inserts, breaking the loop.

This is a reviewer false positive on threat-model / reachability grounds, not a "the code is fine" false positive — the type bug is real, just latent.

Defense-in-depth fix

Although the bug is unreachable from userspace today, the int grow_amount declaration at vm_map.c:4110 is genuinely wrong and would become exploitable if userland MAP_STACK were ever re-enabled (the dead code at vm_mmap.c:1463 would resurrect) or if an admin tuned maxssiz above 2 GiB. The one-line type widening in fix.diff (int grow_amount; → vm_size_t grow_amount;) closes the latent defect with no semantic change — all subsequent comparisons (:4174, :4189, :4214, :4223) are already against unsigned 64-bit lvalues. This matches the finding markdown's ## Recommended fix proposal.

Fix validation

Per Phase 8: fix.diff git apply --check -p1 passes; the single-fix kernel built cleanly (make -j6 nativekernel KERNCONF=X86_64_GENERIC → === NK_DONE rc=0 ===, 4299 cc invocations, zero errors); the patched #1 kernel boots and the trigger still exits 0 with no effect (fix_run.log).

fix_status = not_testable — because the bug is unreachable, there is no "bad behavior" to reproduce on the baseline that could then be shown absent on the patched kernel. The fix is validated to (a) apply, (b) compile, (c) not regress the guest; the latent code path it closes was confirmed by source tracing above.

PoC changes from the as-delivered version

• The original trig.c touched *p (lowest byte) and *(p + 3 GiB) and relied on the (incorrect) premise that this would loop in RetryFault. The rewritten trig.c additionally dumps /proc/curproc/map to make the false positive self-evident (the 8 GiB region is one normal anon entry, not a growable stack), and prints explicit "no growstack" markers at each access. The original semantics (deep access on an 8 GiB MAP_STACK) are preserved.