1. 19 Apr, 2007 5 commits
  2. 15 Apr, 2007 1 commit
  3. 13 Apr, 2007 19 commits
  4. 10 Apr, 2007 2 commits
    • Adrian Bunk's avatar
      Linux 2.6.16.47-rc1 · 15a0dd9a
      Adrian Bunk authored
      15a0dd9a
    • Jean Delvare's avatar
      APPLETALK: Fix a remotely triggerable crash (CVE-2007-1357) · 132d8d23
      Jean Delvare authored
      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: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      132d8d23
  5. 08 Apr, 2007 7 commits
  6. 04 Apr, 2007 3 commits
  7. 03 Apr, 2007 1 commit
  8. 02 Apr, 2007 1 commit
    • David S. Miller's avatar
      [VIDEO] ffb: Fix two DAC handling bugs. · cceec518
      David S. Miller authored
      The determination of whether the DAC has inverted cursor logic is
      broken, import the version checks the X.org driver uses to fix this.
      
      Next, when we change the timing generator, borrow code from X.org that
      does 10 NOP reads of the timing generator register afterwards to make
      sure the video-enable transition occurs cleanly.
      
      Finally, use macros for the DAC registers and fields in order to
      provide documentation for the next person who reads this code.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      cceec518
  9. 31 Mar, 2007 1 commit