DF-3277 — bridge_delete_span() unlinks span bif from the WRONG list → member/span list cross-linkage → KASSERT panic / UAF / double-free

What

bridge_delete_span() executes

TAILQ_REMOVE(&sc->sc_iflists[mycpuid], bif, bif_next);   /* if_bridge.c:1155 */

but span bifs are linked on sc->sc_spanlist (TAILQ_INSERT_HEAD(&sc->sc_spanlist, bif, bif_next), if_bridge.c:1832). When the removed span bif is the last element of the span list (tqe_next == NULL), TAILQ_REMOVE executes head->tqh_last = elm->tqe_prev against the per-cpu member list head, so sc_iflists[0].tqh_last is clobbered to point at &sc->sc_spanlist.tqh_first.

The next TAILQ_INSERT_TAIL on the member list — the LINK2 bonding round-robin in bridge_select_unicast() (if_bridge.c:2135-2143) — then executes *(sc_iflists[0].tqh_last) = alt_bif, i.e. it writes a member bif pointer into sc_spanlist.tqh_first, cross-linking the two lists. After that, span-list operations treat live member bifs as span ports: bridge_delete_span()'s KASSERT fires (INVARIANTS), or on stock kernels the member bif is unlinked from the member list and freed while still a member → use-after-free / double-free at teardown (bridge_del_bif_handler KKASSERTs bif != NULL, or kfree hits freed memory).

Reproduce (guest, as root)

cd /root/poc/df-3277
cc -O -o bond_corrupt bond_corrupt.c
./bond_corrupt

The PoC (pinned to cpu0, all frames ETHERTYPE_ARP so the netisr hash keeps processing on cpu0):

1. bridge0 with tap0/tap1 sharing one MAC (bonding set, STP on, fwddelay 1s), tap2 normal member; bridge link2 + up; tap fds opened before bridge-up so STP ports reach FORWARDING.
2. spanport tap3 + -spanport tap3 → corrupts sc_iflists[0].tqh_last.
3. Learn 02:00:00:00:00:55 on tap0, then unicast to it from tap2 → bonding round-robin TAILQ_INSERT_TAIL through the stale tqh_last → sc_spanlist.tqh_first = <tap1's member bif>.
4. Probe: BRDGDELS("tap1") — finds the MEMBER on the span list.

Expected

[+] list order before bonding traffic:    [member order: tap2 tap1 tap0]
[+] after bcast learn frame:    [rtable: 02:00:00:00:00:55->tap0]
[+] list order after bonding traffic:    [member order: tap2 tap0 tap1]
panic: bridge_delete_span: not a span interface
bridge_delete_span() at bridge_delete_span+0x87
bridge_ioctl_delspan() at bridge_ioctl_delspan+0x58

The member-order flip (tap1 moved to tail) is the INSERT_TAIL firing; the probe panic proves tap1 — a member with if_bridge == sc — was linked on sc_spanlist.

DF-3277 — VERDICT

REPRODUCED — kernel panic (KASSERT), with a documented escalation path to use-after-free / double-free on non-INVARIANTS builds.

Environment

Same guest as DF-3276 (DragonFly 6.5-DEVELOPMENT, X86_64_GENERIC, 6 CPUs; file byte-identical to DragonFlyBSD master).

Root cause (code)

• bridge_delete_span() if_bridge.c:1155: TAILQ_REMOVE(&sc->sc_iflists[mycpuid], bif, bif_next); — the bif is on sc->sc_spanlist (inserted at if_bridge.c:1832). Removing the last span element runs head->tqh_last = elm->tqe_prev with the wrong head: sc_iflists[0].tqh_last := &sc->sc_spanlist.tqh_first.
• bridge_select_unicast() if_bridge.c:2135-2143: with LINK2 and a bonding set (equal-MAC members, equal priority, both forwarding), every bif_bond_weight packets it does TAILQ_REMOVE(...); TAILQ_INSERT_TAIL(&sc->sc_iflists[mycpuid], alt_bif, bif_next); — the INSERT_TAIL writes sc_spanlist.tqh_first = alt_bif through the stale pointer.

Reproduction narrative (3 panics; full chain captured on the 3rd)

Iterations (all on the single-tenant QEMU guest):

1. First runs stalled: STP ports never reached FORWARDING with no peers — root-caused to bstp_enable_port() parking enabled ports in BLOCKING without a state selection; fixed in the PoC by opening the tap fds (media active) before bridge-up so bstp_initialization()'s final bstp_port_state_selection() drives them LISTENING→LEARNING→FORWARDING.
2. Learn/lookup frames initially ETHERTYPE_IP with zero payload were freed by ip_lengthcheck (sys/netinet/ip_demux.c:163, ip_hl=0) before ever reaching bridge_input. Switched to ETHERTYPE_ARP — NETISR_ARP has no hashfn so hash==0 and all processing happens on cpu0, matching the corrupted sc_iflists[0].
3. Full chain run (serial-console capture, run.log):

    t= 2 tap0: state=3 flags=0x17 | tap1: state=3 flags=0x37   # FORWARDING
[+] spanport tap3 added+deleted (list head corrupted)
[+] list order before bonding traffic:  [member order: tap2 tap1 tap0]
[+] after bcast learn frame:  [rtable: 02:00:00:00:00:55->tap0]  # learning works
[+] list order after bonding traffic:   [member order: tap2 tap0 tap1]  # INSERT_TAIL fired
[+] rtable after:  [02:...:66->tap2 02:...:55->tap0]
panic: bridge_delete_span: not a span interface
bridge_delete_span() at bridge_delete_span+0x87
bridge_ioctl_delspan() at bridge_ioctl_delspan+0x58
bridge_control_dispatch() at bridge_control_dispatch+0x64
netmsg_service_loop() at netmsg_service_loop+0xe9

The delspan("tap1") probe found tap1 — a member whose if_bridge == sc — on the span list; bridge_delete_span's KASSERT (if_bridge.c:1152) fired. Three independent runs panicked with the identical signature.

Impact / escalation

• On INVARIANTS kernels (like this guest): deterministic panic.
• On stock kernels the same chain silently unlinks the member bif from the per-cpu member list and kfrees it while the interface is still a bridge member (if_bridge still points at the softc; the other cpus' member lists still hold their bifs). Subsequent teardown hits KKASSERT(bif != NULL && bif->bif_onlist) in bridge_del_bif_handler (KKASSERT is compiled unconditionally) or kfrees memory still referenced by the span list — a use-after-free/double-free of M_DEVBUF objects. With attacker-shaped heap grooming (the freed bif is 40-ish bytes in the devbuf slab) this is a memory-corruption primitive; both the corruption writer (bonding round-robin) and the freeing path are driven by packet traffic once root has configured the topology.
• Configuration requires root (BRDGADDS/BRDGDELS/BRDGSIFFLGS are BC_F_SUSER-gated), hence Medium severity rather than High.

Fix validation

fix.diff (one-line: unlink from &sc->sc_spanlist) applied to the guest's /usr/src alongside the DF-3276 fix; kernel rebuilt and rebooted; the identical PoC then ran to completion: bonding round-robin still reorders the member list, but the delspan("tap1") probe correctly returns ENOENT and ifconfig bridge0 destroy completes cleanly (run_fixed.log).

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.