DF-3203 — krpc_call reads rpc accept-status 8 bytes past the validated region

File: sys/vfs/nfs/krpc_subr.c:356-373 (dead chain-level gate), :391 (pre-m_pullup rp_status read), :417 (the pullup that comes too late) Severity: Low · CWE-125 · 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).

What was reproduced (baseline kernel #1)

A 16-byte "accepted" RPC reply (xid + direction + astatus only) passes every gate — len < MIN_REPLY_HDR at :370 is dead code because sbinit() zeroes sb_cc and soreceive counts the delivered bytes into it, so len -= sio.sb_cc at :366 yields the residual 65536−16, never < 16 for any UDP datagram — and reply->rp_status (offset 20..23 of a 24-byte struct) is then read at :391 before the m_pullup(24) at :417: 4 bytes of stale kernel-heap content beyond the 16-byte datagram, which is

1. printed to console/dmesg by the verbatim kprintf("rpc denied, status=%d\n") at :397, and
2. used for control flow: 0 → gotreply → m_pullup(24) fails on the 16-byte mbuf → spurious ENOBUFS abort (krpc_subr.c:417-419); 2 (RPC_PROGMISMATCH) → EBADRPC leak exit (the DF-3204 path); anything else → the console print and continue.

Attribution (the value is heap memory, not wire data)

• Userland-planted primer, 18/18 deterministic: the attacker sprays 24-byte datagrams to a dead port carrying pattern P at offset 20..23 (their mbufs are freed with P in place), then sends the 16-byte short reply — the verbatim code reads and prints exactly P: pattern 0x5a5a5a5a → rpc denied, status=1515870810 9/9; pattern 0x3cc33cc3 → rpc denied, status=1019428035 9/9 (run.attrib.log, primer_leak_sample.txt). Bytes 16..23 do not exist in a 16-byte datagram: no on-wire content can produce these values.
• Kernel-side groom hit: uniform 0xc3 fill → rpc denied, status=-1010580541 = exactly (int)0xc3c3c3c3 (run.2.log).
• Raw residue across runs: 943337777/943337779 (= ASCII "8:11" / "8:13" timestamp fragments), 153789694, 357452694 (run.log, leak_sample.txt, canary_dump.txt) — uninitialized heap that varies run to run.
• Stale==0 branch: multiple attempts abort with ENOBUFS when the slot previously held a successful reply (status 0 written at +20..23).
• Stale==RPC_PROGMISMATCH coupling: primer pattern 0x00000002 → 3/3 calls return EBADRPC with exactly +3 leaked mbufs (run.couple.log) — DF-3203 steering execution into the DF-3204 leak exit on a value the attacker never put on the wire as a status.

No kernel panic occurs (the read stays inside the mbuf slab allocation), hence no panic.txt; the disclosed artifact is canary_dump.txt.

Fix validation (kernel #2)

With fix.diff (len = received sb_cc, require the full 24-byte header, m_pullup before any field read): the short reply is dropped at the gate, zero verbatim rpc denied, status= lines appear (strict grep ^rpc denied = 0 on the fixed boot; the only matches of the loose phrase are the rig marker text), the call completes on the honest follow-up reply, and honest replies are unaffected (6/6 in the DF-3205 suite).

Reproduce (on the DragonFly guest)

sh build.sh                     # gate + build + install; reboot
sh attrib.sh                    # primer attribution (2 patterns x 3 rounds)
sh run.sh                       # kernel-groom canaries + groom32 coupling
# fix validation:
sh build.sh af834f6e30225b1af68cc83cbcdaf25e29e0e39ca6deaec6f3c13663a661b886 ; reboot
sh run_fixed.sh                 # (in DF-3205 pack) strict rpc-denied count stays 0

Files in this folder

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

REPRODUCED (leak: 4 stale kernel-heap bytes per triggering reply, printed to console, steering control flow) — demonstrated through the verbatim production code on the guest (kernel #1; sha256-gated include of krpc_subr.c; real UDP stack on lo0; real mbufs; userland attacker).

Mechanism, line-accurate - :356-357 len = 1 << 16; sbinit(&sio, len); — sbinit() zeroes sb_cc and stores the limit (sys/sys/sockbuf.h:115-126). - uipc_socket.c:1277 soreceive computes the budget from sb_climit - sb_cc and appends the record into sio, counting the DELIVERED bytes into sb_cc (sockbuf.h:83). - :366 len -= sio.sb_cc; therefore yields 65536 - received — the residual capacity, which for any UDP datagram (max 65507) is far above MIN_REPLY_HDR=16, so the chain-level gate :370 is dead code. - The only working gate is m->m_len >= 16 (:372), but the struct is 24 bytes: rp_astatus (8..11) is read in-bounds at :384, while rp_status sits at offset 20..23 and is read at :391 BEFORE the m_pullup(sizeof(struct rpc_reply)) that only happens at :417 after gotreply. A 16..19-byte "accepted" reply makes :391 read 4..8 bytes past the datagram inside the mbuf data area — stale heap.

Observed manifestations (baseline kernel #1) 1. Console/dmesg disclosure: the verbatim kprintf at :397 printed stale values that vary run to run: 943337777 and 943337779 (0x383a3131 / 0x383a3133 = ASCII "8:11" / "8:13" — timestamp string fragments), 153789694, 357452694 (binary residue). 2. Deterministic attacker-planted value, 18/18: userland-only primer (24-byte datagrams to a dead port carry pattern P at offset 20..23; those mbuf slots are freed with P intact; the next short reply recycles one). P = 0x5a5a5a5a -> status=1515870810 9/9; P = 0x3cc33cc3 -> status=1019428035 9/9 (run.attrib.log). A 16-byte datagram cannot carry bytes 16..23, so the printed value cannot be wire data; the kernel-side groom canary 0xc3 also hit once (-1010580541 = (int)0xc3c3c3c3) in an earlier boot. 3. Control flow on stale memory: stale==0 attempts aborted with ENOBUFS (m_pullup(24) on the 16-byte mbuf fails at :417-419); stale==2 (primer pattern 0x00000002) returned EBADRPC and leaked exactly +3 mbufs in 3 attempts (run.couple.log) — the DF-3204 exit taken on an uninitialized value. No panic: the read stays inside the mbuf allocation, so INVARIANTS do not trip; the disclosed artifact is canary_dump.txt (no panic.txt by design of the bug class).

Impact / privesc assessment Low as filed: 4 bytes of uninitialized kernel heap per spoofed short reply, disclosed to console/dmesg (and boot serial logs), plus stale value steering boot-RPC control flow. Not a local unpriv->root vector: krpc runs only during diskless mountroot (no runtime syscall path reaches it on this disk-root guest). Reachability requires the boot-network attacker of DF-3205 (or a misbehaving server), which makes the short reply trivially deliverable — the two findings compound.

Fix validation (kernel #2 = baseline + fix_all.diff) fix.diff replaces the dead residual math with the received length (len = (int)sio.sb_cc), requires the full 24-byte header before any field access, and pulls the header up front (m_pullup before the direction/xid/astatus/status reads). A/B: on the fixed kernel the 16-byte short reply is dropped at the gate; strict grep for verbatim "^rpc denied, status=" over the whole fixed boot = 0 lines (the only loose-phrase matches are the rig marker text); the call completes on the honest follow-up; honest replies unaffected (6/6 in the DF-3205 T5 suite; PROGMISMATCH detection unchanged — DF-3204 T3 still returns EBADRPC 50/50). No regression observed.

Rig honesty notes - Attribution needed CPU pinning ("usched :1", both the groom and the attacker) because DragonFly objcache magazines are per-CPU; without pinning the stale value is whatever the slot last held (still proving the read, less crisp attribution). - The harness marker text prints the EXPECTED value with the words "verbatim console line is: ... (check dmesg)"; the authoritative observed value is the column-0 dmesg line captured by run.sh / attrib.sh — run.fixed.sh counts those strictly.

Artifacts: run.attrib.log (18/18), run.couple.log (stale==2 -> EBADRPC, +3 mbufs), run.log / run.2.log (residue + groom hit + ENOBUFS), canary_dump.txt / primer_leak_sample.txt / leak_sample.txt, run.fixed.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.