1. 12 Dec, 2013 5 commits
    • Linus Torvalds's avatar
      Merge tag 'iommu-fixes-for-v3.13-rc4' of git://github.com/awilliam/linux-vfio · 319720f5
      Linus Torvalds authored
      Pull iommu fixes from Alex Williamson:
       "arm/smmu driver updates via Will Deacon fixing locking around page
        table walks and a couple other issues"
      
      * tag 'iommu-fixes-for-v3.13-rc4' of git://github.com/awilliam/linux-vfio:
        iommu/arm-smmu: fix error return code in arm_smmu_device_dt_probe()
        iommu/arm-smmu: remove potential NULL dereference on mapping path
        iommu/arm-smmu: use mutex instead of spinlock for locking page tables
      319720f5
    • Linus Torvalds's avatar
      Merge tag 'keys-devel-20131210' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · 5dec682c
      Linus Torvalds authored
      Pull misc keyrings fixes from David Howells:
       "These break down into five sets:
      
         - A patch to error handling in the big_key type for huge payloads.
           If the payload is larger than the "low limit" and the backing store
           allocation fails, then big_key_instantiate() doesn't clear the
           payload pointers in the key, assuming them to have been previously
           cleared - but only one of them is.
      
           Unfortunately, the garbage collector still calls big_key_destroy()
           when sees one of the pointers with a weird value in it (and not
           NULL) which it then tries to clean up.
      
         - Three patches to fix the keyring type:
      
           * A patch to fix the hash function to correctly divide keyrings off
             from keys in the topology of the tree inside the associative
             array.  This is only a problem if searching through nested
             keyrings - and only if the hash function incorrectly puts the a
             keyring outside of the 0 branch of the root node.
      
           * A patch to fix keyrings' use of the associative array.  The
             __key_link_begin() function initially passes a NULL key pointer
             to assoc_array_insert() on the basis that it's holding a place in
             the tree whilst it does more allocation and stuff.
      
             This is only a problem when a node contains 16 keys that match at
             that level and we want to add an also matching 17th.  This should
             easily be manufactured with a keyring full of keyrings (without
             chucking any other sort of key into the mix) - except for (a)
             above which makes it on average adding the 65th keyring.
      
           * A patch to fix searching down through nested keyrings, where any
             keyring in the set has more than 16 keyrings and none of the
             first keyrings we look through has a match (before the tree
             iteration needs to step to a more distal node).
      
           Test in keyutils test suite:
      
              http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=8b4ae963ed92523aea18dfbb8cab3f4979e13bd1
      
         - A patch to fix the big_key type's use of a shmem file as its
           backing store causing audit messages and LSM check failures.  This
           is done by setting S_PRIVATE on the file to avoid LSM checks on the
           file (access to the shmem file goes through the keyctl() interface
           and so is gated by the LSM that way).
      
           This isn't normally a problem if a key is used by the context that
           generated it - and it's currently only used by libkrb5.
      
           Test in keyutils test suite:
      
              http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=d9a53cbab42c293962f2f78f7190253fc73bd32e
      
         - A patch to add a generated file to .gitignore.
      
         - A patch to fix the alignment of the system certificate data such
           that it it works on s390.  As I understand it, on the S390 arch,
           symbols must be 2-byte aligned because loading the address discards
           the least-significant bit"
      
      * tag 'keys-devel-20131210' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
        KEYS: correct alignment of system_certificate_list content in assembly file
        Ignore generated file kernel/x509_certificate_list
        security: shmem: implement kernel private shmem inodes
        KEYS: Fix searching of nested keyrings
        KEYS: Fix multiple key add into associative array
        KEYS: Fix the keyring hash function
        KEYS: Pre-clear struct key on allocation
      5dec682c
    • Linus Torvalds's avatar
      Merge tag 'xfs-for-linus-v3.13-rc4' of git://oss.sgi.com/xfs/xfs · 48a2f0b2
      Linus Torvalds authored
      Pull xfs bugfixes from Ben Myers:
      
       - fix for buffer overrun in agfl with growfs on v4 superblock
      
       - return EINVAL if requested discard length is less than a block
      
       - fix possible memory corruption in xfs_attrlist_by_handle()
      
      * tag 'xfs-for-linus-v3.13-rc4' of git://oss.sgi.com/xfs/xfs:
        xfs: growfs overruns AGFL buffer on V4 filesystems
        xfs: don't perform discard if the given range length is less than block size
        xfs: underflow bug in xfs_attrlist_by_handle()
      48a2f0b2
    • Linus Torvalds's avatar
      futex: move user address verification up to common code · 5cdec2d8
      Linus Torvalds authored
      When debugging the read-only hugepage case, I was confused by the fact
      that get_futex_key() did an access_ok() only for the non-shared futex
      case, since the user address checking really isn't in any way specific
      to the private key handling.
      
      Now, it turns out that the shared key handling does effectively do the
      equivalent checks inside get_user_pages_fast() (it doesn't actually
      check the address range on x86, but does check the page protections for
      being a user page).  So it wasn't actually a bug, but the fact that we
      treat the address differently for private and shared futexes threw me
      for a loop.
      
      Just move the check up, so that it gets done for both cases.  Also, use
      the 'rw' parameter for the type, even if it doesn't actually matter any
      more (it's a historical artifact of the old racy i386 "page faults from
      kernel space don't check write protections").
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5cdec2d8
    • Linus Torvalds's avatar
      futex: fix handling of read-only-mapped hugepages · f12d5bfc
      Linus Torvalds authored
      The hugepage code had the exact same bug that regular pages had in
      commit 7485d0d3 ("futexes: Remove rw parameter from
      get_futex_key()").
      
      The regular page case was fixed by commit 9ea71503 ("futex: Fix
      regression with read only mappings"), but the transparent hugepage case
      (added in a5b338f2: "thp: update futex compound knowledge") case
      remained broken.
      
      Found by Dave Jones and his trinity tool.
      Reported-and-tested-by: default avatarDave Jones <davej@fedoraproject.org>
      Cc: stable@kernel.org # v2.6.38+
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Darren Hart <dvhart@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f12d5bfc
  2. 10 Dec, 2013 26 commits
  3. 09 Dec, 2013 9 commits