DF-5655 — VERDICT

Status: reproduced (host-kernel panic, deterministic; 2/2 baseline fires). Impact: panic — an unprivileged user inside a vkernel panics the host kernel (the kernel running the vkernel process), with one syscall. Confidence: certain. Fix validated (vkernel rejects the value, everything survives).

The finding

sys/platform/vkernel64/x86_64/tls.c — the VKERNEL's sys_set_tls_area validates which (tls.c:79) and info.size (tls.c:96) but never validates info.base before storing it (tls.c:102). This is the vkernel twin of the pc64 gap filed as DF-5639, but the sink is different — and the threat model is worse: the vkernel's set_user_TLS() is a NOP (tls.c:142-145), so the poisoned base is not programmed locally; it is handed to the host kernel on the very next return to emulated user mode and programmed by the host's wrmsr:

1. In-vkernel unprivileged user calls set_tls_area(1, {base:0x0000800000000000, size:-1}, 16) (SYS_set_tls_area = 472).
2. The vkernel's sys_set_tls_area stores info into curthread->td_tls.info[1] (vkernel64 tls.c:102) and returns 0. td_tls is #defined as td_mach.mtd_savevext.vx_tls (vkernel64/include/thread.h:50) — the same memory that struct vextframe wraps (cpu/x86_64/include/vframe.h:44-47).
3. Return to emulated user mode: go_user() calls vmspace_ctl(id, VMSPACE_CTL_RUN, tf, &curthread->td_savevext) (vkernel64 trap.c:1407-1408) — a host syscall made by the vkernel process.
4. Host sys_vmspace_ctl copyins the vframe's vx_tls into the host thread's td_tls (sys/vm/vm_vmspace.c:293-295), calls cpu_sanitize_tls() — a no-op on pc64 (sys/platform/pc64/x86_64/machdep.c:924-927, "For x86_64 we don't have to do anything") — then set_user_TLS() (vm_vmspace.c:311), which executes wrmsr(MSR_KGSBASE, 0x0000800000000000) (pc64 tls.c:163-172).
5. WRMSR with a non-canonical FS.base/GS.base raises #GP(0) in host kernel mode (Intel SDM Vol.3 17.17) → Fatal trap 9 → the host kernel halts in DDB. The vkernel's containment is fully defeated: code with no privilege on the host (any account inside the vkernel) kills the host kernel.

Proof (baseline, stock kernels)

• Trigger: /bin/as_nobody /bin/vk_tls_noncanon 1 inside the vkernel (in-vkernel uid=gid=65534), poisoning GS (fs left valid).
• Serial transcript (run.log / panic.txt): the DF5655: uid=65534 ... base=0x0000800000000000 marker is immediately followed by Fatal trap 9: general protection fault while in kernel mode and Stopped at set_user_TLS+0x94: wrmsr.
• RIP attribution: objdump of the guest /boot/kernel/kernel places set_user_TLS+0x94 (0xffffffff80bd4c74) on the wrmsr preceded by mov $0xc0000102,%ecx — MSR_KGSBASE, i.e. pc64 tls.c:171, the emulated-user GS install. The FSBASE wrmsr (+0x68) was skipped because only GS was poisoned — proving the fault is the vframe-supplied base, not the vkernel's own rtld TLS.
• 2/2 deterministic baseline fires (two separate boots); guest wedged in DDB both times, ssh dead, vm.sh status => down.
• The fault is a fixed #GP — no write primitive, no resumable path — so the impact ceiling is a reliable host-kernel DoS from inside the virtualization boundary (no uid=0 route exists for this class).

Fix validation

fix.diff (this pack) adds the canonicality check to the vkernel's sys_set_tls_area (reject non-canonical info.base with EINVAL), so the value is stopped at the source, before any vmspace_ctl handoff:

• Patched-vkernel run (run.2.log): identical trigger, identical unprivileged uid → DF5655: RETURNED rc=22 (EINVAL), MARKER_AFTER_TRIGGER prints, vkernel stays alive, host stays alive (ssh fine).
• FS variant (which=0) equally rejected (run.3.log).
• Legit TLS regression: the fixed vkernel booted normally — every binary exec'd inside it (sh, vkinit, the static trigger) performs rtld TLS bootstrap through this same syscall with canonical bases.

The host-side counterpart (real validation in pc64 cpu_sanitize_tls, covering hostile/other vkernel binaries) is the second hunk of DF-5639's fix; the two fixes are complementary: DF-5639's seals the host boundary against any vkernel, this one stops the stock DragonFly vkernel from ever carrying an in-vkernel user's poison across it (and avoids the vkernel's own panic("vmspace_ctl failed") at trap.c:1427-1430 that would otherwise fire once hosts adopt DF-5639's fix).

Rig notes (DF-5474)

The stock VKERNEL64 platform does not link (known finding DF-5474: vkernel64 SYSTEM_LD drops ${ELDFLAGS}, so __build_id_start/end are unresolved). The DF-5474 defsym workaround was applied to the guest's /usr/src copy, identically in baseline and fixed phases; it does not touch this finding's code paths.

Negative results (checked and killed)

• which/index bounds — i = uap->which; 0..1 else ERANGE (tls.c:78-80, 126-128); syscallarg(int) is signed; no truncation.
• infosize — uap->infosize < 0 (tls.c:81-82, 129-130) is dead code (size_t, sysproto.h:1045,1050 — always false), but every copy is bounded by min(sizeof(info), infosize) = ≤16 bytes (tls.c:87-93, 134); infosize==0 copies nothing. No overflow, no uninit read: the partial-copy path pre-zeroes info (tls.c:88).
• copyout leak — sys_get_tls_area copies td_tls.info[i], which is only ever user-set, fork-inherited (vkernel64 vm_machdep.c:182-183) or zero-allocated; no kernel pointers are reachable through it.
• cothread / %gs=0 discipline (DF-5607 interplay) — this file never touches MSRs (set_user_TLS() is a NOP, tls.c:142-145) and the swtch.s call site for it is inside #if 0 (vkernel64 swtch.s:481-486); no clobber of cothread %gs is possible from this file.
• vmspace_ctl TLS save/restore — host saves/restores the vkernel's kernel TLS around VMSPACE_CTL_RUN (vm_vmspace.c:288-290, 301-306, 884) and the error path restores both frame and TLS; the bug is solely the unvalidated input accepted by this file, not the save/restore.
• Races — the td_tls store is same-thread; consumers (go_user on the same thread, fork copy under fork's serialization) cannot observe a torn 16-byte struct in a way this file controls.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.