DF-2746 — sys_mincore() off-by-one write below the user vec pointer

DragonFlyBSD sys/vm/vm_mmap.c, sys_mincore().

Bug

The byte-vector maintenance loops use lastvecindex = -1 as "nothing written yet" but then write at vec + lastvecindex (i.e. vec[-1]) on the first iteration instead of vec + lastvecindex + 1:

• gap-fill loop — sys/vm/vm_mmap.c:920-927
• tail-fill loop — sys/vm/vm_mmap.c:961-968

Whenever the first page the kernel reports on is not page 0 of the scanned range (leading unmapped page(s)), the kernel stores one NUL byte at vec[-1] — one byte below the pointer the user supplied — before writing vec[0]. Additionally vecindex/lastvecindex are int while OFF_TO_IDX() yields a 64-bit page count, so ranges ≥ 2^31 pages (≥ 8 TiB) truncate the index (writes redirected by ±2 GiB; still confined to user space).

Impact boundary: std_subyte rejects addresses ≥ VM_MAX_USER_ADDRESS (sys/platform/pc64/x86_64/support.s:632-634), so writes stay inside the caller's own user address space and the written value is always 0 (or a MINCORE_* nibble). No privilege boundary is crossed ⇒ severity Low (POSIX contract violation + single-byte corruption of adjacent user memory chosen by the caller's vec placement; classic heap-metadata neighbor corruption in the calling process).

Build

cc -O -o /tmp/mincore_oob mincore_oob.c

Run (unprivileged)

/tmp/mincore_oob

Expected output on a vulnerable kernel

DF-2746 mincore(vec) off-by-one probe
test1 (all-unmapped range, tail-fill loop):
  vec[-1] = 0x00  (must still be 0x5A)
  vec[0]  = 0x00  (0x00 ok: page unmapped)
  => VULNERABLE: kernel wrote NUL at vec[-1]
test2 (leading hole, gap-fill loop):
  ... same ...
RESULT: VULNERABLE (2)

Exit code 0 + RESULT: VULNERABLE = bug present. On a fixed kernel both sentinels stay 0x5A, RESULT: not vulnerable, exit code 2.

Fix

fix.diff (4 hunks): write at vec + lastvecindex + 1 in both loops and widen the indices to vm_pindex_t. Validated by kernel rebuild in the QEMU guest — see VERDICT.md.

DF-2746 — VERDICT

File: sys/vm/vm_mmap.c (sys_mincore) · Severity: Low · Class: CWE-787 / CWE-193 (off-by-one OOB write; userspace-directed) + index truncation

Reproduced?

YES — reproduced, unprivileged, stable across 3 runs on the stock INVARIANTS kernel (DragonFly dfbsd 6.5-DEVELOPMENT #0 ... X86_64_GENERIC, guest uname -a in env.txt). run.log contains the decisive output:

test1 (all-unmapped range, tail-fill loop):
  vec[-1] = 0x00  (must still be 0x5A)     <- kernel wrote NUL one byte BELOW vec
  => VULNERABLE: kernel wrote NUL at vec[-1]
test2 (leading hole, gap-fill loop):
  vec[-1] = 0x00  (must still be 0x5A)
  => VULNERABLE: kernel wrote NUL at vec[-1]
RESULT: VULNERABLE (2)

Both trigger shapes hit: (1) a fully unmapped range reaches the tail-fill loop vm_mmap.c:961-968; (2) a range whose leading page is a hole reaches the gap-fill loop vm_mmap.c:920-927 via vm_map_lookup_entry() failing so iteration starts at RB_MIN (vm_mmap.c:821-822) and the first reported page has vecindex >= 1. In each loop the very first iteration executes subyte(vec + lastvecindex, 0) with lastvecindex == -1 (vm_mmap.c:829) ⇒ one NUL byte stored at vec[-1].

Exploit chain / impact ceiling

Rigorously bounded — no privilege escalation path exists:

• The write value is always 0 (gap/tail fill); the per-page write uses a MINCORE_* nibble (vm_mmap.c:932).
• The target is always vec + k for the caller-chosen vec; std_subyte refuses addresses ≥ VM_MAX_USER_ADDRESS (sys/platform/pc64/x86_64/support.s:632-634), so a kernel-range vec or wrapped index returns EFAULT — no kernel-memory write primitive.
• Everything lands in the calling process's own address space, which the caller can already write arbitrarily. Residual harm: silent single-byte corruption of whatever the application placed immediately before the vector (e.g. a heap chunk header/length prefix) ⇒ in-process corruption the app cannot anticipate; POSIX mincore(2) promises to touch only vec[0..ceil(len/PAGE_SIZE)).
• Secondary manifestation: vecindex/lastvecindex are int (vm_mmap.c:791) while OFF_TO_IDX() yields vm_pindex_t; ranges ≥ 2^31 pages (≥ 8 TiB, allowed — user space is 128 TiB) truncate the index so fills/writes land ±2 GiB from vec (still user-space only).

Impact: none for privilege; the honest classification is a kernel correctness/contract bug with in-process corruption — filed Low.

Root cause

sys/vm/vm_mmap.c:920-927 and :961-968: loop body writes vec + lastvecindex but increments after the write; with the -1 sentinel (:829) the first store belongs at vec + lastvecindex + 1.

Fix (validated)

fix.diff — write subyte(vec + lastvecindex + 1, 0) in both loops and widen vecindex/lastvecindex to vm_pindex_t (sentinel becomes (vm_pindex_t)-1; lastvecindex + 1 still wraps to 0).

Fix validation

• Baseline (stock kernel): RESULT: VULNERABLE (2), exit 0 (see run.log).
• vm.sh reset with-src, patch -p1 applied to guest /usr/src (clean, 4/4 hunks), make -j4 nativekernel KERNCONF=X86_64_GENERIC, installkernel, reboot.
• Patched kernel: RESULT: not vulnerable, exit 2 — sentinels intact 0x5A, vec[0]/vec[1] still correctly reported 0x00 / 0x1f (see run.fixed.log). Behavior otherwise identical (mincore still returns 0).

References

• sys/vm/vm_mmap.c:791 (int indices), :829 (-1 sentinel), :920-927 (gap-fill), :932 (page write), :961-968 (tail-fill)
• sys/platform/pc64/x86_64/support.s:625-644 (std_subyte user-range check)