1. 17 10月, 2012 2 次提交
    • D
      mm, mempolicy: fix printing stack contents in numa_maps · 32f8516a
      David Rientjes 提交于
      When reading /proc/pid/numa_maps, it's possible to return the contents of
      the stack where the mempolicy string should be printed if the policy gets
      freed from beneath us.
      
      This happens because mpol_to_str() may return an error the
      stack-allocated buffer is then printed without ever being stored.
      
      There are two possible error conditions in mpol_to_str():
      
       - if the buffer allocated is insufficient for the string to be stored,
         and
      
       - if the mempolicy has an invalid mode.
      
      The first error condition is not triggered in any of the callers to
      mpol_to_str(): at least 50 bytes is always allocated on the stack and this
      is sufficient for the string to be written.  A future patch should convert
      this into BUILD_BUG_ON() since we know the maximum strlen possible, but
      that's not -rc material.
      
      The second error condition is possible if a race occurs in dropping a
      reference to a task's mempolicy causing it to be freed during the read().
      The slab poison value is then used for the mode and mpol_to_str() returns
      -EINVAL.
      
      This race is only possible because get_vma_policy() believes that
      mm->mmap_sem protects task->mempolicy, which isn't true.  The exit path
      does not hold mm->mmap_sem when dropping the reference or setting
      task->mempolicy to NULL: it uses task_lock(task) instead.
      
      Thus, it's required for the caller of a task mempolicy to hold
      task_lock(task) while grabbing the mempolicy and reading it.  Callers with
      a vma policy store their mempolicy earlier and can simply increment the
      reference count so it's guaranteed not to be freed.
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      32f8516a
    • A
      fix a leak in replace_fd() users · 45525b26
      Al Viro 提交于
      replace_fd() began with "eats a reference, tries to insert into
      descriptor table" semantics; at some point I'd switched it to
      much saner current behaviour ("try to insert into descriptor
      table, grabbing a new reference if inserted; caller should do
      fput() in any case"), but forgot to update the callers.
      Mea culpa...
      
      [Spotted by Pavel Roskin, who has really weird system with pipe-fed
      coredumps as part of what he considers a normal boot ;-)]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      45525b26
  2. 13 10月, 2012 9 次提交
  3. 12 10月, 2012 7 次提交
  4. 11 10月, 2012 1 次提交
  5. 10 10月, 2012 19 次提交
  6. 09 10月, 2012 2 次提交