]> git.baikalelectronics.ru Git - kernel.git/commit
bridge: Fix br_forward crash in promiscuous mode
authorMichael Braun <michael-dev@fami-braun.de>
Tue, 16 Mar 2010 07:26:22 +0000 (00:26 -0700)
committerDavid S. Miller <davem@davemloft.net>
Tue, 16 Mar 2010 07:26:22 +0000 (00:26 -0700)
commitc4741412466c638d668a4dba4f39896620206ea9
tree385da7d1b722232c3c9003af52079318aa51326e
parentee311c475f21ba360aa8402f98112034f082193b
bridge: Fix br_forward crash in promiscuous mode

From: Michael Braun <michael-dev@fami-braun.de>

bridge: Fix br_forward crash in promiscuous mode

It's a linux-next kernel from 2010-03-12 on an x86 system and it
OOPs in the bridge module in br_pass_frame_up (called by
br_handle_frame_finish) because brdev cannot be dereferenced (its set to
a non-null value).

Adding some BUG_ON statements revealed that
 BR_INPUT_SKB_CB(skb)->brdev == br-dev
(as set in br_handle_frame_finish first)
only holds until br_forward is called.
The next call to br_pass_frame_up then fails.

Digging deeper it seems that br_forward either frees the skb or passes
it to NF_HOOK which will in turn take care of freeing the skb. The
same is holds for br_pass_frame_ip. So it seems as if two independent
skb allocations are required. As far as I can see, commit
f449608154ebb29c7ffc5c893e6d9e040216b52c ("bridge: Avoid unnecessary
clone on forward path") removed skb duplication and so likely causes
this crash. This crash does not happen on 2.6.33.

I've therefore modified br_forward the same way br_flood has been
modified so that the skb is not freed if skb0 is going to be used
and I can confirm that the attached patch resolves the issue for me.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/bridge/br_forward.c
net/bridge/br_input.c
net/bridge/br_private.h