DF-0007 — PoC

leak_sigaction.c — unprivileged leak of up to 4 bytes of kernel stack via the trailing padding of struct sigaction returned by sigaction().

The issue

On amd64 struct sigaction (sys/sys/signal.h:221) is 32 bytes with 4 bytes of trailing padding at offset 28-31:

offset  0: union __sigaction_u (8)   -- written
offset  8: int sa_flags       (4)    -- written
offset 12: sigset_t sa_mask   (16)   -- written (full assignment)
offset 28: <trailing padding> (4)    -- NOT written  <-- LEAK
sizeof = 32 (struct alignment 8)

sys_sigaction() (sys/kern/kern_sig.c:384) stack-allocates oact uninitialized; kern_sigaction() (:260-279) writes oact field-by-field but never the trailing padding; copyout(oactp, uap->oact, sizeof(oact)) (:397) copies all 32 bytes — leaking the 4 uninitialized kernel-stack bytes. i386 is unaffected (sizeof == 24, no trailing pad).

Build

cc -o leak_sigaction leak_sigaction.c

Run

As an unprivileged user on amd64:

./leak_sigaction

Expected output (bug present, e.g. unpatched 6.5-DEVELOPMENT #0)

sizeof(struct sigaction) = 32
sample: 00 00 00 00 00 00 00 00  00 00 00 00 ff fe fe ff  ff ff ff ff ff ff ff ff  ff ff ff ff | 00 f8 ff ff  (pad word 0xfffff800)
... (8/8 samples) ...
samples with non-marker non-zero padding (leaked residue): 8/8
result: LEAK CONFIRMED

The padding word (00 f8 ff ff = 0xfffff800) is a kernel-address-space pointer fragment leaked from the kernel stack — it is neither the 0xAA marker the buffer was filled with nor a value the kernel wrote to a named field. The exact value is deterministic for this syscall path but is genuinely uninitialized kernel-stack residue at offset 28-31.

Expected output (bug FIXED — single-fix kernel 6.5-DEVELOPMENT #1)

sample: 00 00 00 00 00 00 00 00  00 00 00 00 ff fe fe ff  ff ff ff ff ff ff ff ff  ff ff ff ff | 00 00 00 00  (pad word 0x00000000)
...
samples with non-marker non-zero padding (leaked residue): 0/8
result: no residue observed (padding zero/defined)

The fix (fix.diff) zero-initializes the act/oact structs at the sys_sigaction declaration, so the trailing padding is defined (zero) before copyout. The named fields (offsets 0-27) are unchanged.

Leak-detection logic

A sample is counted as leaked residue iff the trailing 4 bytes are neither the 0xAAAAAAAA marker (what the userland buffer was memset with) nor 0x00000000 (zero = defined by the fix). On the buggy kernel the padding holds non-zero kernel-stack residue; on the fixed kernel it is zero.

DF-0007 — Verification Verdict

1. The claim (and why it is correct)

On amd64, struct sigaction (sys/sys/signal.h:221-228) is laid out as:

offset  0: union __sigaction_u { void(*)(int); void(*)(int,siginfo*,void*); }  (8 bytes)
offset  8: int sa_flags                                                          (4 bytes)
offset 12: sigset_t sa_mask   /* unsigned int __bits[_SIG_WORDS=4] */            (16 bytes)
offset 28: <trailing alignment padding>                                          (4 bytes)  <-- NOT a named field
sizeof(struct sigaction) == 32   (struct alignment is 8)

sigset_t is unsigned int __bits[4] (sys/sys/_sigset.h:35-39, 16 bytes), so sa_mask sits directly after sa_flags with no internal gap; the only uninitialized region is the 4 trailing padding bytes at offset 28-31.

In sys_sigaction (sys/kern/kern_sig.c:384):

struct sigaction act, oact;          /* uninitialized stack variables */

kern_sigaction (sys/kern/kern_sig.c:260-279) writes only the named fields:

if (oact) {
    oact->sa_handler = ps->ps_sigact[_SIG_IDX(sig)];   /* offset 0-7  */
    oact->sa_mask    = ps->ps_catchmask[_SIG_IDX(sig)];/* offset 12-27 */
    oact->sa_flags   = 0;                              /* offset 8-11  */
    /* ... |= SA_* ... into sa_flags ... */
}

— it never writes offset 28-31. Then sys_sigaction does (sys/kern/kern_sig.c:397):

error = copyout(oactp, uap->oact, sizeof(oact));   /* copies all 32 bytes */

which propagates the 4 uninitialized trailing bytes to userspace. The data flow was traced line-by-line and matches the finding exactly. On i386 the union is 4 bytes and sizeof(struct sigaction) == 24 (no trailing pad), so i386 is unaffected.

2. Reproduction on the unpatched #0 baseline

PoC leak_sigaction.c: memset's a userland buffer with the 0xAA marker, calls sigaction(SIGUSR1, NULL, &oact), and inspects the trailing 4 bytes (offset 28-31) plus the full 32-byte struct. Run as the unprivileged user maxx (uid 1001, not in wheel).

Decisive baseline output (3/3 identical runs):

sizeof(struct sigaction) = 32
layout: [0..7]=sa_handler [8..11]=sa_flags [12..27]=sa_mask [28..31]=<padding>
sample: 00 00 00 00 00 00 00 00  00 00 00 00 ff fe fe ff  ff ff ff ff ff ff ff ff  ff ff ff ff | 00 f8 ff ff  (pad word 0xfffff800)
... (8/8 samples identical) ...
samples with non-marker non-zero padding (leaked residue): 8/8
result: LEAK CONFIRMED

Leaked value: 00 f8 ff ff = 0xfffff800. This is a kernel-address-space pointer fragment (DragonFly maps kernel text/data in the high 0xfffff8xx... region). It is: - not the 0xAAAAAAAA marker the userland buffer was filled with (so copyout overwrote the user buffer entirely — as expected), - not a value the kernel wrote to a named field (offsets 0-27: handler=SIG_DFL=0, flags=0, mask=the catch-mask — all distinct from the padding), - a non-zero residue from a kernel-stack slot the syscall path leaves at that offset.

The exact value is deterministic for this syscall path (the same stack frame is set up the same way each call), which is normal for a stack-residue leak via a deterministic syscall — the bytes are genuinely uninitialized kernel memory the kernel never wrote at offset 28-31. 4 bytes leaked per call, fully reproducible. impact = leak:4bytes.

3. Exploit chain

Not applicable — this is a pure read-only info leak (CWE-908). There is no write primitive, no corruption, and therefore no escalation chain. The realistic impact ceiling is a weak kernel-stack-residue / KASLR-assist oracle: an unprivileged local user can sample up to 4 bytes of stack residue per sigaction() call. On this guest KASLR is already OFF, so the leak is primarily a hardening defect; on a KASLR-enabled kernel it would be a (weak) information ingredient.

4. PoC changes I made

The reviewer-supplied PoC compiled and ran first try, but its leak criterion (padding != 0xAAAAAAAA marker) false-positives on a fixed kernel: the fix zeroes the padding, so the fixed kernel reads 0x00000000, which is != marker and was incorrectly counted as a leak. I sharpened it: - Dumps the full 32 bytes per sample so the leak region (offset 28-31) is visually distinct from the kernel-written fields (offsets 0-27). - Corrected the leak criterion to padding != marker && padding != 0: leaked residue is non-zero kernel-stack data; a zero padding is defined (the fix wrote it), not leaked. The finding's own README states "On a fixed kernel the padding reads as the marker or zero", so this matches the intended fixed behavior. - Added a dirty_stack() helper (pipe/sysctl/getpid/getuid) between samples to maximize visible residue.

Build/run are unchanged: cc -o leak_sigaction leak_sigaction.c then ./leak_sigaction as an unprivileged user.

5. The fix (fix.diff)

Zero-initialize both act and oact at the sys_sigaction declaration so the trailing padding is defined before kern_sigaction fills the named fields and copyout ships the whole struct. Per C11 6.7.9 §21, { 0 } zero-fills the entire aggregate including padding bytes.

--- a/sys/kern/kern_sig.c
+++ b/sys/kern/kern_sig.c
@@ -381,7 +381,7 @@
 int
 sys_sigaction(struct sysmsg *sysmsg, const struct sigaction_args *uap)
 {
-   struct sigaction act, oact;
+   struct sigaction act = { 0 }, oact = { 0 };
    struct sigaction *actp, *oactp;
    int error;

This matches the finding markdown's ## Recommended fix proposal (the finding used the GNU = {} form; I used the standard-portable = { 0 } form, which gcc 8.3 accepts and which C11 guarantees zero-fills padding). act is fully overwritten by copyin anyway, but initializing it is harmless defense-in-depth and keeps the declaration symmetric.

6. Phase 8 — fix validation on a built single-fix kernel

8a. Baseline (unpatched #0, with-src snapshot): the PoC reproduces the leak (0xfffff800, 8/8 samples, 3/3 runs) — the "before" half. (run.log, run.2.log, run.3.log.)

8b/8c. Apply + build: applied only fix.diff to /usr/src, built make -j6 nativekernel KERNCONF=X86_64_GENERIC MODULES_OVERRIDE= (modules unchanged — the fix is in the main kernel). Clean build, rc=0, kern_sig.o rebuilt (18:21 UTC). (fix_build.log.)

8d. Install + reboot: the on-disk /boot/kernel/kernel carries the schg (system immutable) flag, so a bare cp fails with EPERM and make installkernel fails on the unbuilt modules (cam.ko: No such file); the correct install is chflags noschg → cp kernel.stripped → chmod 555 → chflags schg, then sync; reboot. After reboot kern.version bumped #0 → #1 (Tue Jul 14 18:37:19 UTC 2026) with sha256 d58a88a829940202e643cbf9d0d4fd18f8094492a03a0136aca7ba7a4c4df348. (One earlier attempt to reboot after an unclean vm.sh down force-kill left the loader unable to read the kernel ("Unable to load /kernel/kernel"); recovered with vm.sh reset with-src and a clean sync; reboot.)

8e. Re-run the PoC on the patched #1 kernel (3 runs, identical):

sample: 00 00 00 00 00 00 00 00  00 00 00 00 ff fe fe ff  ff ff ff ff ff ff ff ff  ff ff ff ff | 00 00 00 00  (pad word 0x00000000)
... (8/8 samples identical) ...
samples with non-marker non-zero padding (leaked residue): 0/8
result: no residue observed (padding zero/defined)

The trailing padding is now 0x00000000 — zero-initialized by the fix — on every sample, every run. The named fields (offsets 0-27) are byte-identical to the baseline (the fix does not change kern_sigaction's field writes), confirming the fix only changed the padding.

8f. Classification: fixed. The leaked residue (0xfffff800) present on the unpatched #0 baseline is gone (now 0x00000000) on the single-fix #1 kernel, deterministically, across 3 runs — while the baseline still reproduces it across 3 runs. Clean before/after.

7. Conclusion

The finding is REPRODUCED as an Info-class info leak (4 bytes of kernel-stack residue per call via the uninitialized trailing padding of struct sigaction), and the proposed fix (zero-init the struct at the sys_sigaction boundary) is VALIDATED on a built and booted single-fix kernel: the leak disappears deterministically. No escalation chain applies (pure read-only leak). Guest reset to with-src (#0 unpatched baseline) at the end of the run.