Entered as bug kernel/4604. A colleague suggested I post here, as well.
Anyway, details are in the bug, but the gist is that bridging Intel
cards and
using scrub rules in pf results in a kernel panic. It's very easy to
reproduce.
I'm currently using a VIA single board computer (Commell's LE-564), but
I have reproduced this (since 3.6) on an HP Kayak PC, and a Dell Precision.
Ruleset that causes panic (commenting 2 scrub rules eliminates panic - I
don't know if scrub, in general, causes the panic, or if it's one of the
scrub
options that I am passing):
#### Interface aliases
# Interface aliases for ease of administration.
ext_if = "fxp0" # Untrusted (to LAN)
int_if = "fxp1" # Trusted (to switch)
#### Traffic Normalization
# Prevent fragmentation attacks
scrub in on $ext_if all fragment reassemble no-df
scrub out on $ext_if all fragment reassemble random-id no-df
### Pass traffic on the loopback interface in either direction
pass quick on lo0 all
#### Internal Bridge interface rules
# Filter on external interface - in bridge mode,
# we only filter on one interface.
pass in quick on $int_if all
pass out quick on $int_if all
### Don't filter anything and see if we still panic
pass in quick on $ext_if all
pass out quick on $ext_if all
Crash:
panic: pool_get(mclpl): free list modified: magic=c6830e9e; page
0xd38cc000; it
em addr 0xd38cc800
Stopped at Debugger+0x4: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb> trace
Debugger(0,0,0,d38cc800,d05d2760) at Debugger+0x4
panic(d04f6bc0,d04f8b89,c6830e9e,d38cc000,d38cc800) at panic+0x63
pool_get(d05d2760,0,da369b00,1,d06f1dfc) at pool_get+0x315
fxp_start(d0958040,d06f1dfc,e,d09e3c00) at fxp_start+0x2ac
bridge_ifenqueue(d09ec000,d0958040,da370300,d0958040,da370300) at
bridge_ifenqu
eue+0xa2
bridgeintr_frame(d09ec000,da370300,0,d06f0000) at bridgeintr_frame+0x270
bridgeintr(58,10,10,10,d06f0000) at bridgeintr+0x6a
Bad frame pointer: 0xd06f1e44
