Kernel panic (double fault): pfi_kkif_update() self-recursion via if_rename during interface apply

Description

Kernel panic (double fault) triggered by pfi_kkif_update() recursing on itself
hundreds of times, reached via an if_rename ioctl during OPNsense's normal interface
reconfigure/apply path. Reproduced twice, from two unrelated triggers, with an identical
backtrace both times.

Environment

• OPNsense 26.1.11_6 (amd64)
• FreeBSD 14.3-RELEASE-p16, stable/26.1-n272152-9b6eef552f24 SMP
• Firewall with a relatively large interface count: ~19 VLAN sub-interfaces on a single
  physical NIC, plus WireGuard, OpenVPN, and a WAN failover interface
• Consumer desktop-class hardware (Intel Core i3-4360, Haswell) — flagging only to rule
  out "exotic hardware" as a factor; this looks like a pure software bug (see below)

Backtrace (identical in both occurrences)

[NN] pfi_kkif_update() at pfi_kkif_update+0x1fc/frame ...
[NN] pfi_kkif_update() at pfi_kkif_update+0x1fc/frame ...
... (several hundred more identical frames) ...
[NN] pfi_attach_ifnet_event() at pfi_attach_ifnet_event+0xaf/frame ...
[NN] if_rename() at if_rename+0x377/frame ...
[NN] ifhwioctl() at ifhwioctl+0xcdc/frame ...
[NN] ifioctl() at ifioctl+0x87e/frame ...
[NN] kern_ioctl() at kern_ioctl+0x255/frame ...
[NN] sys_ioctl() at sys_ioctl+0x101/frame ...
[NN] amd64_syscall() at amd64_syscall+0x117/frame ...
[NN] fast_syscall_common() at fast_syscall_common+0xf8/frame ...
[NN] --- syscall (54, FreeBSD ELF64, ioctl), rip = ..., rsp = ..., rbp = ... ---
[NN] KDB: enter: panic

Panic String: double fault in both crash dumps.

Steps to reproduce (occurrence 1 — package upgrade)

1. Run an OPNsense upgrade that includes a significant package/service rebuild touching
   networking-adjacent daemons (in our case: os-frr 1.51 → 1.53_3, frr10 10.5.3 →
   10.6.1, a libyang2 → libyang3 swap, alongside the base opnsense package bump
   26.1.5 → 26.1.11_6). Package installation and run_migrations.php complete without
   error.
2. Reboot.
3. System panics with the above backtrace almost immediately after boot, then
   auto-reboots into the same panic — a crash loop (we observed 424 consecutive crash
   dumps at ~3 minute intervals before manually booting a different, unaffected ZFS boot
   environment to break the loop).

Steps to reproduce (occurrence 2 — completely unrelated: adding a WireGuard peer)

On the same firewall, several hours after the above was resolved (by booting a
different boot environment with the same package versions, which came up clean):

1. In WireGuard settings, clone an existing peer entry to create one new peer (just a
   name/pubkey/tunneladdress — no other settings changed, no new WireGuard
   instance/interface created, no VLAN or interface reassignment).
2. Click Apply in the GUI. WireGuard itself comes up fine immediately.
3. Within minutes, the system panics with the identical backtrace as occurrence 1, and
   crash-loops the same way (6 further crash dumps observed before intervening).

Note that occurrence 2 involved no FRR, no package upgrade, and no VLAN/interface
topology change at all — the only common factor between the two occurrences is that
OPNsense's apply/reconfigure logic performed an interface rename (if_rename) on some
interface, which is what appears in both backtraces.

Workaround found

For WireGuard peer additions specifically: adding the peer directly to the running kernel
interface with the native tool instead of the GUI's apply path does not trigger the
panic:

wg set <if> peer <pubkey> allowed-ips <ip>/32

(then persist the same peer in config.xml separately for boot-time persistence — note:
we have not verified whether a reboot with this peer present in config.xml also
triggers the panic via boot-time interface setup, since we have avoided rebooting the
box since the second occurrence).

We have no verified-safe workaround for the original upgrade-triggered occurrence, other
than avoiding the specific package set / applying the upgrade to a disposable boot
environment first.

Expected behavior

Interface rename/reconfigure during OPNsense's normal apply flow should not cause
pfi_kkif_update() to recurse without bound.

Additional notes

• /opnsense/ifgroups was empty in the affected configuration both times — this isn't
  triggered by an admin-defined interface group with a cycle in its membership.
• Given the somewhat unusual interface count (~19 VLANs on one NIC) we suspect this may
  be specific to configurations with many interfaces/kifs, but have not isolated the
  exact threshold or condition.
• Happy to provide full FreeBSD textdumps (ddb.txt/msgbuf.txt/panic.txt) from both
  occurrences if useful — omitted here for length, and the config itself has been
  sanitized of internal hostnames/IPs for this report.

Start by examining pfi_kkif_update() and pfi_attach_ifnet_event() in the kernel networking code, then reproduce an OPNsense interface apply that performs if_rename. Compare the resulting ddb.txt, msgbuf.txt, and panic.txt dumps; done means interface rename/reconfigure no longer causes unbounded pfi_kkif_update() recursion or a double fault.