1. 01 2月, 2009 1 次提交
  2. 22 1月, 2009 1 次提交
  3. 08 1月, 2009 1 次提交
  4. 26 12月, 2008 1 次提交
    • J
      net/appletalk: Remove redundant test · 88a44e51
      Julia Lawall 提交于
      atif is tested for being NULL twice, with the same effect in each case.  I
      have kept the second test, as it seems to fit well with the comment above it.
      
      A simplified version of the semantic patch that makes this change is as
      follows: (http://www.emn.fr/x-info/coccinelle/)
      
      // <smpl>
      @r exists@
      local idexpression x;
      expression E;
      position p1,p2;
      @@
      
      if (x@p1 == NULL || ...) { ... when forall
         return ...; }
      ... when != \(x=E\|x--\|x++\|--x\|++x\|x-=E\|x+=E\|x|=E\|x&=E\|&x\)
      (
      x@p2 == NULL
      |
      x@p2 != NULL
      )
      
      // another path to the test that is not through p1?
      @s exists@
      local idexpression r.x;
      position r.p1,r.p2;
      @@
      
      ... when != x@p1
      (
      x@p2 == NULL
      |
      x@p2 != NULL
      )
      
      @fix depends on !s@
      position r.p1,r.p2;
      expression x,E;
      statement S1,S2;
      @@
      
      (
      - if ((x@p2 != NULL) || ...)
        S1
      |
      - if ((x@p2 == NULL) && ...) S1
      |
      - BUG_ON(x@p2 == NULL);
      )
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88a44e51
  5. 13 11月, 2008 1 次提交
    • W
      netdevice: safe convert to netdev_priv() #part-4 · 524ad0a7
      Wang Chen 提交于
      We have some reasons to kill netdev->priv:
      1. netdev->priv is equal to netdev_priv().
      2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously
         netdev_priv() is more flexible than netdev->priv.
      But we cann't kill netdev->priv, because so many drivers reference to it
      directly.
      
      This patch is a safe convert for netdev->priv to netdev_priv(netdev).
      Since all of the netdev->priv is only for read.
      But it is too big to be sent in one mail.
      I split it to 4 parts and make every part smaller than 100,000 bytes,
      which is max size allowed by vger.
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      524ad0a7
  6. 04 11月, 2008 1 次提交
    • A
      net: '&' redux · 6d9f239a
      Alexey Dobriyan 提交于
      I want to compile out proc_* and sysctl_* handlers totally and
      stub them to NULL depending on config options, however usage of &
      will prevent this, since taking adress of NULL pointer will break
      compilation.
      
      So, drop & in front of every ->proc_handler and every ->strategy
      handler, it was never needed in fact.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d9f239a
  7. 28 10月, 2008 1 次提交
  8. 14 10月, 2008 1 次提交
  9. 26 7月, 2008 1 次提交
  10. 20 7月, 2008 1 次提交
  11. 26 3月, 2008 1 次提交
  12. 01 3月, 2008 1 次提交
  13. 29 2月, 2008 1 次提交
  14. 29 1月, 2008 3 次提交
  15. 01 11月, 2007 1 次提交
  16. 11 10月, 2007 9 次提交
  17. 11 7月, 2007 1 次提交
  18. 09 5月, 2007 1 次提交
  19. 28 4月, 2007 1 次提交
  20. 26 4月, 2007 7 次提交
  21. 05 4月, 2007 1 次提交
    • 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
  22. 15 2月, 2007 2 次提交
  23. 13 2月, 2007 1 次提交