[Bug 227450] [patch] Should not all packets processed by gif_output be deleted, when an running instance of if_gif(4) is member of an instance of if_bridge(4)?

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 25 Jul 2025 04:58:55 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227450

--- Comment #15 from Koichiro Iwao <meta@FreeBSD.org> ---
Just for the record, here's the minimal setup to reproduce. 

rc.conf is not modified from the default setup of
FreeBSD-15.0-CURRENT-amd64-BASIC-CLOUDINIT-20250724-01c587521dd8-279004-ufs.qcow2.xz. 

hostname="freebsd"
firstboot_freebsd_update_enable=YES
growfs_enable=YES
sshd_enable=YES
nuageinit_enable=YES
dumpdev="AUTO"
ifconfig_DEFAULT="SYNCDHCP accept_rtadv"
# RSA host keys are obsolete and also very slow to generate
sshd_rsa_enable="NO"

Set up minimal Ethernet over IPv6. 

ifconfig bridge0 create
ifconfig epair0 create 
ifconfig gif0 create mtu 1500
ifconfig gif0 inet6 tunnel 2001:db8::1 3fff::1
ifconfig bridge0 addm gif0 addm epair0a
1753415597

(Wait around 5 minutes, kernel will panic)

panic: gif_output: unexpectedly called with bridge attached
cpuid = 2
time = 1753415820
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008c2ac950
vpanic() at vpanic+0x136/frame 0xfffffe008c2aca80
panic() at panic+0x43/frame 0xfffffe008c2acae0
gif_output() at gif_output+0x5b/frame 0xfffffe008c2acaf0
ip6_output() at ip6_output+0x1ca5/frame 0xfffffe008c2accb0
mld_dispatch_packet() at mld_dispatch_packet+0x325/frame 0xfffffe008c2acd30
mld_fasttimo() at mld_fasttimo+0x520/frame 0xfffffe008c2ace10
softclock_call_cc() at softclock_call_cc+0x19b/frame 0xfffffe008c2acec0
softclock_thread() at softclock_thread+0xc6/frame 0xfffffe008c2acef0
fork_exit() at fork_exit+0x82/frame 0xfffffe008c2acf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe008c2acf30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 2 tid 100039 ]
Stopped at      kdb_enter+0x33: movq    $0,0x1235072(%rip)

If an IPv6 (link-local) address is assigned to epair0a, it cannot be added to a
bridge member, and IPv6 addresses cannot be assigned if the interface is a
bridge member (invalid argument).

However, even if the interface is a bridge member, a link-local address may
still be assigned to it. The default rc.conf setup of the VM-IMAGE is the case.
Kernel will panic when it tries to send traffic from the IPv6 address, as zlei
mentioned. 

zlei's patch works fine for me. Shall we move forward?

-- 
You are receiving this mail because:
You are the assignee for the bug.