DF-2558 — leaked-byte variance samples (unpatched #0 baseline)
==============================================================

Three standalone runs of `./poc 3` (3 sysctl reads each). Per-iteration
"leaked non-zero bytes" totals shown, plus the always-uninitialized
xu_alignment_hack (8 B, never written by the handler) value, which is a
canonical kernel-virtual pointer in every record of every run.

Run 1 (run.log):     3 iters / 39 records -> 12375 / 18972 non-zero bytes
Run 2 (run.2.log):   3 iters /             -> 12049 / 18796 non-zero bytes
Run 3 (run.3.log):   3 iters / 36 records -> 11268 / 17432 non-zero bytes

The totals vary run-to-run (genuine stack-residue variation in the
xu_addr / xu_caddr tail unions), proving real uninitialized memory rather
than deterministic struct contents.

--- xu_alignment_hack (8 B, pure residue, NEVER written by unp_pcblist) ---
Every record, every run:
    90870e81 ffffffff
=> little-endian 0xffffffff810e8790  (canonical x86_64 kernel-virtual ptr)
This field is declared at the very end of struct xunpcb (unpcb.h:126) and
the handler never assigns it, so it is guaranteed-uninitialized and is the
single cleanest proof of the leak.

--- per-record typical leak (bound dgram socket, sun_len ~18) ---
    xu_addr  tail [sun_len..256):  ~150-157 non-zero bytes
    xu_caddr leak (whole 256 B if no peer, else tail): ~130-173 non-zero bytes
    xu_alignment_hack [..+8): 8 non-zero bytes
    => ~290-340 non-zero leaked bytes per record out of ~460-510 possible

The residue contains many 0xfffff8??_???????? and 0xffffffff_???????? qwords —
recognizable kernel pointer fragments (KASLR-defeat / stack-residue oracle).

Read-only primitive: the handler only copies bytes OUT to userspace; it
writes no attacker-controlled data into the kernel. There is no write/UAF/
type-confusion path derivable from this sysctl — the leak itself is the
finding (CWE-908 uninitialized stack disclosure / CWE-200 info exposure).