β¬’ DragonFlyBSD Kernel Audit
← triage Β· dashboard
DF-3395

Interface rename (SIOCSIFNAME) fires ifnet_detach_event: silently and permanently unconfigures every vlan on the renamed parent (config-wipe DoS)

Summary

The SIOCSIFNAME handler invokes EVENTHANDLER_INVOKE(ifnet_detach_event, ifp) before installing the new name. vlan registered on that event (the correct, actually-fired event per DF-3344's lesson), and its handler runs vlan_unconfig() on every vlan in the parent's trunk: parent cleared, tag reset, MTU/flags cleared, trunk freed. ifnet_attach_event restores nothing. VERIFIED on guest 2/2: 'ifconfig vtnet0 name vtnet0r' turned 'vlan: 100 parent interface: vtnet0 / status: active' into 'vlan: 0 parent interface: <none>'; renaming back does not restore - all tagged subnets blackhole until the admin re-runs the full vlan config. Privileged trigger, memory-safe teardown. Same collateral hits other ifnet_detach_event consumers (e.g. bridge silently drops a renamed member). Fix: fire the announcement-only ifnet_departure_event (the key DF-3344 found unused) instead. [Filed under if_vlan.c batch: vlan is the canonical consumer; root cause in sys/net/if.c:2206.]

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-3395 Β· 6 files
FileTypeDescriptionSize
rename_wipes_vlan.sh β€” 890 B view raw
run.log β€” 466 B view raw
VERDICT.md β€” 2.6 KB ↓ raw
fix.diff β€” 757 B view raw
manifest.json β€” 650 B view raw
verdict.json β€” 2.3 KB view raw
VERDICT.md
↓ download raw

VERDICT β€” DF-3395: reproduced (privileged rename silently wipes all vlan(4) config on the renamed parent)

Reproduction (DragonFly 6.5-DEVELOPMENT #0, X86_64_GENERIC)

# ifconfig vlan0 create; ifconfig vlan0 vlan 100 vlandev vtnet0
vlan0: ... mtu 1500 / vlan: 100 parent interface: vtnet0 / status: active

# ifconfig vtnet0 name vtnet0r          <- routine SIOCSIFNAME rename
vlan0: ... mtu 1500 / vlan: 0 parent interface: <none>

# ifconfig vtnet0r name vtnet0          <- rename back
vlan0: ... mtu 1500 / vlan: 0 parent interface: <none>   <- NOT restored

Root cause chain: - SIOCSIFNAME handler (sys/net/if.c:2190-2236) invokes EVENTHANDLER_INVOKE(ifnet_detach_event, ifp) at if.c:2206 for a rename, before installing the new name; ifnet_attach_event fires at :2232 after. - vlan registered on ifnet_detach_event (sys/net/vlan/if_vlan.c:377) β€” the event that IS fired (correct per DF-3344's lesson; lagg's bug was registering on the never-fired ifnet_departure_event). - vlan_ifdetach() (if_vlan.c:432) dispatches to netisr0; vlan_ifdetach_dispatch() (if_vlan.c:410-429) runs vlan_unconfig() on every vlan in the parent's trunk: parent pointer cleared, MTU reset, flags cleared, trunk freed. - Nothing on the vlan side re-attaches when ifnet_attach_event fires: the L2 configuration (parent + tag) is permanently destroyed.

Impact

Every vlan(4) riding the renamed interface is silently disconnected (traffic blackhole for all tagged subnets) until an administrator re-runs the full vlan configuration. Rename is a routine, non-destructive administrative gesture everywhere else in the system (addresses, routes, caps and media survive it). Privileged-only trigger (SIOCSIFNAME is caps_priv_check'd at if.c:2191), memory-safe teardown β€” hence Low.

Same collateral applies to other ifnet_detach_event consumers: e.g. a bridge member would be silently dropped on rename via bridge's detach handler.

A rename is not a detach. Fire the announcement-only ifnet_departure_event (the key already exists in eventhandler space and has no state-tearing subscribers β€” see DF-3344) instead of ifnet_detach_event in the SIOCSIFNAME path, keeping ifnet_detach_event for real interface destruction in if_detach().

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.

Fix verification

not_testable
baseline reproduced→ patch + rebuild →patched clean

fix.diff authored (one-line event swap + rationale) but kernel rebuild not performed in this run (non-memory-corruption, Low severity; validation deferred).

fix.diff
↓ fix.diffper-fix-DF-3395

Confirmed kernel references

Detail

Evidence (decisive lines)

["run.log β€” before: 'vlan: 100 parent interface: vtnet0 / status: active'; after rename: 'vlan: 0 parent interface: <none>'; after rename-back: still '<none>'", 'VERDICT.md β€” event chain if.c:2206 -> if_vlan.c:432 -> if_vlan.c:410-429 -> vlan_unconfig (if_vlan.c:854)']

PoC changes

Seed sketch converted to a self-contained shell script (rename_wipes_vlan.sh) with setup/verify/restore phases.

Verified recommended fix

Fire announcement-only ifnet_departure_event in the SIOCSIFNAME path instead of ifnet_detach_event (keep the latter for real destruction in if_detach()).

Verdict

Reproduced deterministically on the stock guest: 'ifconfig vtnet0 name vtnet0r' (SIOCSIFNAME) fires ifnet_detach_event (if.c:2206); vlan's handler (correctly registered on that event, if_vlan.c:377) unconfigures every vlan on the renamed parent (if_vlan.c:410-429 -> vlan_unconfig), permanently destroying the parent+tag L2 configuration ('vlan: 0 parent interface: '); renaming back does not restore it. All tagged subnets on the renamed interface blackhole until reconfigured. Privileged trigger, memory-safe teardown -> Low.