DF-5639 — Unprivileged kernel panic via non-canonical TLS base in sys_set_tls_area(2) / set_user_TLS()

VERDICT: reproduced (impact: panic) — deterministic, single syscall, unprivileged (tested as uid 65534 "nobody").

WHAT HAPPENS

sys_set_tls_area (sys/platform/pc64/x86_64/tls.c:70-110) copies a user-supplied struct tls_info and performs exactly two validations: which in {0,1} (tls.c:83) and size >= -1 (tls.c:100). The 64-bit base field is never validated. tls.c:106 stores it into td_tls.info[i] and tls.c:107 calls set_user_TLS(), which writes

  td->td_pcb->pcb_fsbase = info[0].base;           (tls.c:163)
  ...
  wrmsr(MSR_FSBASE,  gd->gd_user_fs);              (tls.c:167)
  wrmsr(MSR_KGSBASE, gd->gd_user_gs);              (tls.c:171)

with the raw user value. WRMSR to MSR_FSBASE (0xc0000100) / MSR_KGSBASE (0xc0000102) raises #GP(0) when the value is not a canonical address (Intel SDM Vol. 3, 17.17 / MSR canonical-address requirement). The fault is taken in KERNEL mode, inside the crit_enter_quick() section (tls.c:162), and DragonFly treats it as a fatal trap:

  Fatal trap 9: general protection fault while in kernel mode
  current process        = <poc pid>
  current thread         = pri 6 (CRIT)
  Stopped at      set_user_TLS+0x68:  wrmsr

RIP 0xffffffff80bd4c48 = the first wrmsr (MSR_FSBASE, ecx=0xc0000100), confirmed by objdump -d of the guest /boot/kernel/kernel.

REPRODUCE (guest: DragonFly 6.5-DEVELOPMENT x86_64, QEMU/KVM on Intel)

build.sh: cc -O1 -o tls_noncanon tls_noncanon.c run.sh (as any unprivileged user, e.g. nobody): su -m nobody -c /tmp/tls_noncanon expected: console: "Fatal trap 9: general protection fault while in kernel mode" ... "Stopped at set_user_TLS+0x68: wrmsr"; system halts in DDB; ssh dies.

First hit during the pass-2 boundary-matrix run (tls_edge.c), then reproduced minimally 1x1 with tls_noncanon.c on a fresh vm.sh reset with-src boot: panic, current process = the PoC pid.

VARIANTS

• which=1 (gsbase, tls.c:171 wrmsr MSR_KGSBASE) is equally unvalidated — same #GP. Primary PoC uses which=0.
• vmspace_ctl(VMSPACE_CTL_RUN) reaches the same sink with a user-supplied vextframe: vm/vm_vmspace.c:296-307 copies vx_tls into td_tls and calls set_user_TLS(); platform/pc64/x86_64/machdep.c:924 cpu_sanitize_tls() is a NO-OP ("we don't have to do anything"). The fix below covers both entry paths. (vkernel_enable gate applies to this variant only; syscall 472 is unconditional.)

WHY NOT ROOT

#GP is a fault, not a controlled write: there is no corruption primitive, the trap is fatal (DDB/reboot). Ceiling = reliable unprivileged local DoS (kernel panic). No escalation path identified; the wrmsr operands (ecx=MSR index, edx:eax=the base) are otherwise fixed by the code path.

FIX VALIDATION (see VERDICT.md tail, fix logs)

fix.diff adds canonicality validation of info.base in sys_set_tls_area (tls.c) and makes pc64 cpu_sanitize_tls() reject non-canonical bases (machdep.c), closing the vmspace_ctl route. Patched kernel built in-guest, rebooted: baseline: panic at set_user_TLS+0x68 (fatal trap 9) patched : tls_noncanon returns -1/EINVAL, guest stays up, full tls_edge.c matrix passes, normal TLS (libc/rtld, threaded build) unaffected.

FILES

tls_noncanon.c minimal deterministic trigger (syscall 472) tls_edge.c full boundary matrix (discovered the bug) build.sh run.sh exact commands build.log run.log run.2.log panic.txt panic.matrix.txt env.txt fix.diff git-apply-able unified diff (both entry paths) manifest.json verdict.json

DF-5639 — VERDICT: REPRODUCED (impact: panic)

Finding

sys_set_tls_area(2) (sys/platform/pc64/x86_64/tls.c:70-110) accepts an arbitrary 64-bit base from an unprivileged user — the only validations are which in {0,1} (tls.c:83-84) and size >= -1 (tls.c:100-101); the base is deliberately unvalidated ("For x86_64 we can only adjust FSBASE and GSBASE", tls.c:103-105). The value flows unmodified:

uap->info --copyin--> info (tls.c:93-96)
curthread->td_tls.info[i] = info          (tls.c:106)
set_user_TLS()                            (tls.c:107)
  td->td_pcb->pcb_fsbase = info[0].base   (tls.c:163)
  wrmsr(MSR_FSBASE,  gd->gd_user_fs)      (tls.c:167)   <-- #GP(0)
  wrmsr(MSR_KGSBASE, gd->gd_user_gs)      (tls.c:171)   <-- same, which=1

Intel SDM Vol.3 17.17 requires FS.base/GS.base to hold canonical addresses; WRMSR of a non-canonical value raises #GP(0). The fault is taken in KERNEL mode inside crit_enter_quick() (tls.c:162) — a fatal trap, not a recoverable signal:

Fatal trap 9: general protection fault while in kernel mode
current process = <poc pid>; current thread = pri 6 (CRIT)
Stopped at set_user_TLS+0x68: wrmsr

RIP 0xffffffff80bd4c48 identified against the guest's /boot/kernel/kernel: it is the FIRST wrmsr (mov $0xc0000100,%ecx = MSR_FSBASE). Guest: QEMU/KVM on GenuineIntel host, so the guest wrmsr executes natively and Intel's #GP check applies.

How it was found / reproduced

1. Boundary matrix tls_edge.c as uid 65534 discovered the panic during the wild-base phase (console: current process 922, same RIP; the preceding "pid 898 (tls_edge) exited on signal 11" line was an earlier harness iteration dying in USER mode after the same wild base install).
2. Minimal deterministic trigger tls_noncanon.c — a single syscall(472, 0, {base=0x0000800000000000, size=-1}, 16) — on a fresh vm.sh reset with-src boot as nobody: immediate Fatal trap 9 at set_user_TLS+0x68, current process = PoC pid (853), guest halts in DDB, ssh dead. panic.txt is the console capture.

Exploitability ceiling

GP is an uncontrolled fault: no write primitive, no register control

beyond the wrmsr operand the code path already fixes (ecx=MSR index, edx:eax=the base). The result is a 100%-reliable unprivileged local kernel panic (DoS). No route to uid=0 was identified; the trap handler is trap_fatal -> DDB/reboot, nothing resumable. Impact classified "panic".

Variants / related paths (same missing-validation root cause)

• which=1: wrmsr(MSR_KGSBASE) at tls.c:171 — identical #GP.
• vmspace_ctl(VMSPACE_CTL_RUN) as used by virtual kernels: user-supplied vextframe.vx_tls is copied into td_tls (sys/vm/vm_vmspace.c:293-299) and installed by set_user_TLS() (vm_vmspace.c:304); the intended guard, cpu_sanitize_tls() (sys/platform/pc64/x86_64/machdep.c:924-928), is a no-op on pc64. Same panic without ever calling set_tls_area. (Requires vm.vkernel_enable=1; the syscall-472 route has no gate.)
• Context-switch restore path (swtch.s:515-535) wrmsr's PCB_FSBASE/ PCB_GSBASE — post-fix these are always pre-validated values; the syscall-time validation is the single choke point that covers fork inheritance (vm_machdep.c:137,229) too.

Fix validation (mandatory for memory-safety/panic findings)

fix.diff (in this pack, git-apply-able; never applied to the read-only audit tree — applied only inside the guest /usr/src copy):

1. tls.c: reject non-canonical info.base with EINVAL before storing td_tls (canonical iff ((base + 0x0000800000000000) >> 48) == 0).
2. machdep.c cpu_sanitize_tls(): validate both savetls bases, closing the vmspace_ctl route (error path already restores saved TLS, vm_vmspace.c:302-306).

Patched kernel built in-guest (make nativekernel) and booted:

BASELINE (stock kernel): su -m nobody -c /tmp/tls_noncanon -> Fatal trap 9 GPF kernel mode, set_user_TLS+0x68 wrmsr, guest halted in DDB, ssh dead. (run.log / panic.txt) PATCHED (fix.diff kernel): su -m nobody -c /tmp/tls_noncanon -> syscall returns -1/EINVAL ("kernel rejected non-canonical base, errno=22"), guest stays up, no console messages. (run.2.log) full tls_edge.c matrix re-run as nobody: completes end-to-end, wild bases now EINVAL, all legitimate TLS behavior unchanged (round-trip, fork inheritance, exec reset, libc TLS of the freshly exec'd matrix binary itself). (run.3.log)

Conclusion: root cause confirmed at the exact cited lines; fix is minimal, complete over all writers of td_tls/pcb_fsbase/gsbase, and behavior-neutral for canonical bases.

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.