DF-4233 — txp_init() ignores txp_rxring_fill() failure; RX enabled over a stale buffer ring → firmware DMA into freed clusters + NULL deref

File: sys/dev/netif/txp/if_txp.c (pass 2) Severity: High (memcorrupt bucket) — hardware-gated; precondition is a transient MCLGET(M_NOWAIT) failure (kernel memory pressure) during ifconfig txp0 up, then any inbound frame.

Build / run — same guest probe as DF-4231 (t4233.c).

The bug

txp_init() (if_txp.c:1097-1144):

1. txp_stop() at :1110 → txp_rxring_empty() (:1522 → :1073-1094) frees all 256 receive clusters and NULLs sd->sd_mbuf, but the DMA-shared rb_paddrlo ring entries keep pointing at the freed clusters, and hv_rx_buf_write_idx keeps its stale value ("buffers available").
2. txp_rxring_fill(sc) at :1127 — return value ignored. On the first MGETHDR/MCLGET(M_NOWAIT) failure it returns ENOBUFS (:1051, :1056) after refilling only a prefix; hv_rx_buf_write_idx is updated only on success (:1066-1067), so the firmware still believes the old (stale) buffer count.
3. TXP_CMD_TX_ENABLE/TXP_CMD_RX_ENABLE are issued anyway (:1129-1130) and the interface is marked IFF_RUNNING.

When a frame then arrives for a stale ring entry: - the firmware DMAs the (attacker-supplied) frame into the freed mbuf cluster listed in rb_paddrlo — use-after-free write with attacker content into the mbuf cluster zone; - on completion, txp_rx_reclaim() does m = sd->sd_mbuf (NULL for the unfilled prefix) then m->m_pkthdr.len = ... at :676 → NULL write / panic.

Fix

fix.diff: propagate the fill failure — bail out of txp_init() (leave the interface down) instead of enabling RX over a half-filled, stale ring.

DF-4233 VERDICT — txp_init() ignores txp_rxring_fill() failure

Verdict: source-certain ignore + stale-ring mechanics (High, memcorrupt); the firmware-side half (whether the 3XP honors the stale hv_rx_buf_write_idx) is likely-but-not-certain, so overall confidence "likely". Runtime inconclusive: no 3c990 on the audit guest (run.log).

Trace

txp_init()  if_txp.c:1097
  :1107  if (ifp->if_flags & IFF_RUNNING) return;    // no double init
  :1110  txp_stop(sc);
           └─ txp_rxring_empty(sc)  if_txp.c:1522 → :1081-1090
                for each of 256 slots: m_freem(sd->sd_mbuf); sd->sd_mbuf = NULL;
                // rb_paddrlo NOT cleared; hv_rx_buf_write_idx NOT reset
  :1112  MAX_PKT_SIZE cmd
  :1122  STATION_ADDRESS cmd
  :1125  txp_set_filter()
  :1127  txp_rxring_fill(sc);          // <-- return value IGNORED
           └─ :1047-1064 for (i = 0; i < RXBUF_ENTRIES; i++) {
                  MGETHDR/MCLGET(M_NOWAIT); on failure return(ENOBUFS); }
              :1066-1067 hv_rx_buf_write_idx = (RXBUF_ENTRIES-1)*16;  // success only
  :1129  TXP_CMD_TX_ENABLE
  :1130  TXP_CMD_RX_ENABLE             // <-- RX starts over a half-filled ring
  :1139  ifp->if_flags |= IFF_RUNNING;

State after a failed re-init: prefix of the buffer ring holds fresh clusters; the rest holds rb_paddrlo of freed clusters and sd->sd_mbuf == NULL; the firmware's view of available buffers (hv_rx_buf_write_idx, a hostvar word — if_txpreg.h:546) still says "up to the old producer".

Inbound frame on a stale slot: 1. firmware DMAs frame content into the freed cluster (heap UAF write, attacker-controlled content, mbuf cluster zone); 2. firmware posts the rx descriptor (round-tripping the slot's rb_sd pointer, see DF-4232 analysis); 3. txp_rx_reclaim() if_txp.c:671-676: sd = rxd->rx_sd; m = sd->sd_mbuf; → m == NULL → m->m_pkthdr.len = m->m_len = rxd->rx_len; writes through NULL → immediate kernel panic.

So even in the least favorable firmware interpretation, the NULL deref at :676 fires the moment a completion arrives for an unfilled slot; in the natural interpretation (firmware trusts hostvar, which is the whole design of the hostvar block) the DMA-into-freed-cluster happens first.

Precondition realism

MCLGET(M_NOWAIT) failure = transient cluster exhaustion. A remote peer sustaining an inbound flood while a local (or scripted) ifconfig txp0 up runs is the realistic recipe; DFly clusters come from a limited zone, and memory pressure is externally seedable. First-up after attach can also fail mid-fill under pressure (same consequence, stale = zero paddrs → firmware DMA to physical 0 — see notes in the finding).

Why inconclusive at runtime

Same as DF-4231/4232: no Typhoon device on the guest (run.log: NO_3COM_PCI_DEVICE, driver present in kernel, source md5 identical). The MGET failure precondition could be staged in the guest, but with no device to consume the ring there is nothing to observe.

Fix

fix.diff: if (txp_rxring_fill(sc) != 0) { /* leave interface down */ ... return; } mirroring how every other DFly NIC driver aborts init when its rx ring cannot be filled (cf. re(4) re_init → re_rx_list_init error paths).

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.