1. 27 Apr, 2015 3 commits
  2. 26 Apr, 2015 1 commit
    • Andy Lutomirski's avatar
      x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue · 61f01dd9
      Andy Lutomirski authored
      AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET with
      SS == 0 results in an invalid usermode state in which SS is apparently
      equal to __USER_DS but causes #SS if used.
      
      Work around the issue by setting SS to __KERNEL_DS __switch_to, thus
      ensuring that SYSRET never happens with SS set to NULL.
      
      This was exposed by a recent vDSO cleanup.
      
      Fixes: e7d6eefa
      
       x86/vdso32/syscall.S: Do not load __USER32_DS to %ss
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <vda.linux@googlemail.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      61f01dd9
  3. 24 Apr, 2015 4 commits
    • Linus Torvalds's avatar
      x86: fix special __probe_kernel_write() tail zeroing case · d869844b
      Linus Torvalds authored
      Commit cae2a173
      
       ("x86: clean up/fix 'copy_in_user()' tail zeroing")
      fixed the failure case tail zeroing of one special case of the x86-64
      generic user-copy routine, namely when used for the user-to-user case
      ("copy_in_user()").
      
      But in the process it broke an even more unusual case: using the user
      copy routine for kernel-to-kernel copying.
      
      Now, normally kernel-kernel copies are obviously done using memcpy(),
      but we have a couple of special cases when we use the user-copy
      functions.  One is when we pass a kernel buffer to a regular user-buffer
      routine, using set_fs(KERNEL_DS).  That's a "normal" case, and continued
      to work fine, because it never takes any faults (with the possible
      exception of a silent and successful vmalloc fault).
      
      But Jan Beulich pointed out another, very unusual, special case: when we
      use the user-copy routines not because it's a path that expects a user
      pointer, but for a couple of ftrace/kgdb cases that want to do a kernel
      copy, but do so using "unsafe" buffers, and use the user-copy routine to
      gracefully handle faults.  IOW, for probe_kernel_write().
      
      And that broke for the case of a faulting kernel destination, because we
      saw the kernel destination and wanted to try to clear the tail of the
      buffer.  Which doesn't work, since that's what faults.
      
      This only triggers for things like kgdb and ftrace users (eg trying
      setting a breakpoint on read-only memory), but it's definitely a bug.
      The fix is to not compare against the kernel address start (TASK_SIZE),
      but instead use the same limits "access_ok()" uses.
      Reported-and-tested-by: default avatarJan Beulich <jbeulich@suse.com>
      Cc: stable@vger.kernel.org # 4.0
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d869844b
    • Ard Biesheuvel's avatar
      crypto: x86/sha512_ssse3 - fixup for asm function prototype change · 00425bb1
      Ard Biesheuvel authored
      Patch e68410eb ("crypto: x86/sha512_ssse3 - move SHA-384/512
      SSSE3 implementation to base layer") changed the prototypes of the
      core asm SHA-512 implementations so that they are compatible with
      the prototype used by the base layer.
      
      However, in one instance, the register that was used for passing the
      input buffer was reused as a scratch register later on in the code,
      and since the input buffer param changed places with the digest param
      -which needs to be written back before the function returns- this
      resulted in the scratch register to be dereferenced in a memory write
      operation, causing a GPF.
      
      Fix this by changing the scratch register to use the same register as
      the input buffer param again.
      
      Fixes: e68410eb
      
       ("crypto: x86/sha512_ssse3 - move SHA-384/512 SSSE3 implementation to base layer")
      Reported-By: default avatarBobby Powers <bobbypowers@gmail.com>
      Tested-By: default avatarBobby Powers <bobbypowers@gmail.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      00425bb1
    • Ley Foon Tan's avatar
      nios2: rework cache · 1a70db49
      Ley Foon Tan authored
      
      
      - flush dcache before flush instruction cache
      - remork update_mmu_cache and flush_dcache_page
      - add shmparam.h
      Signed-off-by: default avatarLey Foon Tan <lftan@altera.com>
      1a70db49
    • Ezequiel Garcia's avatar
      nios2: Add types.h header required for __u32 type · 2009337e
      Ezequiel Garcia authored
      
      
      Reported by the header checker (CONFIG_HEADERS_CHECK=y):
      
        CHECK   usr/include/asm/ (31 files)
      ./usr/include/asm/ptrace.h:77: found __[us]{8,16,32,64} type without #include <linux/types.h>
      Signed-off-by: default avatarEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Acked-by: default avatarLey Foon Tan <lftan@altera.com>
      2009337e
  4. 23 Apr, 2015 17 commits
  5. 22 Apr, 2015 4 commits
    • Guenter Roeck's avatar
      frv: add io{read,write}{16,32}be functions · 04fca0e3
      Guenter Roeck authored
      
      
      These functions are used in various drivers, including the latest
      version of the 8250 driver. The latter causes the following build
      failure.
      
      drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_out':
      drivers/tty/serial/8250/8250_core.c:456:2: error:
      			implicit declaration of function 'iowrite32be'
      drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_in':
      drivers/tty/serial/8250/8250_core.c:462:2: error:
      			implicit declaration of function 'ioread32be'
      
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Fixes: c627f2ce
      
       ("serial: 8250: Add support for big-endian MMIO
      	accesses")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      04fca0e3
    • Guenter Roeck's avatar
      mn10300: add io{read,write}{16,32}be functions · 601e3ad9
      Guenter Roeck authored
      
      
      These functions are used in various drivers, including the latest
      version of the 8250 driver. The latter causes the following build failure.
      
      drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_out':
      drivers/tty/serial/8250/8250_core.c:456:2: error:
      			implicit declaration of function 'iowrite32be'
      drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_in':
      drivers/tty/serial/8250/8250_core.c:462:2: error:
      			implicit declaration of function 'ioread32be'
      
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Fixes: c627f2ce
      
       ("serial: 8250: Add support for big-endian MMIO
      	accesses")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      601e3ad9
    • Andre Przywara's avatar
      KVM: arm/arm64: check IRQ number on userland injection · fd1d0ddf
      Andre Przywara authored
      
      
      When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently
      only check it against a fixed limit, which historically is set
      to 127. With the new dynamic IRQ allocation the effective limit may
      actually be smaller (64).
      So when now a malicious or buggy userland injects a SPI in that
      range, we spill over on our VGIC bitmaps and bytemaps memory.
      I could trigger a host kernel NULL pointer dereference with current
      mainline by injecting some bogus IRQ number from a hacked kvmtool:
      -----------------
      ....
      DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1)
      DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1)
      DEBUG: IRQ #114 still in the game, writing to bytemap now...
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = ffffffc07652e000
      [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000
      Internal error: Oops: 96000006 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027
      Hardware name: FVP Base (DT)
      task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000
      PC is at kvm_vgic_inject_irq+0x234/0x310
      LR is at kvm_vgic_inject_irq+0x30c/0x310
      pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145
      .....
      
      So this patch fixes this by checking the SPI number against the
      actual limit. Also we remove the former legacy hard limit of
      127 in the ioctl code.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18
      [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__,
      as suggested by Christopher Covington]
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      fd1d0ddf
    • Mathieu Olivari's avatar
      ARM: qcom: add description of KPSS WDT for IPQ8064 · 4ba1c98b
      Mathieu Olivari authored
      
      
      Add the watchdog related entries to the Krait Processor Sub-system
      (KPSS) timer IPQ8064 devicetree section. Also, add a fixed-clock
      description of SLEEP_CLK, which will do for now.
      Signed-off-by: default avatarJosh Cartwright <joshc@codeaurora.org>
      Signed-off-by: default avatarMathieu Olivari <mathieu@codeaurora.org>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Acked-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWim Van Sebroeck <wim@iguana.be>
      4ba1c98b
  6. 21 Apr, 2015 11 commits