DF-5713 — stack_protector.c: kernel stack-smashing protection is a no-op

What this PoC proves (all demonstrated live on the QEMU guest)

1. The canary is a compile-time constant, never seeded. sys/libkern/stack_protector.c:36 (int __guard = 0x00000aff;) is the only definition/assignment of __guard in the entire tree (tree-wide grep). Live proof: - /dev/kmem read of the running kernel's __guard (0xffffffff8113bae0): ff 0a 00 00 = 0x00000aff — run.2.log - KLD guard_probe.ko reads the exported symbol: __guard=0xaff — run.2.log / msgbuf - The shipped /boot/kernel/kernel ELF .data cell at the symbol address holds ff0a0000 — identical, i.e. nothing rewrote it at boot. - Two independent fresh boots (vm.sh reset with-src) read the same ff 0a 00 00 — no per-boot seeding exists (run.2.log, run.4.log).

2. The modern stack-protector ABI does not exist in the kernel. sys/ contains no __stack_chk_guard/__stack_chk_fail definition (tree-wide grep) and nm /boot/kernel/kernel confirms absence. A KLD compiled with -fstack-protector-all (ssp_smash_ssp.ko, manually built because the build system strips the flag) fails to load: link_elf_obj_obj: symbol __stack_chk_guard undefined — panic.txt / console_full.log.

3. Kernel code is force-built WITHOUT any stack protector. sys/platform/pc64/conf/kern.mk:7 — CFLAGS+= -fno-stack-protector ... (grep of the guest's /usr/src). The default-built ssp_smash.ko performs a 48-byte strcpy into a 16-byte kernel-stack buffer and the kernel dies instantly with the saved frame pointer smashed: frame pointer = 0x10:0x4242424242424242 ... Stopped at boom+0x2c: ret — panic.txt. No canary sits between the buffer and the saved frame.

4. The legacy fail path works but is attached to nothing. guard_panic.ko calls __stack_smash_handler() directly → panic: stack overflow in function guard_panic_smash_test — panic2.txt.

Build

# on the guest (sources pushed via the pack below):
cc -O2 -o /tmp/guest/guard_read /tmp/guest/guard_read.c
cd /tmp/guest/guard_probe && make -m /usr/share/mk
cd /tmp/guest/guard_panic && make -m /usr/share/mk
cd /tmp/guest/ssp_smash    && make -m /usr/share/mk        # default (no SSP)
# SSP variant (build system strips -fstack-protector-all, so compile by hand):
cc <kern flags> -fstack-protector-all -c ssp_smash.c -o ssp_smash_ssp.o
cc -nostdlib -r -o ssp_smash_ssp.ko ssp_smash_ssp.o        # exact flags in build.log

Run

/tmp/guest/guard_read 0xffffffff8113bae0 /dev/kmem   # -> ff 0a 00 00, rc=42
kldload /tmp/guest/ssp_smash/ssp_smash_ssp.ko        # -> Undefined symbol __stack_chk_guard
kldload /tmp/guest/guard_probe/guard_probe.ko        # -> __guard=0xaff
kldload /tmp/guest/ssp_smash/ssp_smash.ko            # -> kernel GPF, fp=0x4242...42 (PANIC)
kldload /tmp/guest/guard_panic/guard_panic.ko        # -> panic: stack overflow in function ... (PANIC)
# leave the guest clean:  vm.sh reset with-src

Expected results

See the four numbered points above; all captured in build.log, run.log, run.2.log, run.3.log, run.4.log, panic.txt, panic2.txt, console_full.log.

DF-5713 VERDICT — reproduced (hardening failure; impact: none by itself)

Bottom line: every factual claim of the finding was demonstrated live on the DragonFly 6.5-DEVELOPMENT X86_64_GENERIC guest. The kernel's only stack-canary symbol, __guard, is a compile-time constant (sys/libkern/stack_protector.c:36, 0x00000aff) that is never seeded from any entropy source at any point in boot; the modern __stack_chk_guard/__stack_chk_fail ABI is absent from the kernel entirely; and sys/platform/pc64/conf/kern.mk:7 force-disables -fstack-protector for all kernel and KLD code. The "security-critical mitigation layer" therefore protects exactly nothing: it is 51 lines of dead code force-linked into every pc64 kernel (sys/platform/pc64/conf/files:119), whose only exported value is a publicly-known constant.

Mitigation-family checklist (as tasked)

(a) Canary source / seeding vs first use

• Source: sys/libkern/stack_protector.c:36 (0x00000aff LE) / :38 (0xff0a0000 BE) — a link-time constant in .data, not karc4random.
• Tree-wide grep for __guard writes: only lines 36/38. No SYSINIT, no reseed, nothing. The DF-5694/5695 (arc4 bias) and DF-2243 (zero-window) concerns are moot but in the worst way: the entropy path does not exist at all, so the canary is not "weakly random" — it is known to everyone who can read the public source.
• Live: /dev/kmem reads ff 0a 00 00 on two independent fresh boots (run.2.log, run.4.log); the ELF .data cell at 0xffffffff8113bae0 holds the same bytes; KLD guard_probe.ko reads 0xaff through the exported symbol. Constant from link time through runtime, forever.

(b) Guard placement / infoleak surface

• Single global int in .data at a fixed link-time address (ffffffff8113bae0 on this build), exported in the kernel symbol table (nm), readable by any loaded KLD and by root via /dev/kem///dev/mem. Not per-CPU, not per-boot. There is nothing to leak, though — the value is public in the source. (sys/libkern/stack_protector.c:36)
• Notably the file is force-linked into every pc64 kernel via sys/platform/pc64/conf/files:119 (libkern/stack_protector.c standard) even though no in-tree code references __guard or __stack_smash_handler (tree-wide grep) — pure dead weight. sys/conf/files:2219 has the equivalent line commented out; pc32 (i386) doesn't list the file at all.

(c) Fail path

• __stack_smash_handler() panics with stack overflow in function <name> (sys/libkern/stack_protector.c:49; i386 variant at :47 prints the caller PC from 4(%ebp) — cosmetic only, and that asm is dead for amd64). Demonstrated live: loading guard_panic.ko → panic: stack overflow in function guard_panic_smash_test with a clean backtrace through module_register_init (panic2.txt). The handler works; it is simply connected to no instrumentation.

(d) Terminator-canary property

• LE value bytes in memory: ff 0a 00 00 — first NUL at byte 2, not byte 0. A proper terminator canary places the NUL in the lowest byte so an ascending strcpy stops inside the canary before touching anything past it. Here a byte-string overflow first clobbers ff 0a (both publicly known, so an attacker with a controlled copy simply re-writes them) and terminates inside the canary. With a known constant canary the property is irrelevant anyway: any arbitrary-content overflow primitive (memcpy/bcopy/read) forges all 4 bytes. The BE variant (0xff0a0000 → bytes 00 00 0a ff low→high) has the NUL low, ironically correct — but pc64 is LE.

The decisive live demonstration (why this is a real hardening failure)

The default-built KLD ssp_smash.ko (exactly what bsd.kmod.mk produces: -fno-stack-protector forced by sys/platform/pc64/conf/kern.mk:7) executes a textbook 48-byte strcpy into a 16-byte kernel-stack buffer:

Fatal trap 9: general protection fault while in kernel mode
frame pointer   = 0x10:0x4242424242424242
Stopped at      boom+0x2c:      ret

The saved RBP is 0x4242… — the attacker payload — and the kernel dies at boom's ret on the way to the smashed return address. There is no canary anywhere in that frame, because no kernel/KLD code is ever instrumented. The identical module recompiled with -fstack-protector-all (by hand; the build system silently strips the flag) cannot even load: link_elf_obj_obj: symbol __stack_chk_guard undefined — the kernel provides no modern ABI to link against.

Exploit chain

None developed — none exists through this file. The finding is a missing mitigation (CWE-693), not a corruption primitive: unprivileged attack surface of the file itself is zero (it defines two symbols and a panic). The impact is systemic: every kernel stack-overflow bug in DragonFly lands on unprotected frames, so any such bug elsewhere in sys/ is strictly more exploitable than on a stack-protected kernel; and if SSP were enabled without fixing the file, the only available canary (__guard, propolice ABI) is a publicly-known constant — also decorative.

Why not uid0 / why impact=none

The panics in the evidence were root-deliberate (kldload of a test module). No unprivileged-reachable path through this file exists. Severity Low (hardening/defense-in-depth), confidence certain.

Fix validation

Not performed (fix_status: not_testable): the fix (fix.diff — modern __stack_chk_guard/__stack_chk_fail, SYSINIT seeding from karc4random_buf() after arc4_init_pcpu() has run, kern.mk switched to -fstack-protector-strong) requires a full kernel rebuild/boot cycle whose payoff is a hardening A/B, not a behavior A/B of a reproduced corruption. git apply --check passes against the tree. Upstream should build/boot-test fix.diff (especially the kern.mk hunk) before commit.

Guest state

Guest panicked twice (both deliberate evidence runs), restored with vm.sh reset with-src after each; final state: up, clean snapshot, read-only /dev/kmem probe only after the last reset. guest_dirty: 0.

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.