1. 15 Sep, 2016 7 commits
    • Jann Horn's avatar
      aio: mark AIO pseudo-fs noexec · 22f6b4d3
      Jann Horn authored
      This ensures that do_mmap() won't implicitly make AIO memory mappings
      executable if the READ_IMPLIES_EXEC personality flag is set.  Such
      behavior is problematic because the security_mmap_file LSM hook doesn't
      catch this case, potentially permitting an attacker to bypass a W^X
      policy enforced by SELinux.
      
      I have tested the patch on my machine.
      
      To test the behavior, compile and run this:
      
          #define _GNU_SOURCE
          #include <unistd.h>
          #include <sys/personality.h>
          #include <linux/aio_abi.h>
          #include <err.h>
          #include <stdlib.h>
          #include <stdio.h>
          #include <sys/syscall.h>
      
          int main(void) {
              personality(READ_IMPLIES_EXEC);
              aio_context_t ctx = 0;
              if (syscall(__NR_io_setup, 1, &ctx))
                  err(1, "io_setup");
      
              char cmd[1000];
              sprintf(cmd, "cat /proc/%d/maps | grep -F '/[aio]'",
                  (int)getpid());
              system(cmd);
              return 0;
          }
      
      In the output, "rw-s" is good, "rwxs" is bad.
      Signed-off-by: default avatarJann Horn <jann@thejh.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      22f6b4d3
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 024c7e37
      Linus Torvalds authored
      Pull kvm fix from Paolo Bonzini:
       "One fix for an x86 regression in VM migration, mostly visible with
        Windows because it uses RTC periodic interrupts"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        kvm: x86: correctly reset dest_map->vector when restoring LAPIC state
      024c7e37
    • Darrick J. Wong's avatar
      vfs: cap dedupe request structure size at PAGE_SIZE · b71dbf10
      Darrick J. Wong authored
      Kirill A Shutemov reports that the kernel doesn't try to cap dest_count
      in any way, and uses the number to allocate kernel memory.  This causes
      high order allocation warnings in the kernel log if someone passes in a
      big enough value.  We should clamp the allocation at PAGE_SIZE to avoid
      stressing the VM.
      
      The two existing users of the dedupe ioctl never send more than 120
      requests, so we can safely clamp dest_range at PAGE_SIZE, because with
      4k pages we can handle up to 127 dedupe candidates.  Given the max
      extent length of 16MB, we can end up doing 2GB of IO which is plenty.
      
      [ Note: the "offsetof()" can't overflow, because 'count' is just a
        16-bit integer.  That's not obvious in the limited context of the
        patch, so I'm noting it here because it made me go look.  - Linus ]
      Reported-by: default avatar"Kirill A. Shutemov" <kirill@shutemov.name>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b71dbf10
    • Darrick J. Wong's avatar
      vfs: fix return type of ioctl_file_dedupe_range · 5297e0f0
      Darrick J. Wong authored
      All the VFS functions in the dedupe ioctl path return int status, so
      the ioctl handler ought to as well.
      
      Found by Coverity, CID 1350952.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5297e0f0
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 46626600
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "A set of fixes for the current series in the realm of block.
      
        Like the previous pull request, the meat of it are fixes for the nvme
        fabrics/target code.  Outside of that, just one fix from Gabriel for
        not doing a queue suspend if we didn't get the admin queue setup in
        the first place"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        nvme-rdma: add back dependency on CONFIG_BLOCK
        nvme-rdma: fix null pointer dereference on req->mr
        nvme-rdma: use ib_client API to detect device removal
        nvme-rdma: add DELETING queue flag
        nvme/quirk: Add a delay before checking device ready for memblaze device
        nvme: Don't suspend admin queue that wasn't created
        nvme-rdma: destroy nvme queue rdma resources on connect failure
        nvme_rdma: keep a ref on the ctrl during delete/flush
        iw_cxgb4: block module unload until all ep resources are released
        iw_cxgb4: call dev_put() on l2t allocation failure
      46626600
    • Al Viro's avatar
      fix minor infoleak in get_user_ex() · 1c109fab
      Al Viro authored
      get_user_ex(x, ptr) should zero x on failure.  It's not a lot of a leak
      (at most we are leaking uninitialized 64bit value off the kernel stack,
      and in a fairly constrained situation, at that), but the fix is trivial,
      so...
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [ This sat in different branch from the uaccess fixes since mid-August ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1c109fab
    • Paolo Bonzini's avatar
      kvm: x86: correctly reset dest_map->vector when restoring LAPIC state · b0eaf450
      Paolo Bonzini authored
      When userspace sends KVM_SET_LAPIC, KVM schedules a check between
      the vCPU's IRR and ISR and the IOAPIC redirection table, in order
      to re-establish the IOAPIC's dest_map (the list of CPUs servicing
      the real-time clock interrupt with the corresponding vectors).
      
      However, __rtc_irq_eoi_tracking_restore_one was forgetting to
      set dest_map->vectors.  Because of this, the IOAPIC did not process
      the real-time clock interrupt EOI, ioapic->rtc_status.pending_eoi
      got stuck at a non-zero value, and further RTC interrupts were
      reported to userspace as coalesced.
      
      Fixes: 9e4aabe2
      Fixes: 4d99ba89
      Cc: stable@vger.kernel.org
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: David Gilbert <dgilbert@redhat.com>
      Reviewed-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b0eaf450
  2. 14 Sep, 2016 4 commits
    • Linus Torvalds's avatar
      Merge tag 'pci-v4.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · 4cea8776
      Linus Torvalds authored
      Pull PCI fixes from Bjorn Helgaas:
       "Here are two changes for v4.8.  The first fixes a "[Firmware Bug]: reg
        0x10: invalid BAR (can't size)" warning on Haswell, and the second
        fixes a problem in some new runtime suspend functionality we merged
        for v4.8.  Summary:
      
        Enumeration:
          Mark Haswell Power Control Unit as having non-compliant BARs (Bjorn Helgaas)
      
        Power management:
          Fix bridge_d3 update on device removal (Lukas Wunner)"
      
      * tag 'pci-v4.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        PCI: Fix bridge_d3 update on device removal
        PCI: Mark Haswell Power Control Unit as having non-compliant BARs
      4cea8776
    • Linus Torvalds's avatar
      Merge branch 'uaccess-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 77e5bdf9
      Linus Torvalds authored
      Pull uaccess fixes from Al Viro:
       "Fixes for broken uaccess primitives - mostly lack of proper zeroing
        in copy_from_user()/get_user()/__get_user(), but for several
        architectures there's more (broken clear_user() on frv and
        strncpy_from_user() on hexagon)"
      
      * 'uaccess-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (28 commits)
        avr32: fix copy_from_user()
        microblaze: fix __get_user()
        microblaze: fix copy_from_user()
        m32r: fix __get_user()
        blackfin: fix copy_from_user()
        sparc32: fix copy_from_user()
        sh: fix copy_from_user()
        sh64: failing __get_user() should zero
        score: fix copy_from_user() and friends
        score: fix __get_user/get_user
        s390: get_user() should zero on failure
        ppc32: fix copy_from_user()
        parisc: fix copy_from_user()
        openrisc: fix copy_from_user()
        nios2: fix __get_user()
        nios2: copy_from_user() should zero the tail of destination
        mn10300: copy_from_user() should zero on access_ok() failure...
        mn10300: failing __get_user() and get_user() should zero
        mips: copy_from_user() must zero the destination on access_ok() failure
        ARC: uaccess: get_user to zero out dest in cause of fault
        ...
      77e5bdf9
    • Linus Torvalds's avatar
      Merge tag 'for-linus-4.8b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip · b8f26e88
      Linus Torvalds authored
      Pull xen regression fix from David Vrabel:
       "Fix SMP boot in arm guests"
      
      * tag 'for-linus-4.8b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
        arm/xen: fix SMP guests boot
      b8f26e88
    • Vitaly Kuznetsov's avatar
      arm/xen: fix SMP guests boot · de75abbe
      Vitaly Kuznetsov authored
      Commit 88e957d6 ("xen: introduce xen_vcpu_id mapping") broke SMP
      ARM guests on Xen. When FIFO-based event channels are in use (this is
      the default), evtchn_fifo_alloc_control_block() is called on
      CPU_UP_PREPARE event and this happens before we set up xen_vcpu_id
      mapping in xen_starting_cpu. Temporary fix the issue by setting direct
      Linux CPU id <-> Xen vCPU id mapping for all possible CPUs at boot. We
      don't currently support kexec/kdump on Xen/ARM so these ids always
      match.
      
      In future, we have several ways to solve the issue, e.g.:
      
      - Eliminate all hypercalls from CPU_UP_PREPARE, do them from the
        starting CPU. This can probably be done for both x86 and ARM and, if
        done, will allow us to get Xen's idea of vCPU id from CPUID/MPIDR on
        the starting CPU directly, no messing with ACPI/device tree
        required.
      
      - Save vCPU id information from ACPI/device tree on ARM and use it to
        initialize xen_vcpu_id mapping. This is the same trick we currently
        do on x86.
      Reported-by: default avatarJulien Grall <julien.grall@arm.com>
      Tested-by: default avatarWei Chen <Wei.Chen@arm.com>
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Acked-by: default avatarStefano Stabellini <sstabellini@kernel.org>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      de75abbe
  3. 13 Sep, 2016 29 commits