1. 04 1月, 2006 32 次提交
  2. 28 12月, 2005 3 次提交
    • D
      [IPV6] mcast: Fix multiple issues in MLDv2 reports. · 5ab4a6c8
      David L Stevens 提交于
      The below "jumbo" patch fixes the following problems in MLDv2.
      
      1) Add necessary "ntohs" to recent "pskb_may_pull" check [breaks
              all nonzero source queries on little-endian (!)]
      
      2) Add locking to source filter list [resend of prior patch]
      
      3) fix "mld_marksources()" to
              a) send nothing when all queried sources are excluded
              b) send full exclude report when source queried sources are
                      not excluded
              c) don't schedule a timer when there's nothing to report
      
      NOTE: RFC 3810 specifies the source list should be saved and each
        source reported individually as an IS_IN. This is an obvious DOS
        path, requiring the host to store and then multicast as many sources
        as are queried (e.g., millions...). This alternative sends a full, 
        relevant report that's limited to number of sources present on the
        machine.
      
      4) fix "add_grec()" to send empty-source records when it should
              The original check doesn't account for a non-empty source
              list with all sources inactive; the new code keeps that
              short-circuit case, and also generates the group header
              with an empty list if needed.
      
      5) fix mca_crcount decrement to be after add_grec(), which needs
              its original value
      
      These issues (other than item #1 ;-) ) were all found by Yan Zheng,
      much thanks!
      Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ab4a6c8
    • D
      [NET]: Validate socket filters against BPF_MAXINSNS in one spot. · 1b93ae64
      David S. Miller 提交于
      Currently the checks are scattered all over and this leads
      to inconsistencies and even cases where the check is not made.
      
      Based upon a patch from Kris Katterjohn.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b93ae64
    • Y
      [IPV6]: Fix addrconf dead lock. · 6732bade
      YOSHIFUJI Hideaki 提交于
      We need to release idev->lcok before we call addrconf_dad_stop().
      It calls ipv6_addr_del(), which will hold idev->lock.
      
      Bug spotted by Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6732bade
  3. 27 12月, 2005 2 次提交
  4. 24 12月, 2005 2 次提交
  5. 22 12月, 2005 1 次提交
    • D
      [IPSEC]: Fix policy updates missed by sockets · 9b78a82c
      David S. Miller 提交于
      The problem is that when new policies are inserted, sockets do not see
      the update (but all new route lookups do).
      
      This bug is related to the SA insertion stale route issue solved
      recently, and this policy visibility problem can be fixed in a similar
      way.
      
      The fix is to flush out the bundles of all policies deeper than the
      policy being inserted.  Consider beginning state of "outgoing"
      direction policy list:
      
      	policy A --> policy B --> policy C --> policy D
      
      First, realize that inserting a policy into a list only potentially
      changes IPSEC routes for that direction.  Therefore we need not bother
      considering the policies for other directions.  We need only consider
      the existing policies in the list we are doing the inserting.
      
      Consider new policy "B'", inserted after B.
      
      	policy A --> policy B --> policy B' --> policy C --> policy D
      
      Two rules:
      
      1) If policy A or policy B matched before the insertion, they
         appear before B' and thus would still match after inserting
         B'
      
      2) Policy C and D, now "shadowed" and after policy B', potentially
         contain stale routes because policy B' might be selected
         instead of them.
      
      Therefore we only need flush routes assosciated with policies
      appearing after a newly inserted policy, if any.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b78a82c