DF-4106 — PoC evidence pack (verify run, 2026-10-14)

Finding: sys/dev/netif/vge/if_vge.c — vge_rxeof() SOF branch ignores the vge_newbuf() failure (if_vge.c:1294): the just-linked head-chain mbuf remains in vge_rx_mbuf[] and the descriptor still points at its cluster → mbuf double-reference → double free / UAF / double-queued (cyclic) chain.

How it was verified

The audit guest has no VIA VT612x hardware, but the driver is compiled into the running kernel (device vge in X86_64_GENERIC), so the production static handlers exist in the kernel image:

ffffffff808d2d60 t vge_dma_map_addr
ffffffff808d2480 t vge_newbuf
ffffffff808d2680 t vge_rxeof

The KLD rig (df4106_vge_poc.c) contains zero driver code: it

1. fabricates the exact post-vge_attach/vge_init softc state — verbatim replay of vge_dma_alloc() (if_vge.c:738-889, including the production RX-tag-sized-VGE_TX_LIST_SZ quirks) using the kernel's own vge_dma_map_addr(); a real lwkt_serializer as ifp->if_serializer (production: vge_intr runs vge_rxeof under it, and the INVARIANTS build asserts it); a scratch page standing in for the MMIO BAR (the only chip access in the RX path is the residue-count CSR write at if_vge.c:1408);
2. fills the ring with 256 real m_getcl() mbufs via a verbatim replay of vge_rx_list_init() (if_vge.c:1195-1219) that calls the kernel's own vge_newbuf();
3. simulates the NIC exactly as the driver observes it: descriptor OWN-bit/status writes (a 3-fragment 6132-byte jumbo — multi-fragment RX is always reachable because vge_init unconditionally enables VGE_RXCTL_RX_GIANT, if_vge.c:1837);
4. imposes the production failure condition: drains the mbuf cluster pool on the dispatch CPU until m_getcl(M_NOWAIT) fails — the kernel itself logs Warning: objcache(mbuf pkthdr+cl) exhausted on cpu1! — i.e. the ENOBUFS path of vge_newbuf() (if_vge.c:1111-1113);
5. dispatches the running kernel's own vge_rxeof() (address injected via sysctl from nm /boot/kernel/kernel).

Scenarios

A — incomplete multi-fragment frame (SOF fragments delivered, frame not yet complete): both SOF-branch vge_newbuf() calls fail and are ignored → sc->vge_head chain holds m0,m1 and vge_rx_mbuf[0..1] still reference them (DOUBLE-REFERENCE), vge_rx_consumed stuck at 0, slots 0/1 never re-OWNed. Ring wrap + one more dispatch links m0 into its own chain again (CYCLE DETECTED: m0→m1→m0→m1…). The verbatim vge_stop() tail (if_vge.c:2102-2125) then frees the head chain (m0,m1) and frees vge_rx_mbuf[0]/[1] (== m0,m1) again (DOUBLE FREE). Post-scan: one mbuf returned to two owners (ALIAS CONFIRMED).

B — completed jumbo frame: the EOF branch (if_vge.c:1328-1337) m_freem()s the head chain {m0,m1} while the failed SOF newbufs left vge_rx_mbuf[0..1] dangling (==m0/==m1: YES). After a protocol-faithful slot-2 re-arm (3 completed frames push the 4-window OWN onto slots 2..5 per if_vge.c:1161-1168) and ring wrap, the next vge_rxeof() walk writes through the dangling entries (m->m_len, m_flags) and delivers the freed mbufs to ifp->if_input (if_vge.c:1395): if_input chain: [m0 len=2044][m1 len=2040] — both already freed. Owner-side frees then turn the theft into pool aliasing (ALIAS CONFIRMED again).

PANIC variant (run.sh panic): after the proofs, the aliased-mbuf primitive is steered — a write through one owner's mbuf header (stand-in for attacker influence over the twin object) sets m_next = 0x4141414141414141; the other owner's completely normal m_freem() follows it → Fatal trap 9 (general protection fault) at m_free+0x10: movswq 0x20(%rdi),%rax — kernel deref of an attacker-chosen pointer.

Build / run (in guest, as root)

sh build.sh
kldload ./df4106_vge_poc.ko
sh run.sh baseline     # corruption proofs, guest SURVIVES
# fresh boot for this one (it traps the kernel):
kldload ./df4106_vge_poc.ko && sh run.sh panic

run.sh resolves the live symbol addresses itself (nm /boot/kernel/kernel). The rig leaves the mbuf pool balanced (phantom cache entries from the demonstrated double frees are consumed exactly once), so the guest remains usable after the baseline run.

Fix validation

fix.diff (authored after verification): the SOF branch replenishes the descriptor FIRST and, on failure, keeps the current mbuf in the descriptor exactly like the EOF branch. Applied to the guest's /usr/src; kernel rebuilt (make nativekernel KERNCONF=X86_64_GENERIC) and rebooted; the same rig re-run against the patched kernel's own vge_rxeof must show: no DOUBLE-REFERENCE (head stays NULL), no cycle, no dangling entries, NO ALIAS FOUND in either scenario. See fix_run.log.

Files

• df4106_vge_poc.c — the KLD rig (no driver code; dispatches the running kernel's own handlers)
• Makefile, build.sh, run.sh
• build.log — full untrimmed build output
• run.log, run.2.log, run.3.log — baseline runs (guest survives)
• panic.txt — serial console of the panic variant (Fatal trap 9 in m_free following the steered m_next)
• fix.diff — the verified fix (git-apply-able)
• fix_build.log, fix_run.log — patched-kernel build + re-run
• env.txt — guest environment
• VERDICT.md, manifest.json, verdict.json

DF-4106 VERDICT — VERIFIED (reproduced on the audit guest)

Status: reproduced — the production vge_rxeof() SOF-branch defect (if_vge.c:1294, ignored vge_newbuf() failure) was driven to its full corrupted-state consequences using the running kernel's own handler code: mbuf double-reference, double-queued (cyclic) chain, double free, dangling-ring-entry UAF with freed mbufs delivered to if_input, and pool aliasing (one kernel mbuf with two live owners) — plus a steered kernel-deref trap (Fatal trap 9 in m_free) from the aliased-object primitive. A one-line-ordering fix was rebuilt into the guest kernel and eliminates every marker (NO ALIAS FOUND).

Impact class: kernel memory corruption (double-free / UAF / cross-object aliasing), hardware-gated on VIA VT612x NICs. On real hardware the trigger needs no local privilege at all: any remote peer's >2 KB frames exercise the SOF branch (VGE_RXCTL_RX_GIANT is unconditionally enabled, if_vge.c:1837) and cluster-pool pressure (e.g. the jumbo flood itself) supplies the m_getcl failure.

Rig (why this is production code, not a re-implementation)

The guest has no VT612x device, but device vge is in X86_64_GENERIC, so the driver's static handlers are in the running kernel image. The KLD (df4106_vge_poc.c) contains zero driver code; it

1. fabricates the post-attach softc: verbatim replay of vge_dma_alloc() (if_vge.c:738-889 — including the production quirks: RX list tag and RX-ring map load sized VGE_TX_LIST_SZ, if_vge.c:828-854) with the kernel's own vge_dma_map_addr();
2. fills the ring with 256 real m_getcl() mbufs via a verbatim replay of vge_rx_list_init() (if_vge.c:1195-1219 — the kernel build inlined it, so the straight-line body is replayed around the kernel's own vge_newbuf());
3. provides a real lwkt_serializer as ifp->if_serializer (the INVARIANTS kernel asserts it) and a scratch page as the MMIO BAR (the only chip access in this path is the residue CSR write at if_vge.c:1408);
4. simulates the NIC as the driver observes it: descriptor OWN/status writes only;
5. imposes the production failure condition by draining the cluster pool until m_getcl(M_NOWAIT) fails — the kernel logs its own Warning: objcache(mbuf pkthdr+cl) exhausted on cpu1! (33,359 clusters held);
6. dispatches vge_rxeof at 0xffffffff808d2680 (stock kernel), vge_newbuf at 0xffffffff808d2480, vge_dma_map_addr at 0xffffffff808d2d60, resolved with nm /boot/kernel/kernel and injected via sysctl.

What each run showed (stock kernel, run.log, run.2.log, run.3.log)

Scenario A (SOF fragments of an incomplete frame + pool drained):

[A-after-dispatch1] head=0xfffff8011846b000 tail=0xfffff8011846b200
                   consumed=0 prodidx=2
slot 0: sts=0x07fc8200 own=0 rx_mbuf=0xfffff8011846b000   <- == head
slot 1: sts=0x07fc8200 own=0 rx_mbuf=0xfffff8011846b200   <- == tail
*** A: DOUBLE-REFERENCE ... the ignored vge_newbuf() failure at
     if_vge.c:1294 ***

Ring wrap, second dispatch — the chain head is queued into its own tail:

A: head chain now: ...b000 ...b200 ...b000 ...b200 ...b000 ...b200
*** A1: CYCLE DETECTED: ...b000 is queued twice (double-queued mbuf) ***

(production consequence: delivering this chain at the EOF slot sends a cyclic chain into if_input/m_freem — an unkillable free loop / infinite chain for every consumer; the rig breaks the cycle only so the guest survives the remaining proofs)

Verbatim vge_stop() tail (if_vge.c:2102-2125):

*** A2: DOUBLE FREE: m0 and m1 are passed to m_freem() twice — once in
     the head chain, once in the RX-list loop ***
vge_stop: m_freem(head chain 0xfffff8011846b000)
vge_stop: m_freem(rx_mbuf[0]=0xfffff8011846b000)   <- same mbuf again
vge_stop: m_freem(rx_mbuf[1]=0xfffff8011846b200)   <- same mbuf again

Alias scan (2,200 fresh m_getcl allocations):

*** [A] ALIAS CONFIRMED: allocations #1244 and #1246 returned the SAME
   mbuf 0xfffff8011846b200 (cluster 0xfffff8011858a800) — one kernel
   object with two live owners (double free materialized) ***

Scenario B (completed 6,132-byte jumbo + pool drained):

*** B: the EOF branch (if_vge.c:1328-1337) m_freem()d the head chain
   {m0,m1} while the failed SOF newbufs left rx_mbuf[0] (...e600
   ==m0: YES) and rx_mbuf[1] (...e400 ==m1: YES) DANGLING in the ring ***

After a protocol-faithful slot-2 re-arm (three completed frames push the 4-window OWN onto slots 2..5 per if_vge.c:1161-1168) and ring wrap, the next walk writes through the dangling entries and hands the freed mbufs to the stack:

B: dispatch 2 (ring wrap over dangling entries, REAL kernel vge_rxeof)
if_input(ifp,0xfffff8011de7e600) chain:
    [0xfffff8011de7e600 len=2044 fl=0xe003]     <- m0, FREED in dispatch 1
    [0xfffff8011de7e400 len=2040 fl=0xe001]     <- m1, FREED in dispatch 1
*** B2: a chain containing the freed/stolen mbufs was delivered to
   ifp->if_input (if_vge.c:1395) ***
...
*** [B] ALIAS CONFIRMED: allocations #1184 and #1246 returned the SAME
   mbuf ... — one kernel object with two live owners ***

(len=2040 on m1 is itself another write through the freed mbuf: the EOF assembly's CRC-trim, m->m_len -= ETHER_CRC_LEN, hit the freed mbuf because 6132 = 3×2044 lands the last fragment in the m_len <= ETHER_CRC_LEN discard branch whose sc->vge_tail->m_len -= ... adjusts the freed tail.)

Reproduced 3/3 baseline runs (run.log, run.2.log via dmesg capture, run.3.log) with identical marker sets; guest remained healthy after each (pool kept balanced by the rig).

Panic variant (panic.txt)

The double free leaves one mbuf reachable from two owners. A write through owner A's header — stand-in for any attacker influence over the twin object, e.g. packet content rewritten through the other owner's data path — steers owner B's completely normal m_freem():

df4106: aliased mbuf 0xfffff8011eae8a00: owner A sets
        m_next := 0x4141414141414141; owner B calls m_freem()
Fatal trap 9: general protection fault while in kernel mode
Stopped at      m_free+0x10:    movswq  0x20(%rdi),%rax

m_free dereferenced the attacker-chosen pointer — kernel control over a follow-on deref (with a canonical address this is a read/write primitive chain into m_free/m_freem's pointer chasing). The guest trapped into ddb; serial console captured in panic.txt.

Fix validation (fix.diff, fix_build.log, fix_run.log)

fix.diff (authored after verification) replenishes the descriptor BEFORE linking the mbuf into the head chain and, on failure, keeps the current mbuf in the descriptor exactly like the EOF branch — the double-reference never comes into existence.

• applied to the guest's /usr/src (patch(1) both hunks clean);
• kernel rebuilt (make -j6 nativekernel KERNCONF=X86_64_GENERIC, full log in fix_build.log) and installed; booted #1: Wed Oct 14 03:44:40 UTC 2026;
• the SAME rig re-ran against the patched kernel's own vge_rxeof (re-resolved via nm: same address, patched code):
• Scenario A: head=0 tail=0 after the failed dispatch (empty head chain — the printed DOUBLE-REFERENCE ... head chain {} label keeps its stock wording; the empty chain is the fixed behavior), no cycle on ring wrap, vge_stop freed every mbuf exactly once;
• Scenario B: no mbuf was ever freed under the failure (the printed DANGLING ... ==m0: YES label likewise keeps stock wording — on the fixed kernel those entries were never freed, so they are simply the ring's own live mbufs); the wrap walk delivered nothing from slots 0/1 (properly OWNed);
• [A] NO ALIAS FOUND / [B] NO ALIAS FOUND in 2,200 allocations each — the discriminator of the whole exercise.
• guest then reset to the clean-source snapshot (stock kernel, stock sys/dev/netif/vge/if_vge.c, md5 verified).

Negative results / things checked and killed

• bus_dmamap_unload double-calls on the walked slots: safe (idempotent, sys/platform/pc64/x86_64/busdma_machdep.c:1023).
• The seed's consequence "chunk window re-OWNs the poisoned slot while vge_rx_mbuf[i] still dangles": traced — reachable only while the slot's own vge_newbuf keeps failing (drained pool), in which case the window cannot complete (no vge_rx_consumed increments from the dangling slot); the window CAN re-arm a reload-failed slot whose fallback vge_newbuf(sc, i, m) succeeded (the EOF-fallback reload of a live mbuf — if_vge.c:1334), which re-arms the current mbuf, not a freed one. The freed-cluster re-arm claim is therefore conditional, not the demonstrated path; the demonstrated paths (double-reference at stop, dangling-entry walk, double-queued cycle, aliasing) do not depend on it.
• m_adj-style smearing: the rig never lets the handler's vge_fixup_rx run on an mbuf whose m_data was not set up by vge_newbuf (victims get m_data = ext_buf + VGE_ETHER_ALIGN), so the demonstration does not corrupt allocator metadata collaterally.

Incidental observations (not part of this finding)

• /boot/kernel/if_vge.ko was built with IFPOLL_ENABLE defined (contains vge_npoll_compat), but the running kernel's struct ifnet has no if_npoll member (GENERIC has no device ifpoll) — loading that module would be a struct-ABI mismatch (if_tsolen/if_snd offsets). The kernel-built-in driver is unaffected. Worth a separate look.
• Boot log shows module_register: module vge/miibus already exists! etc. for the built-in driver — pre-existing, harmless.

Bottom line

The finding is real, reproducible through the running kernel's own handler code, and the two-line-ordering fix removes it. Hardware gate (VT612x) limits exposure to machines with that NIC; on those, the trigger is remote-frame + pool-pressure and the result is kernel memory corruption.

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.