linux-stable.git/arch/arm, branch v3.14.76

arm: oabi compat: add missing access checks

2016-08-16T07:29:02+00:00

commit 7de249964f5578e67b99699c5f0b405738d820a2 upstream.

Add access checks to sys_oabi_epoll_wait() and sys_oabi_semtimedop().
This fixes CVE-2016-3857, a local privilege escalation under
CONFIG_OABI_COMPAT.

Reported-by: Chiachih Wu 
Reviewed-by: Kees Cook 
Reviewed-by: Nicolas Pitre 
Signed-off-by: Dave Weinstein 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARM: 8578/1: mm: ensure pmd_present only checks the valid bit

2016-07-27T16:55:49+00:00

commit 624531886987f0f1b5d01fb598034d039198e090 upstream.

In a subsequent patch, pmd_mknotpresent will clear the valid bit of the
pmd entry, resulting in a not-present entry from the hardware's
perspective. Unfortunately, pmd_present simply checks for a non-zero pmd
value and will therefore continue to return true even after a
pmd_mknotpresent operation. Since pmd_mknotpresent is only used for
managing huge entries, this is only an issue for the 3-level case.

This patch fixes the 3-level pmd_present implementation to take into
account the valid bit. For bisectability, the change is made before the
fix to pmd_mknotpresent.

[catalin.marinas@arm.com: comment update regarding pmd_mknotpresent patch]

Fixes: 8d9625070073 ("ARM: mm: Transparent huge page support for LPAE systems.")
Cc: Russell King 
Cc: Steve Capper 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: fix PTRACE_SETVFPREGS on SMP systems

2016-06-24T17:15:28+00:00

commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf upstream.

PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
reloaded, because it undoes one of the effects of vfp_flush_hwstate().

Specifically vfp_flush_hwstate() sets thread->vfpstate.hard.cpu to
an invalid CPU number, but vfp_set() overwrites this with the original
CPU number, thereby rendering the hardware state as apparently "valid",
even though the software state is more recent.

Fix this by reverting the previous change.

Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
Acked-by: Will Deacon 
Tested-by: Simon Marchi 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables

2016-06-01T19:12:46+00:00

commit d4b9e0790aa764c0b01e18d4e8d33e93ba36d51f upstream.

The ARM architecture mandates that when changing a page table entry
from a valid entry to another valid entry, an invalid entry is first
written, TLB invalidated, and only then the new entry being written.

The current code doesn't respect this, directly writing the new
entry and only then invalidating TLBs. Let's fix it up.

Reported-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP3: Fix booting with thumb2 kernel

2016-05-19T00:04:00+00:00

commit d8a50941c91a68da202aaa96a3dacd471ea9c693 upstream.

We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:

Internal error: Oops: 80000005 [#1] SMP THUMB2
...
[] (_raw_spin_unlock_irqrestore) from []
(omap3_enter_idle_bm+0xc5/0x178)
[] (omap3_enter_idle_bm) from []
(cpuidle_enter_state+0x77/0x27c)
[] (cpuidle_enter_state) from []
(cpu_startup_entry+0x155/0x23c)
[] (cpu_startup_entry) from []
(start_kernel+0x32f/0x338)
[] (start_kernel) from [<8000807f>] (0x8000807f)

The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.

Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd . Let's fix the
problem by adding ENDPROC in two places to sleep34xx.S.

Let's also remove the now duplicate custom code for mode switching.
This has been unnecessary since commit 6ebbf2ce437b ("ARM: convert
all "mov.* pc, reg" to "bx reg" for ARMv6+").

And let's also remove the comments about local variables, they are
now just confusing after the ENDPROC.

The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:

https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

Reported-by: Kevin Hilman 
Tested-by: Kevin Hilman 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel

2016-05-11T09:21:00+00:00

commit 5616f36713ea77f57ae908bf2fef641364403c9f upstream.

The secondary CPU starts up in ARM mode. When the kernel is compiled in
thumb2 mode we have to explicitly compile the secondary startup
trampoline in ARM mode, otherwise the CPU will go to Nirvana.

Signed-off-by: Sascha Hauer 
Reported-by: Steffen Trumtrar 
Suggested-by: Ard Biesheuvel 
Signed-off-by: Dinh Nguyen 
Signed-off-by: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP3: Add cpuidle parameters table for omap3430

2016-05-04T21:51:26+00:00

commit 98f42221501353067251fbf11e732707dbb68ce3 upstream.

Based on CPU type choose generic omap3 or omap3430 specific cpuidle
parameters. Parameters for omap3430 were measured on Nokia N900 device and
added by commit 5a1b1d3a9efa ("OMAP3: RX-51: Pass cpu idle parameters")
which were later removed by commit 231900afba52 ("ARM: OMAP3: cpuidle -
remove rx51 cpuidle parameters table") due to huge code complexity.

This patch brings cpuidle parameters for omap3430 devices again, but uses
simple condition based on CPU type.

Fixes: 231900afba52 ("ARM: OMAP3: cpuidle - remove rx51 cpuidle
parameters table")
Signed-off-by: Pali Rohár 
Acked-by: Daniel Lezcano 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP2+: hwmod: Fix updating of sysconfig register

2016-05-04T21:51:23+00:00

commit 3ca4a238106dedc285193ee47f494a6584b6fd2f upstream.

Commit 127500ccb766f ("ARM: OMAP2+: Only write the sysconfig on idle
when necessary") talks about verification of sysconfig cache value before
updating it, only during idle path. But the patch is adding the
verification in the enable path. So, adding the check in a proper place
as per the commit description.

Not keeping this check during enable path as there is a chance of losing
context and it is safe to do on idle as the context of the register will
never be lost while the device is active.

Signed-off-by: Lokesh Vutla 
Acked-by: Tero Kristo 
Cc: Jon Hunter 
Fixes: commit 127500ccb766 "ARM: OMAP2+: Only write the sysconfig on idle when necessary"
[paul@pwsan.com: appears to have been caused by my own mismerge of the
 originally posted patch]
Signed-off-by: Paul Walmsley 
Signed-off-by: Greg Kroah-Hartman

dts: vt8500: Add SDHC node to DTS file for WM8650

2016-03-03T23:06:48+00:00

commit 0f090bf14e51e7eefb71d9d1c545807f8b627986 upstream.

Since WM8650 has the same 'WMT' SDHC controller as WM8505, and the driver
is already in the kernel, this node enables the controller support for
WM8650

Signed-off-by: Roman Volkov 
Reviewed-by: Alexey Charkov 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

ARM: 8517/1: ICST: avoid arithmetic overflow in icst_hz()

2016-02-25T19:58:54+00:00

commit 5070fb14a0154f075c8b418e5bc58a620ae85a45 upstream.

When trying to set the ICST 307 clock to 25174000 Hz I ran into
this arithmetic error: the icst_hz_to_vco() correctly figure out
DIVIDE=2, RDW=100 and VDW=99 yielding a frequency of
25174000 Hz out of the VCO. (I replicated the icst_hz() function
in a spreadsheet to verify this.)

However, when I called icst_hz() on these VCO settings it would
instead return 4122709 Hz. This causes an error in the common
clock driver for ICST as the common clock framework will call
.round_rate() on the clock which will utilize icst_hz_to_vco()
followed by icst_hz() suggesting the erroneous frequency, and
then the clock gets set to this.

The error did not manifest in the old clock framework since
this high frequency was only used by the CLCD, which calls
clk_set_rate() without first calling clk_round_rate() and since
the old clock framework would not call clk_round_rate() before
setting the frequency, the correct values propagated into
the VCO.

After some experimenting I figured out that it was due to a simple
arithmetic overflow: the divisor for 24Mhz reference frequency
as reference becomes 24000000*2*(99+8)=0x132212400 and the "1"
in bit 32 overflows and is lost.

But introducing an explicit 64-by-32 bit do_div() and casting
the divisor into (u64) we get the right frequency back, and the
right frequency gets set.

Tested on the ARM Versatile.

Cc: linux-clk@vger.kernel.org
Cc: Pawel Moll 
Signed-off-by: Linus Walleij 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman