1. 10 Nov, 2010 2 commits
    • David S. Miller's avatar
      filter: make sure filters dont read uninitialized memory · 57fe93b3
      David S. Miller authored
      There is a possibility malicious users can get limited information about
      uninitialized stack mem array. Even if sk_run_filter() result is bound
      to packet length (0 .. 65535), we could imagine this can be used by
      hostile user.
      
      Initializing mem[] array, like Dan Rosenberg suggested in his patch is
      expensive since most filters dont even use this array.
      
      Its hard to make the filter validation in sk_chk_filter(), because of
      the jumps. This might be done later.
      
      In this patch, I use a bitmap (a single long var) so that only filters
      using mem[] loads/stores pay the price of added security checks.
      
      For other filters, additional cost is a single instruction.
      
      [ Since we access fentry->k a lot now, cache it in a local variable
        and mark filter entry pointer as const. -DaveM ]
      Reported-by: default avatarDan Rosenberg <drosenberg@vsecurity.com>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      57fe93b3
    • Vasiliy Kulikov's avatar
      net: ax25: fix information leak to userland · fe10ae53
      Vasiliy Kulikov authored
      Sometimes ax25_getname() doesn't initialize all members of fsa_digipeater
      field of fsa struct, also the struct has padding bytes between
      sax25_call and sax25_ndigis fields.  This structure is then copied to
      userland.  It leads to leaking of contents of kernel stack memory.
      Signed-off-by: default avatarVasiliy Kulikov <segooon@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe10ae53
  2. 09 Nov, 2010 5 commits
  3. 08 Nov, 2010 11 commits
  4. 07 Nov, 2010 1 commit
  5. 04 Nov, 2010 17 commits
  6. 03 Nov, 2010 2 commits
  7. 01 Nov, 2010 2 commits