1. 18 11月, 2010 3 次提交
    • S
      8139cp: fix checksum broken · 24b7ea9f
      Shan Wei 提交于
      I am not family with RealTek RTL-8139C+ series 10/100 PCI Ethernet driver.
      I try to guess the meaning of RxProtoIP and IPFail.
      RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
      !(status & IPFail) is true means that driver correctly to check checksum in IPv4 header.
      
      If these are right, driver will set ip_summed with CHECKSUM_UNNECESSARY for other
      upper protocol, e.g. sctp, igmp protocol. This will cause protocol stack ignores
      checksum check for packets with invalid checksum.
      
      This patch is only compile-test.
      Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24b7ea9f
    • S
      r8169: fix checksum broken · d5d3ebe3
      Shan Wei 提交于
      If r8196 received packets with invalid sctp/igmp(not tcp, udp) checksum, r8196 set skb->ip_summed
      wit CHECKSUM_UNNECESSARY. This cause that upper protocol don't check checksum field.
      
      I am not family with r8196 driver. I try to guess the meaning of RxProtoIP and IPFail.
      RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
      !(opts1 & IPFail) is true means that driver correctly to check checksum in IPv4 header.
      
      If it's right, I think we should not set ip_summed wit CHECKSUM_UNNECESSARY for my sctp packets
      with invalid checksum.
      
      If it's not right, please tell me.
      Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
      Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5d3ebe3
    • D
      rds: Integer overflow in RDS cmsg handling · 218854af
      Dan Rosenberg 提交于
      In rds_cmsg_rdma_args(), the user-provided args->nr_local value is
      restricted to less than UINT_MAX.  This seems to need a tighter upper
      bound, since the calculation of total iov_size can overflow, resulting
      in a small sock_kmalloc() allocation.  This would probably just result
      in walking off the heap and crashing when calling rds_rdma_pages() with
      a high count value.  If it somehow doesn't crash here, then memory
      corruption could occur soon after.
      Signed-off-by: NDan Rosenberg <drosenberg@vsecurity.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      218854af
  2. 17 11月, 2010 2 次提交
  3. 16 11月, 2010 1 次提交
    • A
      net: rtnetlink.h -- only include linux/netdevice.h when used by the kernel · 3b42a96d
      Andy Whitcroft 提交于
      The commit below added a new helper dev_ingress_queue to cleanly obtain the
      ingress queue pointer.  This necessitated including 'linux/netdevice.h':
      
        commit 24824a09
        Author: Eric Dumazet <eric.dumazet@gmail.com>
        Date:   Sat Oct 2 06:11:55 2010 +0000
      
          net: dynamic ingress_queue allocation
      
      However this include triggers issues for applications in userspace
      which use the rtnetlink interfaces.  Commonly this requires they include
      'net/if.h' and 'linux/rtnetlink.h' leading to a compiler error as below:
      
        In file included from /usr/include/linux/netdevice.h:28:0,
                         from /usr/include/linux/rtnetlink.h:9,
                         from t.c:2:
        /usr/include/linux/if.h:135:8: error: redefinition of ‘struct ifmap’
        /usr/include/net/if.h:112:8: note: originally defined here
        /usr/include/linux/if.h:169:8: error: redefinition of ‘struct ifreq’
        /usr/include/net/if.h:127:8: note: originally defined here
        /usr/include/linux/if.h:218:8: error: redefinition of ‘struct ifconf’
        /usr/include/net/if.h:177:8: note: originally defined here
      
      The new helper is only defined for the kernel and protected by __KERNEL__
      therefore we can simply pull the include down into the same protected
      section.
      Signed-off-by: NAndy Whitcroft <apw@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b42a96d
  4. 13 11月, 2010 34 次提交