On Wed, May 11, 2016 at 10:20:29PM -0400, michel.bell...@malaiwah.com wrote: > >Synopsis: attempt to execute 0x0, arping to bridge > >Category: system > >Environment: > System : OpenBSD 5.9 > Details : OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST > 2016 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > panic: attempt to execute user address 0x0 in supervisor mode > Stopped at Debugger+0x9: leave > TID PID UID PRFLAGS PFLAGS CPU COMMAND > *20236 20236 32767 0x13 0 0 arping > Debugger() at Debugger+0x9 > panic() at panic+0xfe > trap() at trap+0x7dd > --- trap (number 6) --- > (null)() at 0 > spec_write() at spec_write+0xbe > VOP_WRITE() at VOP_WRITE+0x3f > vn_write() at vn_write+0x98 > dofilewritev() at dofilewritev+0x205 > > Not sure if relevant in this bug report, but my Ferrari is a PC Engines APU2. > > >How-To-Repeat: > # create a bridge interface > bridge28: flags=41<UP,RUNNING> > groups: bridge > priority 57344 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp > designated: id 00:00:00:00:00:00 priority 0 > vlan28 flags=7<LEARNING,DISCOVER,BLOCKNONIP> > port 8 ifpriority 0 ifcost 0 > vlan128 flags=7<LEARNING,DISCOVER,BLOCKNONIP> > port 7 ifpriority 0 ifcost 0 > Addresses (max cache: 100, timeout: 240): > ac:f1:df:65:11:15 vlan28 0 flags=1<STATIC> > # note my two underlying interfaces are down > vlan28: flags=8942<BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > lladdr 00:0d:b9:41:5d:2d > priority: 0 > vlan: 28 parent interface: trunk0 > groups: vlan > status: active > vlan128: flags=8942<BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > lladdr 00:0d:b9:41:5d:2d > priority: 0 > vlan: 128 parent interface: trunk0 > groups: vlan > status: active > # arping -0 -B -i bridge28 -c 2 -P -s "00:11:22:33:44:55" -q > ## also had the same results trying it with dnet arp op rep sha > "00:11:22:33:44:55" | dnet eth type arp dst ff:ff:ff:ff:ff:ff | dnet send > bridge28 > # boum. > >Fix: > Fix is unknown
This sounds like the problem that was fixed in if_bridge.c 1.278 revision 1.278 date: 2016/04/12 06:20:30; author: mpi; state: Exp; lines: +12 -2; commitid: Itzt9gWTLLzkrbM4; Set bridge(4)'s if_output to a dummy function returning EAFNOSUPPORT as it should not be used to output packets but we have to respect the ifp driver API to some extend. Prevent a panic found the hardway by espie@. ok claudio@, mikeb@, jsg@, krw@ Index: if_bridge.c =================================================================== RCS file: /cvs/src/sys/net/if_bridge.c,v retrieving revision 1.275 diff -u -p -r1.275 if_bridge.c --- if_bridge.c 5 Dec 2015 10:07:55 -0000 1.275 +++ if_bridge.c 12 May 2016 07:06:20 -0000 @@ -127,6 +127,8 @@ struct mbuf *bridge_ip(struct bridge_sof struct ether_header *, struct mbuf *m); int bridge_ifenqueue(struct bridge_softc *, struct ifnet *, struct mbuf *); void bridge_ifinput(struct ifnet *, struct mbuf *); +int bridge_dummy_output(struct ifnet *, struct mbuf *, struct sockaddr *, + struct rtentry *); void bridge_fragment(struct bridge_softc *, struct ifnet *, struct ether_header *, struct mbuf *); #ifdef IPSEC @@ -187,7 +189,7 @@ bridge_clone_create(struct if_clone *ifc ifp->if_softc = sc; ifp->if_mtu = ETHERMTU; ifp->if_ioctl = bridge_ioctl; - ifp->if_output = NULL; + ifp->if_output = bridge_dummy_output; ifp->if_start = NULL; ifp->if_type = IFT_BRIDGE; ifp->if_hdrlen = ETHER_HDR_LEN; @@ -203,6 +205,14 @@ bridge_clone_create(struct if_clone *ifc if_ih_insert(ifp, ether_input, NULL); return (0); +} + +int +bridge_dummy_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, + struct rtentry *rt) +{ + m_freem(m); + return (EAFNOSUPPORT); } int