Created attachment 39602 [details]
Log of kernel Oops and panic with stp-enabled-bridge and ebtables

commands to reproduce (as root):

NIF=eth0   # any interface will do
PROT=arp   # tested with arp and ipv4
TARG=DROP  # tested with DROP and ACCEPT
brctl addbr testbr
brctl addif testbr $NIF
brctl stp testbr on
ip link set up dev testbr
ip link set up dev $NIF
ebtables -A OUTPUT -p $PROT -o $NIF -j $TARG

The gist of it:

Given a bridge and physical interface with link state up, the interface is assigned to the bridge, and the bridge has STP turned on. If, under this combination of circumstances, an ebtables rule is created in the OUTPUT table that specifies the physical interface, a kernel Oops is triggered (the kernel output is attached):

""" (short excerpt)
[ 1105.953771] BUG: unable to handle kernel paging request at ffff8801379bda0b
[ 1105.963752] IP: [<ffffffffa0225aa6>] ebt_do_table+0x5d6/0x6d0 [ebtables]
[ 1105.963752] PGD 1a2b063 PUD 1a067 PMD 0 
[ 1105.963752] Oops: 0000 [#1] SMP 
"""

It is immediately followed by a kernel panic (also in the attached file):

""" (short excerpt)
[ 1106.101435] Kernel panic - not syncing: Fatal exception in interrupt
[ 1106.101435] Pid: 2060, comm: kvm Tainted: G      D     2.6.35-23-server #41-Ubuntu
"""

It appears to be irrelevant what protocol is specified with the -p option, although when _no_ protocol is specified, the Oops and panic do not occur. I tested with -p arp and -p ipv4. It also appears to be irrelevant what target is specified with the -j option. I tested with -j DROP and -j ACCEPT.

My test environment was ubuntu maverick 64-bit using mainline (unpatched) kernels.

The tools versions were as follows:
* bridge-utils 1.4-5ubuntu2
* iproute 20100519-2
* ebtables 2.0.9.2-2

I tested the following kernels with identical results (Oops and panic):
* 2.6.34-020634rc1-generic
* 2.6.34-02063401-generic
* 2.6.34-02063407-generic
* 2.6.35-02063507-generic
* 2.6.35-02063508-generic
* 2.6.35-02063509-generic
* 2.6.36-020636rc6-generic
* 2.6.36-020636rc7-generic
* 2.6.36-020636rc8-generic
* 2.6.36-020636-generic
* 2.6.36-02063601-generic
* 2.6.37-999-generic (daily-201012081134)

Testing versions in reverse order, I finally came to a version that did not exhibit the problem (no Oops or panic - the system remained usable):
* 2.6.33-02063307-generic

As a last bit of curiosity, I looked at the patch for 2.6.34rc1 and saw that ebtables.c has undergone extensive modifications. I have the gut feeling that the issue is related to those modifications.

If I can provide any other test results or more specifics about the test environment, or if I should re-test in another environment alltogether, please advise.