DF-3204 — krpc_call leaks the reply mbuf chain on the RPC_PROGMISMATCH exit

File: sys/vfs/nfs/krpc_subr.c:391-396 (leaking exit), :437-441 (the out: path that never frees m) Severity: Low · CWE-401 · verified in VERIFY mode with the verbatim-interposition kernel-compiled rig (dfrig13_krpc.c, sha256-gated #include of the production krpc_subr.c; real UDP stack, real mbufs, userland attacker attacker.c mode pmis).

What was reproduced (baseline kernel #1)

The attacker answers each request with an in-bounds 24-byte accepted reply whose rp_status = 2 (RPC_PROGMISMATCH, bytes 20..23 on the wire — no OOB involved). The verbatim code at :393-395 executes error = EBADRPC; goto out; with m still owning the soreceive-d reply chain, and the out: path frees only mhead and from and closes the socket — m is never freed.

mbufs before: 7/146632 mbufs in use
mbufs after:  57/146632 mbufs in use     # 50 calls -> exactly +50 leaked

(run.log T3: 50/50 calls returned EBADRPC.)

Control (T33, honest replies transferred to the caller and freed):

mbufs before control: 57   ->   after: 57     # +0

DF-3203 coupling (the same leak taken via the uninitialized read): planting 0x00000002 at mbuf offset 20..23 with the userland primer and sending a 16-byte short reply → 3/3 calls returned EBADRPC with exactly +3 leaked mbufs (run.couple.log, detailed in the DF-3203 pack) — the leak exit taken on a stale value, and incidentally the same path a v2-only mountd drives during the normal md_mount v3→v1 fallback (nfs_mountrpc.c :140-163: v3 EBADRPC → v1 retry, one leaked chain per boot RPC).

Fix validation (kernel #2)

With fix.diff (m_freem(m); m = NULL; before the goto out): 50/50 calls still return EBADRPC (PROGMISMATCH semantics unchanged) and

mbufs before: 8  ->  after: 8     # +0 — leak gone

honest control stays flat (run.fixed.log).

Reproduce (on the DragonFly guest)

sh build.sh                     # gate + build + install; reboot
sh run.sh                       # T3 leak (+50) + T33 control (+0)
# fix validation:
sh build.sh af834f6e30225b1af68cc83cbcdaf25e29e0e39ca6deaec6f3c13663a661b886 ; reboot
sh run_fixed.sh                 # (in DF-3205 pack) T3 +0

Files in this folder

DF-3204 — VERDICT (verified 2026-10-20, VERIFY mode)

REPRODUCED (resource leak: one reply mbuf chain per RPC_PROGMISMATCH exit; bounded, no UAF) — demonstrated through the verbatim production code on the guest (kernel #1; sha256-gated include of krpc_subr.c; the rig calls the real krpc_call over the real UDP stack; the attacker is the userland mode-pmis server).

Mechanism, line-accurate :391-395 — when the (in-bounds) reply status equals RPC_PROGMISMATCH the code does error = EBADRPC; goto out; while m still owns the chain soreceive stored into sio.sb_mb at :367. The out: path (:437-441) frees mhead (:438) and from (:439) and closes the socket (:440) — m is never freed. Every neighboring exit either NULLs m (loop top :352-355), transfers it (gotreply :431) or cannot have one.

Baseline numbers (netstat -m first line, "N/M mbufs in use") - T3, 50 in-bounds PROGMISMATCH replies: 50/50 calls returned EBADRPC; mbufs 7 -> 57, exactly +50, still allocated afterwards (re-checked after a 2 s settle). One leaked mbuf per call, linear, persistent. - T33 control, 50 honest replies (caller frees the returned chain): 57 -> 57, +0. The differential isolates the PROGMISMATCH exit. - Coupling with DF-3203 (stale value, not wire status): userland primer planting 0x00000002 at mbuf offset 20..23 followed by a 16-byte short reply -> 3/3 calls EBADRPC, mbufs 7 -> 10 (+3); the leak exit taken purely on the uninitialized rp_status read. - Real-world trigger unchanged from the finding: md_mount tries MOUNT v3 first and falls back to v1 on EBADRPC (nfs_mountrpc.c:140-163), so a v2-only mountd leaks one chain per boot RPC; a spoofed PROGMISMATCH (DF-3205 delivery) leaks one per reply.

Impact / privesc assessment Low as filed: bounded memory leak (handful of mbufs per boot; even a persistent spoofer is rate-limited by the boot RPC pattern), no UAF, no double free — the chain is simply orphaned while still marked allocated. Not a local unpriv->root vector; krpc is boot-path only (no runtime callers on a disk-root guest). Recorded impact is the availability effect (kernel mbuf pool consumption), which is honest but small; the fix is one line.

Fix validation (kernel #2 = baseline + fix_all.diff) fix.diff adds m_freem(m) + m = NULL before the goto out. A/B: 50/50 calls still EBADRPC (semantics preserved); mbufs 8 -> 8 (+0); honest control flat; no regression in the other suites (DF-3205 T5 6/6, DF-3203 short replies gated).

Artifacts: run.log (T3 +50 / T33 +0 netstat brackets), pmis.log, good.log, run.couple.log (stale-value coupling), run.fixed.log (fixed +0), fx_pmis.log, fx_good.log, build_summary.log.

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.