1. 16 Jul, 2017 4 commits
  2. 12 Jul, 2017 6 commits
  3. 05 Jul, 2017 1 commit
  4. 09 May, 2017 1 commit
  5. 28 Feb, 2017 1 commit
    • Davidlohr Bueso's avatar
      ipc/shm: Fix shmat mmap nil-page protection · 95e91b83
      Davidlohr Bueso authored
      The issue is described here, with a nice testcase:
      The problem is that shmat() calls do_mmap_pgoff() with MAP_FIXED, and
      the address rounded down to 0.  For the regular mmap case, the
      protection mentioned above is that the kernel gets to generate the
      address -- arch_get_unmapped_area() will always check for MAP_FIXED and
      return that address.  So by the time we do security_mmap_addr(0) things
      get funky for shmat().
      The testcase itself shows that while a regular user crashes, root will
      not have a problem attaching a nil-page.  There are two possible fixes
      to this.  The first, and which this patch does, is to simply allow root
      to crash as well -- this is also regular mmap behavior, ie when hacking
      up the testcase and adding mmap(...  |MAP_FIXED).  While this approach
      is the safer option, the second alternative is to ignore SHM_RND if the
      rounded address is 0, thus only having MAP_SHARED flags.  This makes the
      behavior of shmat() identical to the mmap() case.  The downside of this
      is obviously user visible, but does make sense in that it maintains
      semantics after the round-down wrt 0 address and mmap.
      Passes shm related ltp tests.
      Link: http://lkml.kernel.org/r/1486050195-18629-1-git-send-email-dave@stgolabs.netSigned-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Reported-by: default avatarGareth Evans <gareth.evans@contextis.co.uk>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  6. 25 Feb, 2017 2 commits
  7. 20 Feb, 2017 2 commits
  8. 15 Dec, 2016 1 commit
  9. 26 Jul, 2016 2 commits
  10. 24 May, 2016 1 commit
  11. 19 Feb, 2016 1 commit
  12. 21 Jan, 2016 1 commit
  13. 30 Sep, 2015 1 commit
    • Linus Torvalds's avatar
      Initialize msg/shm IPC objects before doing ipc_addid() · b9a53227
      Linus Torvalds authored
      As reported by Dmitry Vyukov, we really shouldn't do ipc_addid() before
      having initialized the IPC object state.  Yes, we initialize the IPC
      object in a locked state, but with all the lockless RCU lookup work,
      that IPC object lock no longer means that the state cannot be seen.
      We already did this for the IPC semaphore code (see commit e8577d1f:
      "ipc/sem.c: fully initialize sem_array before making it visible") but we
      clearly forgot about msg and shm.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Davidlohr Bueso <dbueso@suse.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  14. 10 Sep, 2015 1 commit
    • Davidlohr Bueso's avatar
      ipc: convert invalid scenarios to use WARN_ON · d0edd852
      Davidlohr Bueso authored
      Considering Linus' past rants about the (ab)use of BUG in the kernel, I
      took a look at how we deal with such calls in ipc.  Given that any errors
      or corruption in ipc code are most likely contained within the set of
      processes participating in the broken mechanisms, there aren't really many
      strong fatal system failure scenarios that would require a BUG call.
      Also, if something is seriously wrong, ipc might not be the place for such
      a BUG either.
      1. For example, recently, a customer hit one of these BUG_ONs in shm
         after failing shm_lock().  A busted ID imho does not merit a BUG_ON,
         and WARN would have been better.
      2. MSG_COPY functionality of posix msgrcv(2) for checkpoint/restore.
         I don't see how we can hit this anyway -- at least it should be IS_ERR.
          The 'copy' arg from do_msgrcv is always set by calling prepare_copy()
         first and foremost.  We could also probably drop this check altogether.
          Either way, it does not merit a BUG_ON.
      3. No ->fault() callback for the fs getting the corresponding page --
         seems selfish to make the system unusable.
      Signed-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  15. 07 Aug, 2015 1 commit
    • Stephen Smalley's avatar
      ipc: use private shmem or hugetlbfs inodes for shm segments. · e1832f29
      Stephen Smalley authored
      The shm implementation internally uses shmem or hugetlbfs inodes for shm
      segments.  As these inodes are never directly exposed to userspace and
      only accessed through the shm operations which are already hooked by
      security modules, mark the inodes with the S_PRIVATE flag so that inode
      security initialization and permission checking is skipped.
      This was motivated by the following lockdep warning:
         [ INFO: possible circular locking dependency detected ]
         4.2.0-0.rc3.git0.1.fc24.x86_64+debug #1 Tainted: G        W
         httpd/1597 is trying to acquire lock:
         (&ids->rwsem){+++++.}, at: shm_close+0x34/0x130
         but task is already holding lock:
         (&mm->mmap_sem){++++++}, at: SyS_shmdt+0x4b/0x180
         which lock already depends on the new lock.
         the existing dependency chain (in reverse order) is:
         -> #3 (&mm->mmap_sem){++++++}:
              xfs_dir2_block_getdents.isra.12+0x198/0x1c0 [xfs]
              xfs_readdir+0x1b4/0x330 [xfs]
              xfs_file_readdir+0x2b/0x30 [xfs]
         -> #2 (&xfs_dir_ilock_class){++++.+}:
              xfs_ilock+0x167/0x350 [xfs]
              xfs_ilock_attr_map_shared+0x38/0x50 [xfs]
              xfs_attr_get+0xbd/0x190 [xfs]
              xfs_xattr_get+0x3d/0x70 [xfs]
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Reported-by: default avatarMorten Stevens <mstevens@fedoraproject.org>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarPaul Moore <paul@paul-moore.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Eric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  16. 01 Jul, 2015 2 commits
  17. 15 Apr, 2015 2 commits
  18. 13 Dec, 2014 2 commits
  19. 14 Oct, 2014 1 commit
    • Oleg Nesterov's avatar
      ipc/shm: kill the historical/wrong mm->start_stack check · bf77b94c
      Oleg Nesterov authored
      do_shmat() is the only user of ->start_stack (proc just reports its
      value), and this check looks ugly and wrong.
      The reason for this check is not clear at all, and it wrongly assumes that
      the stack can only grow down.
      But the main problem is that in general mm->start_stack has nothing to do
      with stack_vma->vm_start.  Not only the application can switch to another
      stack and even unmap this area, setup_arg_pages() expands the stack
      without updating mm->start_stack during exec().  This means that in the
      likely case "addr > start_stack - size - PAGE_SIZE * 5" is simply
      impossible after find_vma_intersection() == F, or the stack can't grow
      anyway because of RLIMIT_STACK.
      Many thanks to Hugh for his explanations.
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Davidlohr Bueso <davidlohr.bueso@hp.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  20. 08 Aug, 2014 2 commits
    • Jack Miller's avatar
      shm: allow exit_shm in parallel if only marking orphans · 83293c0f
      Jack Miller authored
      If shm_rmid_force (the default state) is not set then the shmids are only
      marked as orphaned and does not require any add, delete, or locking of the
      tree structure.
      Seperate the sysctl on and off case, and only obtain the read lock.  The
      newly added list head can be deleted under the read lock because we are
      only called with current and will only change the semids allocated by this
      task and not manipulate the list.
      This commit assumes that up_read includes a sufficient memory barrier for
      the writes to be seen my others that later obtain a write lock.
      Signed-off-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarJack Miller <millerjo@us.ibm.com>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Anton Blanchard <anton@samba.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Jack Miller's avatar
      shm: make exit_shm work proportional to task activity · ab602f79
      Jack Miller authored
      This is small set of patches our team has had kicking around for a few
      versions internally that fixes tasks getting hung on shm_exit when there
      are many threads hammering it at once.
      Anton wrote a simple test to cause the issue:
      Before applying this patchset, this test code will cause either hanging
      tracebacks or pthread out of memory errors.
      After this patchset, it will still produce output like:
        root@somehost:~# ./bust_shm_exit 1024 160
        INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 116, t=2111 jiffies, g=241, c=240, q=7113)
        INFO: Stall ended before state dump start
      But the task will continue to run along happily, so we consider this an
      improvement over hanging, even if it's a bit noisy.
      This patch (of 3):
      exit_shm obtains the ipc_ns shm rwsem for write and holds it while it
      walks every shared memory segment in the namespace.  Thus the amount of
      work is related to the number of shm segments in the namespace not the
      number of segments that might need to be cleaned.
      In addition, this occurs after the task has been notified the thread has
      exited, so the number of tasks waiting for the ns shm rwsem can grow
      without bound until memory is exausted.
      Add a list to the task struct of all shmids allocated by this task.  Init
      the list head in copy_process.  Use the ns->rwsem for locking.  Add
      segments after id is added, remove before removing from id.
      On unshare of NEW_IPCNS orphan any ids as if the task had exited, similar
      to handling of semaphore undo.
      I chose a define for the init sequence since its a simple list init,
      otherwise it would require a function call to avoid include loops between
      the semaphore code and the task struct.  Converting the list_del to
      list_del_init for the unshare cases would remove the exit followed by
      init, but I left it blow up if not inited.
      Signed-off-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarJack Miller <millerjo@us.ibm.com>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Anton Blanchard <anton@samba.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  21. 06 Jun, 2014 5 commits