1. 10 4月, 2013 2 次提交
  2. 13 3月, 2013 1 次提交
  3. 11 3月, 2013 1 次提交
  4. 07 3月, 2013 3 次提交
  5. 05 3月, 2013 3 次提交
    • H
      s390/mm: fix flush_tlb_kernel_range() · f6a70a07
      Heiko Carstens 提交于
      Our flush_tlb_kernel_range() implementation calls __tlb_flush_mm() with
      &init_mm as argument. __tlb_flush_mm() however will only flush tlbs
      for the passed in mm if its mm_cpumask is not empty.
      
      For the init_mm however its mm_cpumask has never any bits set. Which in
      turn means that our flush_tlb_kernel_range() implementation doesn't
      work at all.
      
      This can be easily verified with a vmalloc/vfree loop which allocates
      a page, writes to it and then frees the page again. A crash will follow
      almost instantly.
      
      To fix this remove the cpumask_empty() check in __tlb_flush_mm() since
      there shouldn't be too many mms with a zero mm_cpumask, besides the
      init_mm of course.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f6a70a07
    • H
      s390/mm: fix vmemmap size calculation · a7bb1ae7
      Heiko Carstens 提交于
      The size of the vmemmap must be a multiple of PAGES_PER_SECTION, since the
      common code always initializes the vmemmap in such pieces.
      So we must round up in order to not have a too small vmemmap.
      
      Fixes an IPL crash on 31 bit with more than 1920MB.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      a7bb1ae7
    • M
      s390: critical section cleanup vs. machine checks · 6551fbdf
      Martin Schwidefsky 提交于
      The current machine check code uses the registers stored by the machine
      in the lowcore at __LC_GPREGS_SAVE_AREA as the registers of the interrupted
      context. The registers 0-7 of a user process can get clobbered if a machine
      checks interrupts the execution of a critical section in entry[64].S.
      
      The reason is that the critical section cleanup code may need to modify
      the PSW and the registers for the previous context to get to the end of a
      critical section. If registers 0-7 have to be replaced the relevant copy
      will be in the registers, which invalidates the copy in the lowcore. The
      machine check handler needs to explicitly store registers 0-7 to the stack.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      6551fbdf
  6. 04 3月, 2013 1 次提交
    • E
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman 提交于
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reported-by: NKees Cook <keescook@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  7. 28 2月, 2013 12 次提交
  8. 26 2月, 2013 1 次提交
  9. 25 2月, 2013 1 次提交
  10. 24 2月, 2013 3 次提交
  11. 23 2月, 2013 1 次提交
  12. 14 2月, 2013 11 次提交