1. 17 3月, 2010 5 次提交
  2. 16 3月, 2010 2 次提交
    • M
      bridge: Fix br_forward crash in promiscuous mode · 7f7708f0
      Michael Braun 提交于
      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
      b33084be ("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: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f7708f0
    • H
      bridge: Move NULL mdb check into br_mdb_ip_get · 0821ec55
      Herbert Xu 提交于
      Since all callers of br_mdb_ip_get need to check whether the
      hash table is NULL, this patch moves the check into the function.
      
      This fixes the two callers (query/leave handler) that didn't
      check it.
      Reported-by: NMichael Braun <michael-dev@fami-braun.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0821ec55
  3. 14 3月, 2010 1 次提交
  4. 08 3月, 2010 4 次提交
  5. 03 3月, 2010 1 次提交
  6. 02 3月, 2010 1 次提交
  7. 28 2月, 2010 14 次提交
  8. 17 2月, 2010 7 次提交
  9. 16 2月, 2010 2 次提交
  10. 15 2月, 2010 1 次提交
  11. 05 2月, 2010 1 次提交
  12. 03 2月, 2010 1 次提交