DF-3205 — krpc_call zero-entropy XIDs + no reply-source filtering

File: sys/vfs/nfs/krpc_subr.c:201,:256-262,:282,:348-351,:380,:432-435 Severity: Medium · CWE-330 · verified in VERIFY mode on the QEMU guest with the verbatim-interposition kernel-compiled rig dfrig13_krpc.c (sha256-gated #include of the production krpc_subr.c; no socket seams — the rig calls the real krpc_call/krpc_portmap over the real UDP stack on lo0, and the attacker is a real userland process).

What was reproduced (baseline kernel #1)

1. Blind predicted-XID spoof of the first RPC of a boot (blindboot.sh, run as the first rig activity after a fresh boot): the client call used xid 0xffffff00 — computed by the attacker purely from the source constants (static_xid = ~0xFF, krpc_subr.c:201, incremented once per call at :282) without ever reading a request payload — and the forged portmap GETPORT reply was accepted: krpc_portmap err=0 port bytes ca fe, i.e. the attacker chose the port the diskless client will contact next (the first step of becoming its NFS authority).
2. Determinism dump (test 5): six sequential calls carried xids 0xffffff01..0xffffff06 (+1 per call, continuing the counter) and every request came from reserved UDP port 1023 (the deterministic sweep :256-262 rebinding the same free port per call).
3. Wrong-origin acceptance (test 1): a reply sent from 127.0.0.2 (not the server address in the request) was accepted — payload ATTA… from ATTACKER-PAYLOAD. krpc_call never connect()s the socket and frees/discards the soreceive source address (:348-351, :432-435); the only content filter is the xid compare at :380.
4. End-to-end portmap authority hijack (test 4): spoofed GETPORT reply → client adopts the attacker-chosen port (ca fe).
5. Live side note: the resend loop (:315 for(;;)) has no global deadline — a run whose attacker stops replying spins forever printing RPC timeout for server 127.0.0.1 every ~5 s (observed twice).

Fix validation (kernel #2, fix_all.diff; single-finding hunk = fix.diff)

Same tests on the fixed kernel: xids are karc4random()-backed and non-sequential (0x07d0b1bd, 0x01e5b8d7, 0xb88a504a, …; blind predictions all differ), the wrong-origin reply from 127.0.0.2 is dropped (call completes on the legitimate-origin follow-up with payload SERV…), the blind portmap spoof is rejected (client takes the follow-up answer, port bytes 77 77), and honest replies still work (6/6, no regression). See run.fixed.log / fx_*.log.

Reproduce (on the DragonFly guest)

sh build.sh          # verbatim sha256 gate + make nativekernel + installkernel; reboot
sh blindboot.sh      # decisive: first-call-of-boot blind spoof (fresh boot only!)
sh run.sh            # determinism dump + wrong-origin + portmap (sniffed) tests
# fix validation:
sh build.sh af834f6e30225b1af68cc83cbcdaf25e29e0e39ca6deaec6f3c13663a661b886 ; reboot
sh run_fixed.sh

Files in this folder

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

REPRODUCED — every element of the finding demonstrated on the guest through the verbatim production code (sha256-gated #include of krpc_subr.c compiled into kernel #1; rig drives the real UDP stack; attacker = userland process).

1. Zero-entropy XID, proven blind krpc_subr.c:201 static u_int32_t static_xid = ~0xFF; and :282 xid = atomic_fetchadd_int(&static_xid, 1);. On a fresh boot the first krpc call of the machine used xid 0xffffff00 — predicted by the attacker from the source constants alone (attacker flag -b: it never reads the request payload; blindboot.log: "REQ #1 ... xid=0xffffff00 ... blind prediction for this call: 0xffffff00 MATCH"). The subsequent counter sequence 0xffffff01..06 was observed one-per-call (dump.log), and the coupling run (run.couple.log, another fresh boot) matched predictions 3/3. NetBSD seeds this counter from cprng; DragonFly does not.

2. No reply-source filtering krpc_call never connect()s the UDP socket; the only content filter is the xid compare at :380. soreceive captures the reply origin into from, but :348-351 frees it every loop iteration and :432-435 only hands it out for broadcast callers — the real callers (md_mount, md_lookup_swap in nfs_mountrpc.c:146,163,253,256) all pass from_p == NULL. Demonstrated: a reply from 127.0.0.2 (not the requested server 127.0.0.1) was accepted, payload ATTACKER-PAYLOAD (run.log T1 marker "err=0 payload='ATTA'"; attacker log "spoof sent from 127.0.0.2").

3. Deterministic reserved-port sweep :256-262 sweeps 1023 downward; every request of every run came from UDP port 1023 (all attacker logs), because each call rebinds the same first free reserved port. Prediction of the client endpoint is therefore trivial.

4. Authority hijack end-to-end krpc_portmap (krpc_subr.c:127-178) hands its caller the port from whatever reply krpc_call accepted: the blind spoof made the verbatim code return the attacker-chosen bytes (err=0, port bytes ca fe; blindboot.log). In the boot scenario (md_mount -> krpc_portmap for MOUNT, then krpc_call to the returned port) this is precisely the primitive that lets a third party on the boot LAN serve the root filesystem of a diskless client. The rig stops at the portmap seam (md_mount itself is out of scope for this finding), so full root-FS adoption was not re-driven here; the identical chain was however demonstrated end-to-end for the sibling BOOTP rig DF-3044 (bootpc_decode_reply -> md_mount adoption markers).

5. Resend loop with no global deadline (secondary, observed live) When the attacker stops answering, the for(;;) at :315 resends forever, printing "RPC timeout for server ..." about every 5 s (observed twice; the stuck sysctl thread never returns). The finding notes this; no extra test was needed.

Impact / privesc assessment On the standard disk-root guest there is NO runtime path to krpc (callers: nfs_mountrpc.c only, reached from nfs_mountroot at nfs_vfsops.c:557/943 during diskless mountroot), so this is not a local unpriv->root escalation here. The threat is the boot network: any LAN host (no IP spoofing needed — delivery is to the client 1023/UDP endpoint, xid guessable, origin unchecked) becomes the portmap/mountd/NFS authority of a booting diskless client, which in deployment means attacker-chosen root filesystem = full compromise of the client. In-rig the demonstrated manifestation is acceptance of the forged authority (integrity) plus the infinite-resend hang (availability); the poc impact enum has no auth-bypass value, so the closest manifested value is recorded ("dos") with this ceiling documented — same treatment as the DF-3044 BOOTP sibling.

Fix validation (kernel #2 = baseline + fix_all.diff, gate sha af834f6e30225b1af68cc83cbcdaf25e29e0e39ca6deaec6f3c13663a661b886) - xid = karc4random() (fix hunk 1): fx_dump.log shows 0x07d0b1bd/0x01e5b8d7/0xb88a504a/0x6d5d8e23/0xe974921d/0x77a3ea43 — no sequence; blind predictions all "differ". - reply source must equal sa (address AND port) (fix hunk 2): the 127.0.0.2 spoof is dropped; T1 completes on the legitimate-origin follow-up (payload SERV). The blind pmap spoof is dropped; T4 completes on the follow-up answer (port bytes 77 77). - no regression: honest replies still complete 6/6 (T5) and the pmis/control loops behave as on baseline for their own findings.

Rig honesty notes - The blind attacker still learns the client UDP endpoint from recvfrom() — equivalent to a boot-LAN sniffer seeing the unicast request go by; the quantity the xid is supposed to protect (the ability to forge a reply without observing the request) is what was defeated, and on the baseline it did not exist. - "usched :1" pins rig and attacker to CPU0 for objcache magazine locality (DragonFly has no cpuset(1)); 127.0.0.2 requires an lo0 alias (scripts add it).

Artifacts: run.blindboot.log (decisive blind acceptance), run.log, dump.log/spoof.log/pmap.log (attacker view), run.fixed.log + fx_*.log (A/B), build.log/build_fixed.log (full builds + gate lines), env.txt.

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.