# DF-3570 — VERDICT

**Status: not_testable** (audit guest has virtio-net only; no Realtek
silicon). **Source-level proof: complete and mechanical** (`proof.log`).
The vulnerable code is confirmed compiled into the stock `if_re.ko` shipped
on the guest (`nm` evidence in `env.txt`), and the guest loads the module
without error — there is simply no 10ec:8168 device to trigger attach.

## Root cause (one dropped line)

`MP_ReadOtherFunPciEConfigSpace()` — sys/dev/netif/re/re.c:31163-31192 —
performs the CSIAR config-space read handshake and then:

    u_int32_t RetVal = 0xffffffff;      /* :31171 */
    ...
    do { DELAY(100); ReadDone = CSR_READ_4(sc, RE_CSIAR); Timeout++; }
    while (((ReadDone & 0x80000000) == 0) && (Timeout < WaitCount));
    DELAY(50);
    return RetVal;                      /* :31191 — never reads RE_CSIDR */

`RetVal` is never assigned the contents of `RE_CSIDR` (0x64), so **every
call returns the constant 0xffffffff**. The write twin
(`MP_WriteOtherFunPciEConfigSpace`, :31132-31161) does use RE_CSIDR
(:31148), which makes the omission unambiguous — a porting drop of the
upstream `RetVal = RTL_R32(PCI_CSIDR);` line.

## Impact chain 1 — NULL CMAC handle => attach-time kernel panic

1. re.c:4413-4417 — `HwSuppDashVer = 3` for MACFG_70/71/72
   (RTL8168FP / RTL8117 family).
2. re.c:4448-4449 — `sc->re_dash = re_check_dash(sc)` (OCP 0x128 bit0).
3. re.c:4456 — `CmacMemPhysAddress = MP_ReadOtherFunPciEConfigSpace(sc,0,0xf018)`
   == 0xffffffff (constant).
4. re.c:4457 — `if (!(CmacMemPhysAddress & BIT_0))` is FALSE for 0xffffffff,
   so the whole mapping block (:4458-4473) incl. `bus_space_map()` (:4468)
   is skipped and `re_mapped_cmac_handle` stays NULL (softc is bzeroed by
   if_re.c's attach). This holds for DASH and non-DASH SKUs alike — for
   non-DASH SKUs the `if (sc->re_dash)` gate (:4451) skips mapping anyway.
5. re.c:4484-4489 — for MACFG_70/71/72 the softc unconditionally does
   `sc->re_cmac_handle = sc->re_mapped_cmac_handle` (NULL) and
   `sc->re_cmac_tag = sc->re_mapped_cmac_tag` (0).
6. if_re.c:772 — attach calls `rtl_exit_oob(sc)` → re.c:3588-3596 — for
   MACFG_61/62/67/70/71/72 → `Dash2DisableTxRx(sc)`.
7. re.c:3445-3453 — `Dash2DisableTx()`: the `if (!sc->re_dash) return;`
   guard is commented out (:3447), and `HW_DASH_SUPPORT_TYPE_3(sc)` is true
   for MACFG_70-72, so it executes
   `RE_CMAC_WRITE_1(sc, RE_CMAC_IBCR2, RE_CMAC_READ_1(sc, RE_CMAC_IBCR2) & ~BIT_0)`.
8. On DragonFly the CMAC macros (re_dragonfly.h:43-54) are raw
   `bus_space_*` calls, and x86_64 `bus_space_read_1`
   (sys/cpu/x86_64/include/bus_dma.h:135-141) is
   `*(volatile u_int8_t *)(handle + offset)` for memory tags → read/write
   of virtual address 0xF9/0xF8/0xFB → **kernel page fault at attach**,
   before the interface exists. Deterministic for every MACFG_70/71/72
   device; boot with the card, or devd/kldload with it present.

## Impact chain 2 — PCIe config-space clobbering (all CSIAR RMW users)

Live read-modify-write consumers of the broken read all receive 0xffffffff:

- re.c:3891-3893 (re_hw_init): writes 0xffffffff to config 0xF108
  (PCIE uncorrectable-error mask) — masks all UE reporting for the NIC.
- re.c:5765, 5806, 5938, 5982, 6059, 6125, 6227, 6318, 6383, 6470, 6585,
  6598, 6792, 6952 (re_hw_start_unlock, per-MACFG branches for
  8168C/D/E/V): e.g. `Data32 = 0xffffffff & 0xC0FFFFFF | (0x3F<<24)`
  = 0xffffffff — the "preserve bits 23:0" intent of the RMW is defeated and
  the NIC's config dword is written all-ones (clock-gating / max-payload
  related setup).
- re.c:7414 (re_hw_start_unlock_8125): DASH descriptor-format select made
  from garbage.

Reliability/functional misconfiguration of the device; no kernel memory
corruption.

## Threat model / severity

- The panic is NOT triggerable by an unprivileged local user — it fires
  deterministically when the driver attaches to MACFG_70-72 silicon
  (device present at boot, devd autoload, or explicit kldload by root).
  Severity therefore **Low** ("requires specific hardware"), but certain:
  with an RTL8117/8168FP installed, the machine panics during re(4) attach.
- The config clobbering affects common 8168 chips but stays inside the
  device's own config space.
- No info leak, no privilege boundary crossed, no remote reach.

## Why not reproduced on the guest

`pciconf -l` on the audit QEMU guest shows only virtio devices
(NO_REALTEK_HW). The RTL8168FP MMIO/CSIAR registers cannot be driven, so
the path cannot execute. `kldload if_re` succeeds and is a no-op (no
matching PCI ID). Honest classification: **not_testable / hardware absent**,
not false_positive — the chain is source-proven link by link (proof.log)
and the vulnerable functions are present in the shipped module binary
(env.txt).

## Fix (fix.diff)

1. Restore the dropped data-register read:
   `RetVal = CSR_READ_4(sc, RE_CSIDR);` after the handshake in
   `MP_ReadOtherFunPciEConfigSpace`.
2. Defense in depth for the NULL-handle deref, so a DASH detection mistake
   can never fault the kernel: bail out of `Dash2DisableTx`/`Dash2DisableRx`
   when `sc->re_cmac_handle == 0`, and skip the CMAC path in
   `re_init_software_variable`'s MACFG_70-72 assignment if unmapped.

Fix validation: **not_testable** — validating the runtime effect requires
RTL8168FP hardware (panic present before patch, gone after). The patch is
two-line plus guards, compile-checkable by inspection against the write
twin at :31148; no kernel build was performed on the guest for this
Low-severity, hardware-gated finding (fix_status=not_testable).

## 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.