1. 11 12月, 2013 1 次提交
  2. 21 11月, 2013 1 次提交
    • H
      net: rework recvmsg handler msg_name and msg_namelen logic · f3d33426
      Hannes Frederic Sowa 提交于
      This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
      set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
      to return msg_name to the user.
      
      This prevents numerous uninitialized memory leaks we had in the
      recvmsg handlers and makes it harder for new code to accidentally leak
      uninitialized memory.
      
      Optimize for the case recvfrom is called with NULL as address. We don't
      need to copy the address at all, so set it to NULL before invoking the
      recvmsg handler. We can do so, because all the recvmsg handlers must
      cope with the case a plain read() is called on them. read() also sets
      msg_name to NULL.
      
      Also document these changes in include/linux/net.h as suggested by David
      Miller.
      
      Changes since RFC:
      
      Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
      non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
      affect sendto as it would bail out earlier while trying to copy-in the
      address. It also more naturally reflects the logic by the callers of
      verify_iovec.
      
      With this change in place I could remove "
      if (!uaddr || msg_sys->msg_namelen == 0)
      	msg->msg_name = NULL
      ".
      
      This change does not alter the user visible error logic as we ignore
      msg_namelen as long as msg_name is NULL.
      
      Also remove two unnecessary curly brackets in ___sys_recvmsg and change
      comments to netdev style.
      
      Cc: David Miller <davem@davemloft.net>
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3d33426
  3. 25 9月, 2013 1 次提交
  4. 27 10月, 2012 1 次提交
  5. 26 6月, 2012 1 次提交
    • E
      NFC: Return from rawsock_release when sk is NULL · 03e934f6
      Eric Dumazet 提交于
      Sasha Levin reported following panic :
      
      [ 2136.383310] BUG: unable to handle kernel NULL pointer dereference at
      00000000000003b0
      [ 2136.384022] IP: [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
      [ 2136.384022] PGD 131c4067 PUD 11c0c067 PMD 0
      [ 2136.388106] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [ 2136.388106] CPU 1
      [ 2136.388106] Pid: 24855, comm: trinity-child1 Tainted: G        W
      3.5.0-rc2-sasha-00015-g7b268f7 #374
      [ 2136.388106] RIP: 0010:[<ffffffff8114e400>]  [<ffffffff8114e400>]
      __lock_acquire+0xc0/0x4b0
      [ 2136.388106] RSP: 0018:ffff8800130b3ca8  EFLAGS: 00010046
      [ 2136.388106] RAX: 0000000000000086 RBX: ffff88001186b000 RCX:
      0000000000000000
      [ 2136.388106] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
      0000000000000000
      [ 2136.388106] RBP: ffff8800130b3d08 R08: 0000000000000001 R09:
      0000000000000000
      [ 2136.388106] R10: 0000000000000000 R11: 0000000000000001 R12:
      0000000000000002
      [ 2136.388106] R13: 00000000000003b0 R14: 0000000000000000 R15:
      0000000000000000
      [ 2136.388106] FS:  00007fa5b1bd4700(0000) GS:ffff88001b800000(0000)
      knlGS:0000000000000000
      [ 2136.388106] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2136.388106] CR2: 00000000000003b0 CR3: 0000000011d1f000 CR4:
      00000000000406e0
      [ 2136.388106] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
      0000000000000000
      [ 2136.388106] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
      0000000000000400
      [ 2136.388106] Process trinity-child1 (pid: 24855, threadinfo
      ffff8800130b2000, task ffff88001186b000)
      [ 2136.388106] Stack:
      [ 2136.388106]  ffff8800130b3cd8 ffffffff81121785 ffffffff81236774
      000080d000000001
      [ 2136.388106]  ffff88001b9d6c00 00000000001d6c00 ffffffff130b3d08
      ffff88001186b000
      [ 2136.388106]  0000000000000000 0000000000000002 0000000000000000
      0000000000000000
      [ 2136.388106] Call Trace:
      [ 2136.388106]  [<ffffffff81121785>] ? sched_clock_local+0x25/0x90
      [ 2136.388106]  [<ffffffff81236774>] ? get_empty_filp+0x74/0x220
      [ 2136.388106]  [<ffffffff8114e97a>] lock_acquire+0x18a/0x1e0
      [ 2136.388106]  [<ffffffff836b37df>] ? rawsock_release+0x4f/0xa0
      [ 2136.388106]  [<ffffffff837c0ef0>] _raw_write_lock_bh+0x40/0x80
      [ 2136.388106]  [<ffffffff836b37df>] ? rawsock_release+0x4f/0xa0
      [ 2136.388106]  [<ffffffff836b37df>] rawsock_release+0x4f/0xa0
      [ 2136.388106]  [<ffffffff8321cfe8>] sock_release+0x18/0x70
      [ 2136.388106]  [<ffffffff8321d069>] sock_close+0x29/0x30
      [ 2136.388106]  [<ffffffff81236bca>] __fput+0x11a/0x2c0
      [ 2136.388106]  [<ffffffff81236d85>] fput+0x15/0x20
      [ 2136.388106]  [<ffffffff8321de34>] sys_accept4+0x1b4/0x200
      [ 2136.388106]  [<ffffffff837c165c>] ? _raw_spin_unlock_irq+0x4c/0x80
      [ 2136.388106]  [<ffffffff837c1669>] ? _raw_spin_unlock_irq+0x59/0x80
      [ 2136.388106]  [<ffffffff837c2565>] ? sysret_check+0x22/0x5d
      [ 2136.388106]  [<ffffffff8321de8b>] sys_accept+0xb/0x10
      [ 2136.388106]  [<ffffffff837c2539>] system_call_fastpath+0x16/0x1b
      [ 2136.388106] Code: ec 04 00 0f 85 ea 03 00 00 be d5 0b 00 00 48 c7 c7
      8a c1 40 84 e8 b1 a5 f8 ff 31 c0 e9 d4 03 00 00 66 2e 0f 1f 84 00 00 00
      00 00 <49> 81 7d 00 60 73 5e 85 b8 01 00 00 00 44 0f 44 e0 83 fe 01 77
      [ 2136.388106] RIP  [<ffffffff8114e400>] __lock_acquire+0xc0/0x4b0
      [ 2136.388106]  RSP <ffff8800130b3ca8>
      [ 2136.388106] CR2: 00000000000003b0
      [ 2136.388106] ---[ end trace 6d450e935ee18982 ]---
      [ 2136.388106] Kernel panic - not syncing: Fatal exception in interrupt
      
      rawsock_release() should test if sock->sk is NULL before calling
      sock_orphan()/sock_put()
      Reported-by: NSasha Levin <levinsasha928@gmail.com>
      Tested-by: NSasha Levin <levinsasha928@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      03e934f6
  6. 13 4月, 2012 2 次提交
  7. 07 3月, 2012 1 次提交
  8. 25 1月, 2012 1 次提交
  9. 15 12月, 2011 3 次提交
  10. 01 12月, 2011 2 次提交
  11. 01 11月, 2011 1 次提交
  12. 25 8月, 2011 1 次提交
  13. 06 7月, 2011 1 次提交