DF-0207 — Memory leak in clist_alloc_cblocks (missing kfree of old c_data)

See VERDICT.md for the full analysis (root cause, proof, reachability nuance).

Reproduce (the leak)

./build.sh                 # builds the userspace trigger + the kld harness
sudo ./run.sh              # kldload harness; vmstat -m | grep ttys before/after

UNPATCHED kernel: M_TTYS MemUse jumps 143K -> ~29M (leak). FIXED kernel: M_TTYS MemUse stays 143K (flat, no leak).

The harness (df0207_harness.c) calls clist_alloc_cblocks() directly with a changing ccmax, which is the definitive proof the bug leaks on every resize.

Fix

fix.diff adds kfree(odata, M_TTYS) of the old buffer before overwriting cl->c_data. Validated: single-fix kernel #1 boots; harness no longer leaks (M_TTYS flat). See fix_run.log.

DF-0207 — Memory leak in clist_alloc_cblocks() (missing kfree of old c_data)

Verdict: REPRODUCED (leak primitive definitively demonstrated via direct invocation). Impact: leak / DoS — unbounded M_TTYS kernel-memory exhaustion. Not memory corruption, so there is no privilege-escalation chain; the ceiling is kmem-exhaustion DoS.

The bug (root cause)

sys/kern/tty_subr.c, clist_alloc_cblocks():

48: void
49: clist_alloc_cblocks(struct clist *cl, int ccmax)
50: {
51:     short *data;
...
61:     data = kmalloc(ccmax * sizeof(*data), M_TTYS, M_INTWAIT|M_ZERO);
...
71:         bcopy(cl->c_data + cl->c_cchead, data, n * sizeof(*data));   /* copy OLD -> new */
...
80:     cl->c_data = data;     /* <-- overwrites the OLD pointer WITHOUT kfree() */
81: }

Compare with clist_free_cblocks() (lines 86-100) which does kfree(data, M_TTYS). Every time ccmax != cl->c_ccmax (a resize), the previous c_data buffer is orphaned — a permanent leak of old_ccmax * sizeof(short) bytes of M_TTYS.

Proof (direct harness)

Because the finding's claimed unprivileged vector (pty + tcsetattr baud change) does not actually change ccmax on this guest (see Reachability note below), a kernel-module harness (df0207_harness.c) calls clist_alloc_cblocks() directly with an alternating ccmax (1024 ↔ 4096), 3000 iterations. Measured with vmstat -m | grep ttys:

~5860 c_data buffers orphaned, ~29 MB of M_TTYS permanently leaked. Each subsequent clist_alloc_cblocks(cl, X) where X != cl->c_ccmax leaks again — unbounded.

Reachability (important nuance)

• The bug fires whenever a clist's ccmax changes. Callers that resize: tty.c:1664/2435/2457/2489 (ttsetwater / ttypend), netgraph ng_tty/ng_h4, if_sl (SLIP).
• The finding's stated trigger is partly incorrect: for a pty, t_ispeedwat/t_ospeedwat are 0 (never set by the pty driver), so ttsetwater()'s case 0: makes the computed outq/rawq buffer sizes constant regardless of baud (outq ccmax is always imax(ohiwat,2048)+OBUFSIZ+100; ohiwat clamps to ≤2048 for any speed). The early return if (ccmax == cl->c_ccmax) return; then prevents any realloc, so tcsetattr baud changes on a pty do not leak.
• The only in-tree driver that sets t_*speedwat = (speed_t)-1 (the speed-dependent case that does vary ccmax with baud) is sio.c:2480-2481 (the COM serial driver). On this guest /dev/ttyd0 (sio0) is root:wheel 0600 — not openable by an unprivileged user — and it is the live console, so its baud-change path could not be driven from userspace here.
• Conclusion: the leak is real and unbounded on any code path that resizes a clist. The realistic trigger on a stock system is a serial/tty driver or netgraph/SLIP path that varies ccmax; the unprivileged-pty+baud vector claimed by the finding does not hold. Reported as a confirmed leak (DoS-class), reachability = needs a ccmax-change path (sio baud / driver / netgraph), not a blanket unprivileged trigger.

The fix

fix.diff saves the old c_data pointer (odata) before overwriting cl->c_data, and kfree(odata, M_TTYS)s it afterward (guarding NULL). Minimal, targeted, mirrors clist_free_cblocks.

Fix validation

Built a single-fix kernel (DF-0207 fix only) on the with-src baseline: - Unpatched #0 baseline: harness load → M_TTYS 143K → 29.4M (leak). - Patched kernel: harness load → M_TTYS stays flat (~143K, only the legitimately-live buffers) — leak eliminated.

(See run.log / fix_run.log for the before/after vmstat -m lines.)

Kernel refs

• sys/kern/tty_subr.c:61 — kmalloc of new data
• sys/kern/tty_subr.c:80 — cl->c_data = data without kfree (the leak)
• sys/kern/tty_subr.c:99 — clist_free_cblocks correctly kfrees (reference)
• sys/kern/tty.c:2489 — ttsetwater outq resize call site
• sys/dev/serial/sio/sio.c:2480 — only driver setting t_*speedwat = -1