DF-3570 — MP_ReadOtherFunPciEConfigSpace never reads RE_CSIDR (constant 0xffffffff return) => NULL CMAC bus_space handle dereference (kernel panic) at re(4) attach on RTL8168FP/RTL8117, plus silent PCIe-config clobbering on every chip using the CSIAR read-modify-write paths.

Build / Run

Nothing to compile from userland. The fault is deterministic at device attach. On a machine with an RTL8168FP / RTL8117 (MACFG_70/71/72):

# kldload if_re          # or boot with the device present

Expected (unpatched): kernel page fault in Dash2DisableTx during rtl_exit_oob, before any interface registers. The serial console shows a panic with fault address 0xf9/0xf8/0xfb.

What IS verified in this pack (no such hardware on the audit guest)

./proof.sh     # mechanical re-derivation of every chain link from sys/

Guest (audit target) facts

dfbsd-qemu/vm.sh run_root 'pciconf -l'   # -> virtio only, NO_REALTEK_HW
nm /boot/kernel/if_re.ko                  # -> Dash2DisableTx,
                                          #    MP_ReadOtherFunPciEConfigSpace,
                                          #    rtl_* back-end all present
                                          #    in the shipped module

So the vulnerable code is compiled into the stock kernel module; the audit guest simply has no Realtek NIC to drive it. Status: not_testable (hardware absent), source-proven (see VERDICT.md).

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.