1. 29 Jun, 2013 1 commit
  2. 04 Mar, 2013 1 commit
    • Eric W. Biederman's avatar
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman authored
      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
      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: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarKees Cook <keescook@google.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  3. 23 Feb, 2013 1 commit
  4. 21 Jan, 2013 1 commit
  5. 18 Nov, 2012 1 commit
  6. 09 Nov, 2012 1 commit
    • Thomas Betker's avatar
      jffs2: Fix lock acquisition order bug in jffs2_write_begin · 5ffd3412
      Thomas Betker authored
      jffs2_write_begin() first acquires the page lock, then f->sem. This
      causes an AB-BA deadlock with jffs2_garbage_collect_live(), which first
      acquires f->sem, then the page lock:
          mutex_lock(&f->sem)                         (A)
                          lock_page(page)             (B)
                  lock_page(page)                     (B)
          mutex_lock(&f->sem)                         (A)
      We fix this by restructuring jffs2_write_begin() to take f->sem before
      the page lock. However, we make sure that f->sem is not held when
      calling jffs2_reserve_space(), as this is not permitted by the locking
      The deadlock above was observed multiple times on an SoC with a dual
      ARMv7 (Cortex-A9), running the long-term 3.4.11 kernel; it occurred
      when using scp to copy files from a host system to the ARM target
      system. The fix was heavily tested on the same target system.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Betker <thomas.betker@rohde-schwarz.com>
      Acked-by: default avatarJoakim Tjernlund <Joakim.Tjernlund@transmode.se>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
  7. 09 Oct, 2012 1 commit
  8. 03 Oct, 2012 1 commit
  9. 29 Sep, 2012 2 commits
  10. 21 Sep, 2012 1 commit
  11. 18 Sep, 2012 1 commit
    • Eric W. Biederman's avatar
      userns: Pass a userns parameter into posix_acl_to_xattr and posix_acl_from_xattr · 5f3a4a28
      Eric W. Biederman authored
       - Pass the user namespace the uid and gid values in the xattr are stored
         in into posix_acl_from_xattr.
       - Pass the user namespace kuid and kgid values should be converted into
         when storing uid and gid values in an xattr in posix_acl_to_xattr.
      - Modify all callers of posix_acl_from_xattr and posix_acl_to_xattr to
        pass in &init_user_ns.
      In the short term this change is not strictly needed but it makes the
      code clearer.  In the longer term this change is necessary to be able to
      mount filesystems outside of the initial user namespace that natively
      store posix acls in the linux xattr format.
      Cc: Theodore Tso <tytso@mit.edu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  12. 22 Jul, 2012 1 commit
  13. 14 Jul, 2012 2 commits
  14. 31 May, 2012 4 commits
  15. 14 May, 2012 9 commits
  16. 07 May, 2012 1 commit
    • Josh Cartwright's avatar
      jffs2: Fix lock acquisition order bug in gc path · 226bb7df
      Josh Cartwright authored
      The locking policy is such that the erase_complete_block spinlock is
      nested within the alloc_sem mutex.  This fixes a case in which the
      acquisition order was erroneously reversed.  This issue was caught by
      the following lockdep splat:
         [ INFO: possible circular locking dependency detected ]
         3.0.5 #1
         jffs2_gcd_mtd6/299 is trying to acquire lock:
          (&c->alloc_sem){+.+.+.}, at: [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
         but task is already holding lock:
          (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890
         which lock already depends on the new lock.
         the existing dependency chain (in reverse order) is:
         -> #1 (&(&c->erase_completion_lock)->rlock){+.+...}:
                [<c008bec4>] validate_chain+0xe6c/0x10bc
                [<c008c660>] __lock_acquire+0x54c/0xba4
                [<c008d240>] lock_acquire+0xa4/0x114
                [<c046780c>] _raw_spin_lock+0x3c/0x4c
                [<c01f744c>] jffs2_garbage_collect_pass+0x4c/0x890
                [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
                [<c0071a68>] kthread+0x98/0xa0
                [<c000f264>] kernel_thread_exit+0x0/0x8
         -> #0 (&c->alloc_sem){+.+.+.}:
                [<c008ad2c>] print_circular_bug+0x70/0x2c4
                [<c008c08c>] validate_chain+0x1034/0x10bc
                [<c008c660>] __lock_acquire+0x54c/0xba4
                [<c008d240>] lock_acquire+0xa4/0x114
                [<c0466628>] mutex_lock_nested+0x74/0x33c
                [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
                [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
                [<c0071a68>] kthread+0x98/0xa0
                [<c000f264>] kernel_thread_exit+0x0/0x8
         other info that might help us debug this:
          Possible unsafe locking scenario:
                CPU0                    CPU1
                ----                    ----
          *** DEADLOCK ***
         1 lock held by jffs2_gcd_mtd6/299:
          #0:  (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890
         stack backtrace:
         [<c00155dc>] (unwind_backtrace+0x0/0x100) from [<c0463dc0>] (dump_stack+0x20/0x24)
         [<c0463dc0>] (dump_stack+0x20/0x24) from [<c008ae84>] (print_circular_bug+0x1c8/0x2c4)
         [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) from [<c008c08c>] (validate_chain+0x1034/0x10bc)
         [<c008c08c>] (validate_chain+0x1034/0x10bc) from [<c008c660>] (__lock_acquire+0x54c/0xba4)
         [<c008c660>] (__lock_acquire+0x54c/0xba4) from [<c008d240>] (lock_acquire+0xa4/0x114)
         [<c008d240>] (lock_acquire+0xa4/0x114) from [<c0466628>] (mutex_lock_nested+0x74/0x33c)
         [<c0466628>] (mutex_lock_nested+0x74/0x33c) from [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890)
         [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) from [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc)
         [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [<c0071a68>] (kthread+0x98/0xa0)
         [<c0071a68>] (kthread+0x98/0xa0) from [<c000f264>] (kernel_thread_exit+0x0/0x8)
      This was introduce in '81cfc9f1 jffs2: Fix serious write stall due to erase'.
      Cc: stable@kernel.org [2.6.37+]
      Signed-off-by: default avatarJosh Cartwright <joshc@linux.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  17. 06 May, 2012 1 commit
  18. 27 Mar, 2012 1 commit
  19. 26 Mar, 2012 9 commits