DF-0938 — /proc/<pid>/fpregs uninitialized kernel stack leak

Summary

procfs_dofpregs (sys/vfs/procfs/procfs_fpregs.c:54) declares struct fpreg r (512 bytes) on the kernel stack without zeroing. On the default cpu_fxsr=true amd64 path, fill_fpregs → fill_fpregs_xmm writes only 108 of those 512 bytes (env87 + sv_ac[8]). uiomove_frombuf(&r, sizeof(r), uio) then copies the full 512 bytes to userspace, leaking ~404 bytes of uninitialized kernel stack — including kernel .text/.data/heap pointers — to any local user who reads /proc/self/fpregs. Pure info leak (KASLR-defeat primitive); no corruption.

Build & run (as unprivileged user maxx)

./build.sh && ./run.sh

Equivalent manual invocation:

cc -O2 -o poc poc.c
./poc | hexdump -C | sed -n '1,40p'

Expected output

BUGGY kernel (6.5-DEVELOPMENT #0, unpatched):

read 512 bytes
~300 non-zero non-0xAA bytes in tail [108..512) (leaked kernel stack)

Hexdump offsets 0x70..0x1ff contain kernel-virtual pointers in 0xfffff8008dxxxxxx, 0xfffff80116xxxxxx, 0xffffffff80xxxxxx ranges. Variance across runs confirms uninitialized stack (not deterministic FPU state).

FIXED kernel (6.5-DEVELOPMENT #1, with fix.diff applied):

read 512 bytes
0 non-zero non-0xAA bytes in tail [108..512) (leaked kernel stack)

Hexdump shows 00 00 00 ... from offset 0x6c onward (deterministic, 3 runs).

Fix

fix.diff — adds #include <sys/systm.h> and bzero(&r, sizeof(r)) immediately after the struct fpreg r; declaration in procfs_dofpregs. Validated by building a single-fix kernel and confirming the leak disappears (see VERDICT.md).

This supersedes the finding markdown's proposed memset (which omits the required systm.h include and fails to compile under -Werror).

DF-0938 — VERDICT

Status: REPRODUCED (info leak) Impact: leak:~300 bytes of uninitialized kernel stack per /proc/self/fpregs read (includes multiple kernel-virtual pointers — direct KASLR-defeat / kernel-address disclosure). Confidence: certain Class: CWE-908 (Use of Uninitialized Resource) / CWE-200 (Info Exposure)

Verdict (one line)

REPRODUCED: reading /proc/self/fpregs as an unprivileged user leaks ~300 bytes of uninitialized kernel stack (including kernel .text/.data/heap pointers) because procfs_dofpregs declares struct fpreg r on the stack without zeroing and fill_fpregs (on the default cpu_fxsr=true amd64 path) only initializes 108 of the 512 bytes.

Mechanism (every hop cited path:line)

1. Stack-declared, unzeroed buffer. sys/vfs/procfs/procfs_fpregs.c:54 — struct fpreg r; with no initializer. struct fpreg is 512 bytes (sys/cpu/x86_64/include/reg.h:74-84: fpr_env[4]=32 + fpr_acc[8][16]=128 + fpr_xacc[16][16]=256 + fpr_spare[12]=96).

2. Partial fill on the default path. procfs_fpregs.c:63 calls procfs_read_fpregs(lp, &r) → fill_fpregs(lp, &r) (sys/platform/pc64/x86_64/machdep.c:3078). On cpu_fxsr==true — which is set unconditionally on every SSE+FXSR CPU at boot (sys/platform/pc64/x86_64/initcpu.c:227-230, i.e. every modern x86_64 including this KVM guest) — fill_fpregs calls fill_fpregs_xmm(&pcb_save.sv_xmm, (struct save87 *)fpregs) (machdep.c:3082-3085).

3. fill_fpregs_xmm writes only 108 bytes. machdep.c:3034-3053 writes only env87 (28 B: en_cw/sw/tw/fip/fcs/opcode/foo/fos) + sv_ac[8] (8 × fpacc87 = 80 B) = 108 B. It never touches sv_pad0[4] nor sv_pad[64] of the save87 overlay (sys/cpu/x86_64/include/npx.h:67-80), nor the 336-byte fpr_xacc+fpr_spare tail of struct fpreg that lies beyond the 176-byte save87 overlay.

4. Full-buffer copyout. procfs_fpregs.c:65 — uiomove_frombuf(&r, sizeof(r), uio) copies the full sizeof(r)=512 bytes to userspace. Net: ~404 bytes (4 + 64 + 336) of the buffer are uninitialized kernel stack → leaked to the reader.

5. Reachability / privilege. procfs_fpregs.c:59 checks p_trespass(curp->p_ucred, p->p_ucred); reading one's own /proc/self/fpregs returns 0 (cr1==cr2, sys/kern/kern_prot.c:1025-1026), so the read is always permitted for any local user with no privilege.

Evidence (decisive)

Unprivileged user maxx (uid 1001, not in wheel), unpatched 6.5-DEVELOPMENT #0 kernel:

$ cc -O2 -o poc poc.c && ./poc
read 512 bytes
297 non-zero non-0xAA bytes in tail [108..512) (leaked kernel stack)

Hexdump of the 512-byte read (offset 0x70 onward — the unzeroed tail — is full of kernel pointers):

00000070  88 38 49 18 01 f8 ff ff  ...  fffff80118493888
00000080  78 35 49 18 01 f8 ff ff  53 4f 9d 80 ff ff ff ff   fffff80118493578  ffffffff809d4f53
000000a0  80 01 06 4f e9 03 00 00  00 8c cb 8d 00 f8 ff ff   ...  fffff8008dcb8c00
000000d0  0a 64 cb 8d 00 f8 ff ff  80 1d d1 16 01 f8 ff ff   fffff8008dcb640a  fffff80116d11d80
00000100  f0 95 93 16 01 f8 ff ff  f0 95 93 16 01 f8 ff ff   fffff801169395f0 (×2)
00000168  c0 db 0e 81 ff ff ff ff                            ffffffff810edbc0  ← kernel .text
                                                              (proc0 = 0xffffffff81176920)

Variance proof (3 runs) — confirms uninitialized stack, not deterministic FPU state:

The pointer at 0x100 changes every run; the buffer hash changes every run → stale stack residue.

Exploit chain

None — this is a pure info leak (no write/corruption primitive). Impact ceiling is KASLR defeat / kernel address disclosure: ~404 bytes per read, including kernel .text/.data/heap pointers (e.g. 0xffffffff810xxxxx near proc0, 0xfffff80116xxxxxx heap, 0xfffff8008dxxxxxx text). Repeatable per-read with fresh residue → an attacker can aggregate pointers to deterministically resolve kernel symbols, enabling a separate kernel memory-corruption primitive that requires a known kernel VA. No uid=0 derivable from this bug alone.

PoC changes

PoC (findings/poc/DF-0938/poc.c) was correct as delivered by the reviewer — it compiled and ran first try, no source edits needed. The only changes I made were to the evidence pack: added build.sh, run.sh, VERDICT.md, manifest.json, full build.log/run.log, leak_sample.txt, env.txt, run1.bin, and the validated fix.diff.

Fix (fix.diff)

Zero-initialize struct fpreg r before fill_fpregs touches it, so the unpopulated regions cannot leak stack bytes. Adds #include <sys/systm.h> (for bzero, matching the idiom in the sibling procfs_vfsops.c:86) and bzero(&r, sizeof(r)) immediately after the declaration:

struct fpreg r;
bzero(&r, sizeof(r));   /* zero unpopulated tail so uiomove_frombuf can't leak stack */

This supersedes the finding markdown's proposal (which used memset without the required #include <sys/systm.h> — the kernel builds with -Werror=implicit-function-declaration, so the literal markdown fix fails to compile; switching to bzero + the systm.h include compiles clean). The defensive suggestion in the markdown (also zero in procfs_doregs/procfs_dodbregs) is sound but out of scope for this single finding.

Fix validation (Phase 8)

Built a single-fix kernel (make -j6 nativekernel, .c-only change → fast incremental) on the with-src base, installed kernel.stripped → /boot/kernel/kernel, rebooted into 6.5-DEVELOPMENT #1: Sun Jul 12 12:25:37 UTC 2026 (sha256 b97a7729c4309033e2d9e719793c5702612ac59ac21f3230a3ff628b2a9aeb2a).

→ fixed: the leak is gone on the patched kernel and present on the unpatched baseline. Clean before/after.

Kernel references (verified during this run)

• sys/vfs/procfs/procfs_fpregs.c:54 — struct fpreg r; declared on stack, unzeroed.
• sys/vfs/procfs/procfs_fpregs.c:63 — procfs_read_fpregs(lp, &r) → fill_fpregs.
• sys/vfs/procfs/procfs_fpregs.c:65 — uiomove_frombuf(&r, sizeof(r), uio) copies full 512 B.
• sys/platform/pc64/x86_64/machdep.c:3078-3085 — fill_fpregs branches to fill_fpregs_xmm when cpu_fxsr.
• sys/platform/pc64/x86_64/machdep.c:3034-3053 — fill_fpregs_xmm writes only 108 B (env87 + sv_ac[8]).
• sys/platform/pc64/x86_64/initcpu.c:227-230 — cpu_fxsr=1 on every SSE+FXSR CPU (default on modern x86_64).
• sys/cpu/x86_64/include/reg.h:74-84 — struct fpreg is 512 bytes.
• sys/cpu/x86_64/include/npx.h:67-80 — struct save87 (176 B) overlay; sv_pad0[4] + sv_pad[64] never written by fill_fpregs_xmm.
• sys/kern/kern_prot.c:1025-1026 — p_trespass returns 0 when reading own cred (unprivileged reachability).