1. 29 4月, 2007 9 次提交
  2. 11 4月, 2007 9 次提交
  3. 10 4月, 2007 1 次提交
  4. 09 4月, 2007 6 次提交
  5. 08 4月, 2007 4 次提交
  6. 07 4月, 2007 3 次提交
  7. 06 4月, 2007 5 次提交
  8. 05 4月, 2007 3 次提交
    • H
      [IPSEC]: Reject packets within replay window but outside the bit mask · 4c4d51a7
      Herbert Xu 提交于
      Up until this point we've accepted replay window settings greater than
      32 but our bit mask can only accomodate 32 packets.  Thus any packet
      with a sequence number within the window but outside the bit mask would
      be accepted.
      
      This patch causes those packets to be rejected instead.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c4d51a7
    • M
      [IPv6]: Exclude truncated packets from InHdrErrors statistics · 60e5c166
      Mitsuru Chinen 提交于
      Incoming trancated packets are counted as not only InTruncatedPkts but
      also InHdrErrors. They should be counted as InTruncatedPkts only.
      Signed-off-by: NMitsuru Chinen <mitch@linux.vnet.ibm.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60e5c166
    • J
      [APPLETALK]: Fix a remotely triggerable crash · 75559c16
      Jean Delvare 提交于
      When we receive an AppleTalk frame shorter than what its header says,
      we still attempt to verify its checksum, and trip on the BUG_ON() at
      the end of function atalk_sum_skb() because of the length mismatch.
      
      This has security implications because this can be triggered by simply
      sending a specially crafted ethernet frame to a target victim,
      effectively crashing that host. Thus this qualifies, I think, as a
      remote DoS. Here is the frame I used to trigger the crash, in npg
      format:
      
      <Appletalk Killer>
      {
      # Ethernet header -----
      
        XX XX XX XX XX XX  # Destination MAC
        00 00 00 00 00 00  # Source MAC
        00 1D              # Length
      
      # LLC header -----
      
        AA AA 03
        08 00 07 80 9B  # Appletalk
      
      # Appletalk header -----
      
        00 1B        # Packet length (invalid)
        00 01        # Fake checksum 
        00 00 00 00  # Destination and source networks
        00 00 00 00  # Destination and source nodes and ports
      
      # Payload -----
      
        0C 0D 0E 0F 10 11 12 13
        14
      }
      
      The destination MAC address must be set to those of the victim.
      
      The severity is mitigated by two requirements:
      * The target host must have the appletalk kernel module loaded. I
        suspect this isn't so frequent.
      * AppleTalk frames are non-IP, thus I guess they can only travel on
        local networks. I am no network expert though, maybe it is possible
        to somehow encapsulate AppleTalk packets over IP.
      
      The bug has been reported back in June 2004:
        http://bugzilla.kernel.org/show_bug.cgi?id=2979
      But it wasn't investigated, and was closed in July 2006 as both
      reporters had vanished meanwhile.
      
      This code was new in kernel 2.6.0-test5:
        http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=7ab442d7e0a76402c12553ee256f756097cae2d2
      And not modified since then, so we can assume that vanilla kernels
      2.6.0-test5 and later, and distribution kernels based thereon, are
      affected.
      
      Note that I still do not know for sure what triggered the bug in the
      real-world cases. The frame could have been corrupted by the kernel if
      we have a bug hiding somewhere. But more likely, we are receiving the
      faulty frame from the network.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75559c16