DF-3779 VERDICT — REPRODUCED (mechanism, protocol-replica) — impact: panic

Bottom line

A single hostile RX completion descriptor with an in-bounds rxd_idx, sop=1, and qid >= nrxqueues makes vmxnet3_rxq_eof() select RX ring 1, which the driver leaves unpopulated (all vrxb_m == NULL) on every default configuration. The local m fetched at if_vmx.c:2223 stays NULL through the sop path and if_vmx.c:2265-2266 write through it → supervisor write to a fixed near-NULL address (0x18 observed) → fatal trap 12 → guest kernel panic. The KASSERTs guarding the ring/btype invariants (if_vmx.c:2224, 2241-2249) are compiled out on production kernels.

Why source-certain

• Ring selection from rxcd->qid with no validation: if_vmx.c:2217-2220 (same pattern in vmxnet3_rxq_discard_chain, if_vmx.c:2086-2089).
• qid is a 10-bit host field (if_vmxreg.h:148); DragonFly never negotiates more than 1 RX queue (MSI-X unsupported on DFly: if_vmx.c:812-813 errors out, vmxnet3_check_multiqueue() if_vmx.c:587-589 forces 1/1) — so any qid != 0 selects ring 1.
• Ring 1 unpopulated at default MTU: if_vmx.c:2563-2581 (populate = 1 whenever frame_size <= MCLBYTES(2048) + MJUMPAGESIZE(4096), i.e. every MTU <= 6126); ring 1's rxbuf array is only ever zero-filled (vmxnet3_init_rxq, if_vmx.c:1047-1048 M_ZERO).
• vmxnet3_newbuf() at if_vmx.c:2257 refills rxbuf[idx] after m was fetched — the NULL local is dereferenced regardless.
• The completion ring, the descriptors and update_rxhead all live in host-writable shared DMA memory (the driver itself reads host-written stats back from the same page: if_vmx.c:3684-3753).

How it was proven on the guest

Protocol-replica KLD (vmxrep.c) — copies the exact ring structures and the verbatim sop-path code of vmxnet3_rxq_eof, with the hostile descriptor injected as the host would DMA it. Run on DragonFly 6.5-DEVELOPMENT X86_64_GENERIC (production kernel, no INVARIANTS):

vmxrep3779: m == NULL (ring 1 unpopulated); if_vmx.c:2265 ... next
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x18
fault code            = supervisor write data, page not present
Stopped at vmxrep_sysctl+0x252: movl $0x40,0x18(%rbx)      # 0x40 = the rxcd->len

(panic.txt; reproduced twice — initial run + clean rerun after reset.)

The store instruction is the replicated m->m_pkthdr.len = m->m_len = length (0x40 == the hostile len=64; m in %rbx == 0).

Exploitability

Fixed-address near-NULL write (address = offsetof(m_pkthdr) constants, value partially host-influenced via length). No controllable pointer target → panic-only on this arch (no SMEP/SMAP/KASLR irrelevant here). Within the malicious-host threat model (compromised ESXi backend, nested-hypervisor attack, or a buggy host offloading to ring 1 by mistake) this is a one-descriptor guest kill.

Fix validation

Full patched-kernel validation is not possible on this guest (no vmxnet3 device to attach the real driver). The fix logic was validated with the same replica: test 901 (fixrun.log) drops the completion when the selected ring is unpopulated — no crash, guest alive: vmxrep901(fixed rx): unpopulated ring selected - completion dropped, no NULL deref, guest alive

fix.diff adds the equivalent NULL guard after the mbuf fetch in vmxnet3_rxq_eof() (and notes the same guard belongs in the discard path).

Kernel refs

sys/dev/virtual/vmware/vmxnet3/if_vmx.c:2217-2220, 2223, 2257, 2265-2266, 2563-2581, 1047-1048, 2086-2089; if_vmxreg.h:143-171.

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.