DF-3009 — VERDICT

REPRODUCED — malicious-server client kernel panic (NULL-pointer dereference at a fixed virtual address), verified on the stock guest kernel, then fix validated on a patched kernel build.

Root cause (path:line)

• sys/vfs/nfs/nfs_socket.c:648 — the SOCK_STREAM receive path parses the SunRPC record mark: len = ntohl(len) & ~0x80000000;
• sys/vfs/nfs/nfs_socket.c:653 — the only sanity check is if (len > NFS_MAXPACKET). A record mark of exactly 0x80000000 (LASTFRAG, length 0) is accepted. (The server-side twin, nfsrv_getstream() at sys/vfs/nfs/nfs_socket.c:2743, does reject ns_reclen <= 0 — the client lacks the equivalent check.)
• sys/vfs/nfs/nfs_socket.c:665 — sbinit(&sio, len) with len == 0 gives sb_climit == 0; sorecvtcp() (sys/kern/uipc_socket.c:1723) immediately takes the resid == 0 → release path and returns 0 with an empty mbuf chain (sio.sb_mb == NULL).
• sys/vfs/nfs/nfs_socket.c:672 — the short-receive guard if (error == 0 && sio.sb_cc != len) compares 0 != 0 and does not fire; *mp = sio.sb_mb stays NULL and nfs_receive() returns success.
• sys/vfs/nfs/nfs_socket.c:861-862 — nfs_reply(): info.md = info.mrep; (NULL) then info.dpos = mtod(info.md, caddr_t); which is a load of ((struct mbuf *)NULL)->m_data — virtual address 0x10 (offsetof(struct m_hdr, mh_data) = 8+8). Unconditional page fault in kernel mode.

Trigger chain

1. Malicious (or compromised) NFS server, NFS program spoken over TCP.
2. mount_nfs -o tcp ... handshake answered honestly (rpcbind/mountd + NULL-proc ping), so the mount succeeds.
3. Any subsequent kernel RPC over the TCP connection (e.g. the GETATTR issued by stat /mnt, or the async reader thread for bio requests) is answered with exactly 4 bytes: 80 00 00 00.
4. Client kernel panics before xid matching — the fault is in the reply pre-parse, so the xid/proc of the pending request is irrelevant.

Baseline run (stock kernel #0 Thu Jul 2 06:02:54 UTC 2026)

sh run.sh:

MOUNT_OK
... ssh session dies with the guest ...

serial console (see panic.txt):

Fatal user address access from kernel mode from stat at ffffffff808021a2
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x10
fault code      = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff808021a2
current process = 1087 (stat)
Stopped at      nfs_reply+0x622:        movq    0x10(%rax),%rax

vm.sh status → down. Faulting instruction is the mtod(NULL) load — exactly the predicted site (nfs_socket.c:862).

Exploitability beyond DoS

The primitive is a kernel-mode read of a fixed unmapped address (0x10). There is no offset control and no write; userland cannot map page 0 into the kernel on this platform. Verdict: reliable client DoS/panic only, no escalation path. (Classification: impact=panic, not uid0_privesc.)

Fix validation (kernel #0 Sat Sep 5 05:04:56 UTC 2026)

fix.diff applied to the guest's /usr/src, make nativekernel KERNCONF=X86_64_GENERIC + make installkernel, reboot, exact same PoC:

• mount still succeeds (MOUNT_OK),

• stat /mnt does not panic; the console shows the new rejection firing 30× followed by the normal reconnect/retry loop:

  kernel: impossible packet length (0) from nfs server 127.0.0.1:/P kernel: receive error 27 from nfs server 127.0.0.1:/P

• vm.sh status → up throughout; hard-mount retry (stat blocking while a dead server never answers) is pre-existing designed behavior, not a regression. Guest then reset to the clean snapshot.

fix_status: fixed (baseline reproduced → patched not reproduced, same PoC, same options).

Honesty notes

• One earlier mount attempt in the same session failed with "Program not registered" — that was self-inflicted (my DF-3010 rpcbind occupied UDP 111); not a PoC defect. After cleanup the baseline reproduced on the first clean attempt.
• The nfs_reply() NULL-mrep case is also reachable through the nfsiod reader thread (sys/vfs/nfs/nfs_iod.c:96 calls the same nfs_reply(nmp, NULL)), so async READ/WRITE replies hit the same line.