1. 11 10月, 2007 36 次提交
  2. 08 10月, 2007 1 次提交
    • B
      [IPv6]: Fix ICMPv6 redirect handling with target multicast address · bf0b48df
      Brian Haley 提交于
      When the ICMPv6 Target address is multicast, Linux processes the 
      redirect instead of dropping it.  The problem is in this code in 
      ndisc_redirect_rcv():
      
               if (ipv6_addr_equal(dest, target)) {
                       on_link = 1;
               } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                       ND_PRINTK2(KERN_WARNING
                                  "ICMPv6 Redirect: target address is not 
      link-local.\n");
                       return;
               }
      
      This second check will succeed if the Target address is, for example, 
      FF02::1 because it has link-local scope.  Instead, it should be checking 
      if it's a unicast link-local address, as stated in RFC 2461/4861 Section 
      8.1:
      
             - The ICMP Target Address is either a link-local address (when
               redirected to a router) or the same as the ICMP Destination
               Address (when redirected to the on-link destination).
      
      I know this doesn't explicitly say unicast link-local address, but it's 
      implied.
      
      This bug is preventing Linux kernels from achieving IPv6 Logo Phase II 
      certification because of a recent error that was found in the TAHI test 
      suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the 
      multicast address in the Destination field instead of Target field, so 
      we were passing the test.  This won't be the case anymore.
      
      The patch below fixes this problem, and also fixes ndisc_send_redirect() 
      to not send an invalid redirect with a multicast address in the Target 
      field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux 
      passes all 245 tests now.
      Signed-off-by: NBrian Haley <brian.haley@hp.com>
      Acked-by: NDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf0b48df
  3. 29 9月, 2007 1 次提交
    • D
      [TCP]: Fix MD5 signature handling on big-endian. · f8ab18d2
      David S. Miller 提交于
      Based upon a report and initial patch by Peter Lieven.
      
      tcp4_md5sig_key and tcp6_md5sig_key need to start with
      the exact same members as tcp_md5sig_key.  Because they
      are both cast to that type by tcp_v{4,6}_md5_do_lookup().
      
      Unfortunately tcp{4,6}_md5sig_key use a u16 for the key
      length instead of a u8, which is what tcp_md5sig_key
      uses.  This just so happens to work by accident on
      little-endian, but on big-endian it doesn't.
      
      Instead of casting, just place tcp_md5sig_key as the first member of
      the address-family specific structures, adjust the access sites, and
      kill off the ugly casts.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8ab18d2
  4. 17 9月, 2007 1 次提交
  5. 15 9月, 2007 1 次提交