DF-0592 — PoC: uninitialized kernel stack leak via fairq_getqstats copyout

Privileged local info-leak PoC. fairq_getqstats (sys/net/altq/altq_fairq.c:278) declares struct fairq_classstats stats; on the stack without zeroing (line 282). The helper get_class_stats (altq_fairq.c:974-1001) only populates a subset of the struct fields — compiler-inserted padding bytes plus the entire red[3] array (when the class uses Q_DROPTAIL, the default) remain uninitialized. copyout((caddr_t)&stats, ubuf, sizeof(stats)) at altq_fairq.c:312 copies the full 224-byte struct unconditionally, leaking up to 176 bytes of stale kernel stack per DIOCGETQSTATS call.

The same defect exists in altq_priq.c:priq_getqstats and altq_hfsc.c:hfsc_getqstats (identical stack-declared, partially-populated *_classstats struct); fix.diff closes all three.

Files

• fairq_leak.c — full driver: DIOCXBEGIN/DIOCADDALTQ x2 (discipline + Q_DROPTAIL class) / DIOCXCOMMIT / DIOCGETALTQS / DIOCGETALTQ / DIOCGETQSTATS, then hex-dumps the uninitialized regions of the returned struct.
• build.sh — cc -O2 -o fairq_leak fairq_leak.c
• run.sh — kldload pf.ko (system setup) + ./fairq_leak vtnet0
• run.log — decisive unpatched run (LEAK CONFIRMED)
• run.2.log,run.3.log — additional leak runs (variance)
• baseline_unpatched.log — Phase 8 baseline reproduction on #0
• fix_run.log — Phase 8 patched-kernel run (leak GONE)
• fix_build.log — single-fix kernel build log (35k lines, rc=0)
• leak_sample.txt — 4-run variance sample
• env.txt — guest uname / cc / kldstat
• fix.diff — git-apply-able fix for fairq + priq + hfsc
• VERDICT.md — full narrative
• manifest.json — catalog

Build & run

./build.sh                       # cc -O2 -o fairq_leak fairq_leak.c
sudo ./run.sh                    # kldload pf.ko ; ./fairq_leak vtnet0

(Or directly: cc -O2 -o fairq_leak fairq_leak.c && sudo ./fairq_leak vtnet0.)

Expected output (unpatched kernel)

Hex dump of the returned struct fairq_classstats showing non-zero bytes at struct offsets 12-15, 52-55, and 56-223 (the uninitialized regions). Many of those bytes look like kernel text/data pointers (0xffffffff8xxxxxxx on amd64) — stale stack frames recovered from prior kernel call paths. On the default GENERIC with-src kernel a typical leak is 124-138 non-zero bytes out of 176, with 27-29 kernel-pointer-looking 8-byte windows per call.

=== uninitialized-region analysis ===
  region [ 12.. 15] (  4 bytes) padding(qlimit->xmit_cnt) : 4 non-zero bytes
  region [ 52.. 55] (  4 bytes) padding(qtype->red[0])    : 4 non-zero bytes
  region [ 56..223] (168 bytes) red[3] (Q_DROPTAIL: ...)  : 130 non-zero bytes

TOTAL non-zero bytes in uninitialized regions: 138 / 176
kernel-pointer-looking 8-byte windows in red[] region: 29
RESULT: LEAK CONFIRMED — 138 bytes of uninitialized kernel stack returned to userspace.

Expected output (patched kernel — fix.diff applied)

  region [ 12.. 15] (  4 bytes) padding(qlimit->xmit_cnt) : 0 non-zero bytes
  region [ 52.. 55] (  4 bytes) padding(qtype->red[0])    : 0 non-zero bytes
  region [ 56..223] (168 bytes) red[3] (Q_DROPTAIL: ...)  : 0 non-zero bytes

TOTAL non-zero bytes in uninitialized regions: 0 / 176
RESULT: no leak — all uninitialized regions are zero.

Notes

• /dev/pf is 0600 root:wheel (sys/net/pf/pf_ioctl.c:3360). The PoC must run as root (or with /dev/pf delegated, e.g. a jail with /dev/pf). This is a Low info-leak finding (CVSS PR:H/C:L); the realistic attacker is already privileged. No privilege escalation; the leak is the whole impact.
• kldload pf.ko is system setup, not part of any escalation chain — it makes the pf subsystem available. The kernel-side bug (fairq_getqstats) ships in the base GENERIC kernel (compiled in via options ALTQ_FAIRQ); pf.ko is the standard userland-facing module.
• The same defect exists in altq_priq.c:priq_getqstats and altq_hfsc.c:hfsc_getqstats. fix.diff patches all three with the identical memset(&stats, 0, sizeof(stats)) immediately after the declaration in each *_getqstats function.

DF-0592 — VERDICT

Verdict

REPRODUCED. Uninitialized kernel stack bytes are leaked to userspace through the FAIRQ altq DIOCGETQSTATS ioctl path. The same defect also exists in the priq and hfsc disciplines (identical code pattern); fix.diff closes all three.

Mechanism (trigger → primitive → effect)

1. Trigger. A privileged local user (root or any process holding /dev/pf, which is 0600 root:wheel per sys/net/pf/pf_ioctl.c:3360) configures a FAIRQ discipline on an interface with a Q_DROPTAIL class (the default — no FARF_RED/FARF_RIO flags), then issues DIOCGETQSTATS (sys/net/pf/pfvar.h:1707). The ioctl dispatches through pfioctl (sys/net/pf/pf_ioctl.c:2097) → altq_getqstats (sys/net/altq/altq_subr.c:677) → fairq_getqstats (sys/net/altq/altq_fairq.c:278).

2. Primitive. In fairq_getqstats the kernel declares struct fairq_classstats stats; on the stack without zeroing (altq_fairq.c:282). The helper get_class_stats (altq_fairq.c:974-1001) writes only: - class_handle, qlimit, xmit_cnt, drop_cnt, qtype, qlength (lines 978-988) — covering offsets 0-11, 16-47, 48-51 of the 224-byte struct. - Conditionally sp->red[0] (Q_RED) or sp->red[0..2] (Q_RIO).

It never touches: - (a) 4 bytes of padding at offset 12-15 (between qlimit and xmit_cnt, needed to align pktcntr to 8 bytes); - (b) 4 bytes of padding at offset 52-55 (between qtype and red[0], needed to align struct redstats to 8 bytes); - (c) when qtype == Q_DROPTAIL (the default — cl_qtype is set to Q_DROPTAIL=0x03 in fairq_class_create at altq_fairq.c:436 unless FARF_RED/FARF_RIO are set), the entire red[3] array (168 bytes at offset 56-223).

Total leak surface per call: 176 bytes (out of 224).

3. Effect. copyout((caddr_t)&stats, ubuf, sizeof(stats)) at altq_fairq.c:312 copies the full 224-byte struct to userspace unconditionally, leaking all 176 uninitialized bytes.

Reproduction evidence (unpatched #0 baseline)

On the default GENERIC with-src kernel (6.5-DEVELOPMENT #0) as root with pf.ko loaded, four independent runs of ./fairq_leak vtnet0 returned:

RUN 1: 138/176 non-zero bytes,  29 kernel-pointer-looking 8-byte windows
RUN 2: 124/176 non-zero bytes,  27 kernel-pointer-looking 8-byte windows
RUN 3: 126/176 non-zero bytes,  27 kernel-pointer-looking 8-byte windows
RUN 4: 133/176 non-zero bytes,  28 kernel-pointer-looking 8-byte windows

Sample bytes (RUN 1, region 56-223): fe@57 9a@58 89@59 f8@61 ff@62 ff@63 b0@64 c8@65 67@66 80@67 ff@68 ff@69 ...

The byte-for-byte variance across runs at offsets 80-103 proves these are genuine stale stack frames (not deterministic struct contents); the re-occurring 0xffff..., 0xffffffff80..., 0xffffffff81... windows are kernel text/data pointers from prior call frames — directly useful as KASLR-defeat input (KASLR is OFF on this guest, but the leak holds on hardened kernels too).

Exploit chain

None. This is a pure info-leak (CWE-200). No write primitive, no corruption, no escalation chain. Realistic impact ceiling: up to 176 bytes of stale kernel stack disclosed per call, repeatable, containing kernel text/data pointers usable for KASLR bypass. The attacker is already privileged (/dev/pf 0600 root:wheel), so the direct operational impact is bounded; the leak is most valuable as input to a separate primitive in a chained exploit.

PoC changes from the filing-time sketch

The PoC source fairq_leak.c did not exist in the folder at run time — the README described it as a "sketch" to be materialized by the verifier. I wrote a complete driver from scratch that:

• Uses the actual DragonFly pf ioctl interface — DIOCXBEGIN + PF_RULESET_ALTQ to obtain the altq-transaction ticket (NOT DIOCBEGINALTQS — that constant is defined in pfvar.h but is not wired to a case in pf_ioctl.c; altq begin/commit are only reachable via the batched DIOCXBEGIN/DIOCXCOMMIT path with rs_num = PF_RULESET_ALTQ = PF_RULESET_MAX = 5).
• Adds the FAIRQ discipline first (qname="", scheduler=ALTQT_FAIRQ, ifbandwidth=10Mbps) on the chosen interface, then a class named "def" on the same interface (the kernel auto-discovers the parent discipline by ifname match at pf_ioctl.c:2038-2044, and auto-allocates a non-zero qid via pf_qname2qid).
• Walks the active list with DIOCGETALTQS/DIOCGETALTQ to find the queue entry (the one with qname[0] != 0).
• Issues DIOCGETQSTATS with pq.buf poisoned with 0xAA first, so even a partial-overlap (e.g. if a future kernel truncates the copyout) would be visible.
• Analyzes the three known-uninitialized regions (offsets 12-15, 52-55, 56-223) and reports non-zero byte counts plus a kernel-pointer scan.
• Corrected the qtype labels: Q_RED=0x01, Q_RIO=0x02, Q_DROPTAIL=0x03 (from sys/net/altq/altq_classq.h:48-50, not the 0/1/2 the original sketch guessed).

No fix to the underlying claim was needed — the finding's mechanism description is accurate end-to-end.

Fix validation (Phase 8)

Authored fix.diff: a single memset(&stats, 0, sizeof(stats)) line added immediately after the local-variable declarations in each of fairq_getqstats, priq_getqstats, and hfsc_getqstats. Minimal and targeted at the root cause.

fix.diff supersedes the finding markdown's proposal (which only fixed fairq_getqstats): I extended the identical one-line memset to priq_getqstats and hfsc_getqstats because they have the same line-for-line bug pattern (stack-declared, partially-populated *_classstats struct). The finding itself flagged these as needing the same fix, so this is a straightforward superset.

Honesty notes / caveats

• The bug is deterministic and 100% reproducible on every call. The variance in non-zero count (124-138 of 176) is because the leaked stack bytes themselves vary, not because the leak sometimes fires.
• pf.ko must be loaded (kldload pf.ko) for /dev/pf to exist. That is normal system setup (the standard shipped pf module), not a privilege-escalation step; the finding already requires root to open /dev/pf (0600 root:wheel), so there is no privilege boundary being crossed by kldload.
• /dev/pf exists only when pf.ko is loaded — fresh boot does not have it. The bug is still real on any DragonFly deployment that actually uses ALTQ/pf (routers, VPN concentrators, jails with delegated /dev/pf).