Skip to content
  1. May 01, 2015
  2. Apr 30, 2015
  3. Apr 28, 2015
  4. Apr 27, 2015
    • David S. Miller's avatar
      Merge branch 'ppp_mppe_desync' · 8e9b29cc
      David S. Miller authored
      
      
      Sylvain Rochet says:
      
      ====================
      ppp: mppe: fixes MPPE desync on links which don't guarantee packet ordering
      
      I am currently having an issue with PPP over L2TP (UDP) and MPPE in
      stateless mode (default mode), UDP does not guarantee packet ordering so
      we might get out of order packet. MPPE needs to be continuously synched
      so we should drop late UDP packet.
      
      I added a printk on the number of time we rekeyed in MPPE decompressor,
      this is what we currently have if we receive a slightly out of order UDP
      packet:
      
      [1731001.049206] mppe_decompress[1]: ccount 1559
      [1731001.049216] mppe_decompress[1]: rekeyed 1 times
      
      [1731001.049228] mppe_decompress[1]: ccount 1560
      [1731001.049232] mppe_decompress[1]: rekeyed 1 times
      
      [1731001.050170] mppe_decompress[1]: ccount 1562
      [1731001.050182] mppe_decompress[1]: rekeyed 2 times
      
      [1731001.050191] mppe_decompress[1]: ccount 1561
      [1731001.062576] mppe_decompress[1]: rekeyed 4095 times
                                                   ^^^^
      This is obviously wrong, we missed packet 1561 and we already rekeyed 2
      times for 1562 we previously received, we can't recover the decryption
      key we need for 1561, we should drop it instead of rekeying 4095 times.
      
      This patch series drop any packet with are not within the 4096/2 forward
      window.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e9b29cc
    • Sylvain Rochet's avatar
      ppp: mppe: discard late packet in stateless mode · 03654763
      Sylvain Rochet authored
      
      
      When PPP is used over a link which does not guarantee packet ordering,
      we might get late MPPE packets. This is a problem because MPPE must be
      kept synchronized and the current implementation does not drop them and
      rekey 4095 times instead of 0, which is wrong.
      
      In order to prevent rekeying about a whole count space times (~ 4095
      times), drop packets which are not within the forward 4096/2 window and
      increase sanity error counter.
      
      Signed-off-by: default avatarSylvain Rochet <sylvain.rochet@finsecur.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03654763
    • Sylvain Rochet's avatar
      ppp: mppe: sanity error path rework · 32530189
      Sylvain Rochet authored
      
      
      We are going to need sanity error path a little further, rework to be
      able to use the sanity error path anywhere in decompressor.
      
      Signed-off-by: default avatarSylvain Rochet <sylvain.rochet@finsecur.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32530189
    • Matan Barak's avatar
      net/bonding: Make DRV macros private · 73b5a6f2
      Matan Barak authored
      
      
      The bonding modules currently defines four macros with
      general names that pollute the global namespace:
      DRV_VERSION
      DRV_RELDATE
      DRV_NAME
      DRV_DESCRIPTION
      
      Fixing that by defining a private bonding_priv.h
      header files which includes those defines.
      
      Signed-off-by: default avatarMatan Barak <matanb@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73b5a6f2
    • Linus Torvalds's avatar
      Linux 4.1-rc1 · b787f68c
      Linus Torvalds authored
      b787f68c
    • Andy Lutomirski's avatar
      x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue · 61f01dd9
      Andy Lutomirski authored
      AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET with
      SS == 0 results in an invalid usermode state in which SS is apparently
      equal to __USER_DS but causes #SS if used.
      
      Work around the issue by setting SS to __KERNEL_DS __switch_to, thus
      ensuring that SYSRET never happens with SS set to NULL.
      
      This was exposed by a recent vDSO cleanup.
      
      Fixes: e7d6eefa
      
       x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <vda.linux@googlemail.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      61f01dd9
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 1190944f
      Linus Torvalds authored
      Pull intel drm fixes from Dave Airlie.
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg
        drm/i915: Workaround to avoid lite restore with HEAD==TAIL
        drm/i915: cope with large i2c transfers
      1190944f