1. 05 Oct, 2007 2 commits
  2. 03 Oct, 2007 15 commits
  3. 02 Oct, 2007 17 commits
  4. 01 Oct, 2007 6 commits
    • John W. Linville's avatar
      [IEEE80211]: avoid integer underflow for runt rx frames · 04045f98
      John W. Linville authored
      Reported by Chris Evans <scarybeasts@gmail.com>:
      > The summary is that an evil 80211 frame can crash out a victim's
      > machine. It only applies to drivers using the 80211 wireless code, and
      > only then to certain drivers (and even then depends on a card's
      > firmware not dropping a dubious packet). I must confess I'm not
      > keeping track of Linux wireless support, and the different protocol
      > stacks etc.
      > Details are as follows:
      > ieee80211_rx() does not explicitly check that "skb->len >= hdrlen".
      > There are other skb->len checks, but not enough to prevent a subtle
      > off-by-two error if the frame has the IEEE80211_STYPE_QOS_DATA flag
      > set.
      > This leads to integer underflow and crash here:
      > if (frag != 0)
      >    flen -= hdrlen;
      > (flen is subsequently used as a memcpy length parameter).
      How about this?
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric Dumazet's avatar
      [TCP]: secure_tcp_sequence_number() should not use a too fast clock · 9b42c336
      Eric Dumazet authored
      TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
      In order to follow network speed increase, we can use a faster clock, but
      we should limit this clock so that the delay between two rollovers is
      greater than MSL (TCP Maximum Segment Lifetime : 2 minutes)
      Choosing a 64 nsec clock should be OK, since the rollovers occur every
      274 seconds.
      Problem spotted by Denys Fedoryshchenko
      [ This bug was introduced by f8595815
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Alexey Kuznetsov's avatar
      [SFQ]: Remove artificial limitation for queue limit. · 32740ddc
      Alexey Kuznetsov authored
      This is followup to Patrick's patch. A little optimization to enqueue
      routine allows to remove artificial limitation on queue length.
      Plus, testing showed that hash function used by SFQ is too bad or even worse.
      It does not even sweep the whole range of hash values.
      Switched to Jenkins' hash.
      Signed-off-by: default avatarAlexey Kuznetsov <kaber@ms2.inr.ac.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Linus Torvalds's avatar
      Linux 2.6.23-rc9 · 3146b39c
      Linus Torvalds authored
      No, I didn't want to do this, but we had more stuff go in after -rc8
      than we had in the previous -rc. Gaah.
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus · a3470171
      Linus Torvalds authored
      * 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
        [MIPS] vmlinux.lds.S: Handle note sections
        [MIPS] Fix value of O_TRUNC
    • Andi Kleen's avatar
      x86_64: increase VDSO_TEXT_OFFSET for ancient binutils · cf8dc57c
      Andi Kleen authored
      For some reason old binutils genertate larger headers so increase the text
      offset of the vdso to avoid linker errors.
      Roland McGrath explains:
        "There are extra symbols in the '.dynsym' section that are responsible
         for the size difference (They also cause corresponding inflation in
         Older ld's wrongly generated these unneeded symbols in .dynsym.  This
         was fixed not all that long ago (2006); binutils- might be
         the first fixed version, but I have not verified for sure where the
         cutoff was.
         The unneeded symbols et al from old ld add almost 700 bytes excess.
         This limits fairly tightly the amount by which the actual text and
         data in the vDSO can grow in the future without pushing the whole
         file over 4kb.  If it does grow later on, we should consider changing
         the layout with a config option or something to pack it better
         without that padding, when building the kernel with newer binutils."
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>