Skip to content
  1. Jun 03, 2015
  3. Apr 27, 2015
  5. Apr 24, 2015
    • 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
    • Steven Miao's avatar
      eth: bf609 eth clock: add pclk clock for stmmac driver probe · d91e14b3
      Steven Miao authored 
      

Signed-off-by: default avatarSteven Miao <realmz6@gmail.com>
      d91e14b3
    • Chen Gang's avatar
      blackfin: Wire up missing syscalls · 4f650a59
      Chen Gang authored 
      

The related syscalls are below which may cause samples/kdbus building
break in next-20150401 tree, the related information and error:

    CALL    scripts/checksyscalls.sh
  <stdin>:1223:2: warning: #warning syscall kcmp not implemented [-Wcpp]
  <stdin>:1226:2: warning: #warning syscall finit_module not implemented [-Wcpp]
  <stdin>:1229:2: warning: #warning syscall sched_setattr not implemented [-Wcpp]
  <stdin>:1232:2: warning: #warning syscall sched_getattr not implemented [-Wcpp]
  <stdin>:1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp]
  <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp]
  <stdin>:1241:2: warning: #warning syscall getrandom not implemented [-Wcpp]
  <stdin>:1244:2: warning: #warning syscall memfd_create not implemented [-Wcpp]
  <stdin>:1247:2: warning: #warning syscall bpf not implemented [-Wcpp]
  <stdin>:1250:2: warning: #warning syscall execveat not implemented [-Wcpp]
  [...]
    HOSTCC  samples/kdbus/kdbus-workers
  samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
  samples/kdbus/kdbus-workers.c:930:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
    p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
                    ^
  samples/kdbus/kdbus-workers.c:930:18: note: each undeclared identifier is reported only once for each function it appears in

Signed-off-by: default avatarChen Gang <gang.chen.5i5j@gmail.com>
      4f650a59
  7. Apr 23, 2015
  9. Apr 22, 2015
    • 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
    • Bjorn Helgaas's avatar
      ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows · 9fbbda5c
      Bjorn Helgaas authored 
      Prior to c770cb4c ("PCI: Mark invalid BARs as unassigned"), if we tried
to claim a PCI BAR but could not find an upstream bridge window that
matched it, we complained but still allowed the device to be enabled.

c770cb4c broke devices that previously worked (mptsas and igb in the
case Tony reported, but it could be any devices) because it marks those
BARs as IORESOURCE_UNSET, which makes pci_enable_device() complain and
return failure:

  igb 0000:81:00.0: can't enable device: BAR 0 [mem size 0x00020000] not assigned
  igb: probe of 0000:81:00.0 failed with error -22

The underlying cause is an ACPI Address Space Descriptor for a PCI host
bridge window that is marked as "consumer".  This is a firmware defect:
resources that are produced on the downstream side of a bridge should be
marked "producer".  But rejecting these BARs that we previously allowed is
a functionality regression, and firmware has not used the producer/consumer
bit consistently, so we can't rely on it anyway.

Stop checking the producer/consumer bit, and assume all bridge Address
Space Descriptors are for bridge windows.

Note that this change does not affect I/O Port or Fixed Location I/O Port
Descriptors, which are commonly used for the [io 0x0cf8-0x0cff] config
access range.  That range is a "consumer" range and should not be treated
as a window.

Fixes: c770cb4c ("PCI: Mark invalid BARs as unassigned")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96961


Reported-and-tested-by: default avatarTony Luck <tony.luck@intel.com>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9fbbda5c
    • Sowmini Varadhan's avatar
      sparc: Use GFP_ATOMIC in ldc_alloc_exp_dring() as it can be called in softirq context · 0edfad59
      Sowmini Varadhan authored 
      

Since it is possible for vnet_event_napi to end up doing
vnet_control_pkt_engine -> ... -> vnet_send_attr ->
vnet_port_alloc_tx_ring -> ldc_alloc_exp_dring -> kzalloc()
(i.e., in softirq context), kzalloc() should be called with
GFP_ATOMIC from ldc_alloc_exp_dring.

Signed-off-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0edfad59
    • David S. Miller's avatar
      sparc64: Use M7 PMC write on all chips T4 and onward. · df386375
      David S. Miller authored 
      

They both work equally well, and the M7 implementation is
simpler and cheaper (less register writes).

With help from David Ahern.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df386375