DF-0775 — PoC Evidence Pack

Finding: RPC reply verifier-length integer overflow corrupts XDR cursor — wild pointer deref client kernel panic or OOB read

Verdict: NOT REPRODUCED (false positive for claimed impact)

TL;DR

The signed overflow in nfsm_rndup(i) IS real, and info->dpos IS corrupted (dpos += INT_MIN, jumping ~2 GiB backwards). However, the subsequent nfsm_dissect() bounds check truncates its pointer-difference to int, which makes the comparison fail and routes to nfsm_disct(), returning EBADRPC. The claimed wild-pointer dereference (*tl == 0 at line 1509) is never reached. No panic, no OOB read — only EBADRPC, which is the same error any malformed RPC reply produces.

Files

How to reproduce

./build.sh                 # build the malicious server
# as root inside the guest:
./run.sh                   # start server, mount, test

Expected: ls: /mnt_df0775: RPC struct is bad (EBADRPC). Guest stays up. No panic.

Why the claimed impact doesn't manifest

See VERDICT.md for the full disassembly proof. Short version:

1. nfsm_rndup(0x7FFFFFFD) wraps to INT_MIN ✓
2. nfsm_adv(info, INT_MIN) corrupts info->dpos ✓ (confirmed by disassembly of nfsm_adv @ 0xffffffff80814520)
3. nfsm_dissect(info, 4) computes int n = ptrdiff — the 64-bit pointer difference (≈ 2³¹) truncates to a negative 32-bit int ✓
4. bytes <= n → 4 <= negative → FALSE → routes to nfsm_disct → returns EBADRPC ✓ (confirmed by disassembly cmp %esi,%ecx)
5. The wild pointer is never returned, never dereferenced ✓

DF-0775 — VERDICT

Verdict: NOT REPRODUCED (false positive for claimed impact)

Finding title: RPC reply verifier-length integer overflow corrupts XDR cursor — wild pointer deref client kernel panic or OOB read

Claimed impact: kernel panic (wild pointer dereference) or OOB kernel memory read when a malicious NFS server replies with verifier_len ∈ {0x7FFFFFFD, 0x7FFFFFFE, 0x7FFFFFFF}.

Actual observed impact: EBADRPC — the NFS operation fails gracefully. No panic, no OOB read, no kernel memory disclosure. The guest remains fully stable after 21+ malicious replies.

What IS real

The finding correctly identifies three things in sys/vfs/nfs/nfs_socket.c:nfs_request_processreply():

1. No bounds check on verifier length (line 1498): c i = fxdr_unsigned(int32_t, *tl); /* full int32 range, no bound */ The server-side path at line 2347 checks if (len < 0 || len > RPCAUTH_MAXSIZ) — the client-side does not.

2. Signed overflow in nfsm_rndup (line 1505): c ERROROUT(nfsm_adv(info, nfsm_rndup(i))); /* nfsm_rndup(a) = (((a)+3) & (~0x3)) — overflows for a near INT_MAX */ For i = 0x7FFFFFFD: (0x7FFFFFFD + 3) & ~3 = 0x80000000 = INT_MIN.

3. dpos corruption in nfsm_adv (nfsm_subs.c:916-918): c n = mtod(info->md, caddr_t) + info->md->m_len - info->dpos; if (n >= len) { /* 0 >= INT_MIN → TRUE (signed) */ info->dpos += len; /* dpos += INT_MIN → wild pointer, ~2 GiB back */ Confirmed by disassembly of nfsm_adv @ 0xffffffff80814520: the cmp %esi,%ecx / jl at 8081453f-80814541 does NOT jump for ecx=0, esi=0x80000000 (because 0 >= INT_MIN is true in signed comparison), so the in-place dpos += sign_extend(INT_MIN) at 80814543-8081454b executes, corrupting dpos.

What does NOT happen (the claimed impact)

The finding claims that after dpos is corrupted, nfsm_dissect(info, 4) at line 1507 returns the wild pointer, which is then dereferenced at line 1509 (if (*tl == 0)).

This is false. nfsm_dissect() never returns the wild pointer. The reason is a int n truncation in the bounds check:

void *nfsm_dissect(nfsm_info_t info, int bytes) {
    int n;                                              /* ← 32-bit! */
    n = mtod(info->md, caddr_t) + info->md->m_len - info->dpos;
    /*      ↑ 64-bit pointer arithmetic, result is ptrdiff_t (64-bit)   */
    if (bytes <= n) {        /* n is truncated to int before compare    */
        ptr = info->dpos;    /* ← wild pointer — ONLY reached if n >= 4 */
        ...
    } else {
        error = nfsm_disct(...);  /* ← returns EBADRPC for our case     */
    }
}

After the dpos corruption, the pointer difference (m_data + m_len - dpos_corrupted) is a huge 64-bit value (≈ 2³¹ + original_remaining). Truncated to int, this is negative (0x80000000 + small → still bit-31 set → negative as signed int). The signed comparison 4 <= (negative) is FALSE, so the code routes to nfsm_disct(), which also detects the bad state and returns EBADRPC. The wild pointer is never returned, never dereferenced.

Disassembly proof — nfsm_dissect @ 0xffffffff80815170:

80815191:  sub    %rax,%rcx       ; rcx = (m_data+m_len) - dpos  [64-bit]
80815194:  cmp    %esi,%ecx       ; 32-BIT: compares ecx (lower 32) with bytes
80815196:  jl     808151b0        ; ecx(0x80000000) < esi(4) signed → JUMP TAKEN
                                  ; → falls into nfsm_disct → EBADRPC

The cmp %esi,%ecx instruction explicitly compares the lower 32 bits (%ecx) of the 64-bit pointer difference against bytes (%esi). The compiler did NOT optimize away the int n intermediate — it honors the C type and truncates. For any practical mbuf size (≤ 4 KiB), the truncated value is always negative, so the wild-pointer path is unreachable.

Mathematical proof the wild pointer is unreachable

Let R = original remaining bytes in the current mbuf (0 ≤ R ≤ ~4096). After corruption: ptrdiff = R + 2³¹. Truncated to int: n = (int)(R + 0x80000000). For 0 ≤ R < 2³¹ (always true for mbufs): n = R + 0x80000000 which has bit 31 set → n < 0. Since bytes = 4 > 0, bytes <= n is 4 <= negative → always FALSE. The wild pointer is returned only if n >= 4, which requires R >= 2³¹ — impossible for an mbuf.

Reproduction evidence

A malicious NFS/RPC server (malicious_server.c) was built and run on the guest. It implements: - portmap v2 (UDP/TCP 111) → returns port 2049 for all GETPORT - rpcbind v3/v4 → PROG_MISMATCH (forces fallback to portmap v2) - NFS NULL proc → valid reply (satisfies mount_nfs userspace probe) - NFSv2 MOUNT proc → valid reply with a 32-byte dummy file handle - All other NFS procs (kernel RPCs) → reply with verifier_len=0x7FFFFFFD

mount_nfs -2 -o tcp,port=2049,ro 127.0.0.1:/x /mnt succeeded. The kernel NFS client then sent 21+ GETATTR RPCs, each receiving the malicious verifier. Every operation returned EBADRPC:

$ ls /mnt_df0775
ls: /mnt_df0775: RPC struct is bad

The guest never panicked. No trap, no page fault, no kernel message. The kernel was completely stable throughout.

Server log excerpt:

[ok]   prog=100003 vers=2 proc=0 xid=0x... (NULL — mount_nfs userspace)
[ok]   prog=100000 vers=2 proc=3 xid=0x... (portmap GETPORT → 2049)
[ok]   prog=100005 vers=1 proc=1 xid=0x... (MOUNT → dummy FH)
[EVIL] prog=100003 vers=2 proc=1 xid=0x5E5944DD -> verifier_len=0x7FFFFFFD
[EVIL] prog=100003 vers=2 proc=1 xid=0x5E5944DE -> verifier_len=0x7FFFFFFD
... (21 total kernel RPCs with malicious verifier)

Exploit chain

Not applicable — this is not a memory-corruption primitive. The dpos corruption is real but the corrupted pointer is never dereferenced due to the int n truncation defense in nfsm_dissect(). There is no write primitive, no read primitive, no control-flow hijack. The only observable effect is EBADRPC, which is the same error any malformed RPC reply would produce. This is not exploitable for privilege escalation.

Recommended fix (defense-in-depth)

Although the claimed impact does not manifest, the underlying code has a legitimate hardening gap: the client-side verifier length is unbounded while the server-side caps at RPCAUTH_MAXSIZ (400). A future compiler change, code refactor, or different architecture could remove the int truncation defense and expose the dpos corruption. The fix matches the existing server-side check:

i = fxdr_unsigned(int32_t, *tl);
if (i < 0 || i > RPCAUTH_MAXSIZ) {   /* ← add this */
    error = EBADRPC;
    goto nfsmout;
}

See fix.diff. This supersedes the finding markdown's proposal (which suggested the same bound check plus a redundant nfsm_adv length check — the latter is unnecessary since the bound check eliminates the overflow entirely).