1. 11 10月, 2007 1 次提交
  2. 09 5月, 2007 1 次提交
  3. 28 4月, 2007 1 次提交
  4. 26 4月, 2007 5 次提交
  5. 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
  6. 11 2月, 2007 1 次提交
  7. 04 12月, 2006 1 次提交
  8. 31 10月, 2006 1 次提交
  9. 29 9月, 2006 1 次提交
  10. 22 7月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  12. 29 3月, 2006 1 次提交
  13. 12 1月, 2006 1 次提交
  14. 04 1月, 2006 2 次提交
    • C
      [NET]: Add a dev_ioctl() fallback to sock_ioctl() · b5e5fa5e
      Christoph Hellwig 提交于
      Currently all network protocols need to call dev_ioctl as the default
      fallback in their ioctl implementations.  This patch adds a fallback
      to dev_ioctl to sock_ioctl if the protocol returned -ENOIOCTLCMD.
      This way all the procotol ioctl handlers can be simplified and we don't
      need to export dev_ioctl.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5e5fa5e
    • E
      [NET]: move struct proto_ops to const · 90ddc4f0
      Eric Dumazet 提交于
      I noticed that some of 'struct proto_ops' used in the kernel may share
      a cache line used by locks or other heavily modified data. (default
      linker alignement is 32 bytes, and L1_CACHE_LINE is 64 or 128 at
      least)
      
      This patch makes sure a 'struct proto_ops' can be declared as const,
      so that all cpus can share all parts of it without false sharing.
      
      This is not mandatory : a driver can still use a read/write structure
      if it needs to (and eventually a __read_mostly)
      
      I made a global stubstitute to change all existing occurences to make
      them const.
      
      This should reduce the possibility of false sharing on SMP, and
      speedup some socket system calls.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90ddc4f0
  15. 28 9月, 2005 1 次提交
    • O
      [APPLETALK]: Fix broadcast bug. · 64233bff
      Oliver Dawid 提交于
      From: Oliver Dawid <oliver@helios.de>
      
      we found a bug in net/appletalk/ddp.c concerning broadcast packets. In 
      kernel 2.4 it was working fine. The bug first occured 4 years ago when 
      switching to new SNAP layer handling. This bug can be splitted up into a 
      sending(1) and reception(2) problem:
      
      Sending(1)
      In kernel 2.4 broadcast packets were sent to a matching ethernet device 
      and atalk_rcv() was called to receive it as "loopback" (so loopback 
      packets were shortcutted and handled in DDP layer).
      
      When switching to the new SNAP structure, this shortcut was removed and 
      the loopback packet was send to SNAP layer. The author forgot to replace 
      the remote device pointer by the loopback device pointer before sending 
      the packet to SNAP layer (by calling ddp_dl->request() ) therfor the 
      packet was not sent back by underlying layers to ddp's atalk_rcv().
      
      Reception(2)
      In atalk_rcv() a packet received by this loopback mechanism contains now 
      the (rigth) loopback device pointer (in Kernel 2.4 it was the (wrong) 
      remote ethernet device pointer) and therefor no matching socket will be 
      found to deliver this packet to. Because a broadcast packet should be 
      send to the first matching socket (as it is done in many other protocols 
      (?)), we removed the network comparison in broadcast case.
      
      Below you will find a patch to correct this bug. Its diffed to kernel 
      2.6.14-rc1
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64233bff
  16. 30 8月, 2005 2 次提交
  17. 21 6月, 2005 1 次提交
  18. 20 4月, 2005 1 次提交
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4