1. 02 6月, 2011 1 次提交
  2. 01 6月, 2011 1 次提交
  3. 26 5月, 2011 1 次提交
  4. 24 5月, 2011 1 次提交
    • D
      net: convert %p usage to %pK · 71338aa7
      Dan Rosenberg 提交于
      The %pK format specifier is designed to hide exposed kernel pointers,
      specifically via /proc interfaces.  Exposing these pointers provides an
      easy target for kernel write vulnerabilities, since they reveal the
      locations of writable structures containing easily triggerable function
      pointers.  The behavior of %pK depends on the kptr_restrict sysctl.
      
      If kptr_restrict is set to 0, no deviation from the standard %p behavior
      occurs.  If kptr_restrict is set to 1, the default, if the current user
      (intended to be a reader via seq_printf(), etc.) does not have CAP_SYSLOG
      (currently in the LSM tree), kernel pointers using %pK are printed as 0's.
       If kptr_restrict is set to 2, kernel pointers using %pK are printed as
      0's regardless of privileges.  Replacing with 0's was chosen over the
      default "(null)", which cannot be parsed by userland %p, which expects
      "(nil)".
      
      The supporting code for kptr_restrict and %pK are currently in the -mm
      tree.  This patch converts users of %p in net/ to %pK.  Cases of printing
      pointers to the syslog are not covered, since this would eliminate useful
      information for postmortem debugging and the reading of the syslog is
      already optionally protected by the dmesg_restrict sysctl.
      Signed-off-by: NDan Rosenberg <drosenberg@vsecurity.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Thomas Graf <tgraf@infradead.org>
      Cc: Eugene Teo <eugeneteo@kernel.org>
      Cc: Kees Cook <kees.cook@canonical.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Eric Paris <eparis@parisplace.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71338aa7
  5. 21 5月, 2011 1 次提交
  6. 20 5月, 2011 1 次提交
    • J
      SCTP: fix race between sctp_bind_addr_free() and sctp_bind_addr_conflict() · c182f90b
      Jacek Luczak 提交于
      During the sctp_close() call, we do not use rcu primitives to
      destroy the address list attached to the endpoint.  At the same
      time, we do the removal of addresses from this list before
      attempting to remove the socket from the port hash
      
      As a result, it is possible for another process to find the socket
      in the port hash that is in the process of being closed.  It then
      proceeds to traverse the address list to find the conflict, only
      to have that address list suddenly disappear without rcu() critical
      section.
      
      Fix issue by closing address list removal inside RCU critical
      section.
      
      Race can result in a kernel crash with general protection fault or
      kernel NULL pointer dereference:
      
      kernel: general protection fault: 0000 [#1] SMP
      kernel: RIP: 0010:[<ffffffffa02f3dde>]  [<ffffffffa02f3dde>] sctp_bind_addr_conflict+0x64/0x82 [sctp]
      kernel: Call Trace:
      kernel:  [<ffffffffa02f415f>] ? sctp_get_port_local+0x17b/0x2a3 [sctp]
      kernel:  [<ffffffffa02f3d45>] ? sctp_bind_addr_match+0x33/0x68 [sctp]
      kernel:  [<ffffffffa02f4416>] ? sctp_do_bind+0xd3/0x141 [sctp]
      kernel:  [<ffffffffa02f5030>] ? sctp_bindx_add+0x4d/0x8e [sctp]
      kernel:  [<ffffffffa02f5183>] ? sctp_setsockopt_bindx+0x112/0x4a4 [sctp]
      kernel:  [<ffffffff81089e82>] ? generic_file_aio_write+0x7f/0x9b
      kernel:  [<ffffffffa02f763e>] ? sctp_setsockopt+0x14f/0xfee [sctp]
      kernel:  [<ffffffff810c11fb>] ? do_sync_write+0xab/0xeb
      kernel:  [<ffffffff810e82ab>] ? fsnotify+0x239/0x282
      kernel:  [<ffffffff810c2462>] ? alloc_file+0x18/0xb1
      kernel:  [<ffffffff8134a0b1>] ? compat_sys_setsockopt+0x1a5/0x1d9
      kernel:  [<ffffffff8134aaf1>] ? compat_sys_socketcall+0x143/0x1a4
      kernel:  [<ffffffff810467dc>] ? sysenter_dispatch+0x7/0x32
      Signed-off-by: NJacek Luczak <luczak.jacek@gmail.com>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c182f90b
  7. 13 5月, 2011 2 次提交
  8. 11 5月, 2011 1 次提交
  9. 09 5月, 2011 4 次提交
  10. 08 5月, 2011 1 次提交
  11. 04 5月, 2011 1 次提交
  12. 28 4月, 2011 5 次提交
  13. 27 4月, 2011 1 次提交
  14. 23 4月, 2011 1 次提交
  15. 22 4月, 2011 3 次提交
  16. 20 4月, 2011 15 次提交