linux-stable.git/arch, branch linux-3.4.y

parisc: Fix syscall restarts

2016-10-26T15:15:41+00:00

commit 71a71fb5374a23be36a91981b5614590b9e722c3 upstream.

On parisc syscalls which are interrupted by signals sometimes failed to
restart and instead returned -ENOSYS which in the worst case lead to
userspace crashes.
A similiar problem existed on MIPS and was fixed by commit e967ef02
("MIPS: Fix restart of indirect syscalls").

On parisc the current syscall restart code assumes that all syscall
callers load the syscall number in the delay slot of the ble
instruction. That's how it is e.g. done in the unistd.h header file:
	ble 0x100(%sr2, %r0)
	ldi #syscall_nr, %r20
Because of that assumption the current code never restored %r20 before
returning to userspace.

This assumption is at least not true for code which uses the glibc
syscall() function, which instead uses this syntax:
	ble 0x100(%sr2, %r0)
	copy regX, %r20
where regX depend on how the compiler optimizes the code and register
usage.

This patch fixes this problem by adding code to analyze how the syscall
number is loaded in the delay branch and - if needed - copy the syscall
number to regX prior returning to userspace for the syscall restart.

Signed-off-by: Helge Deller 
Cc: Mathieu Desnoyers 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

ARM: 8471/1: need to save/restore arm register(r11) when it is corrupted

2016-10-26T15:15:38+00:00

commit fa0708b320f6da4c1104fe56e01b7abf66fd16ad upstream.

In cpu_v7_do_suspend routine, r11 is used while it is NOT
saved/restored, different compiler may have different usage
of ARM general registers, so it may cause issues during
calling cpu_v7_do_suspend.

We meet kernel fault occurs when using GCC 4.8.3, r11 contains
valid value before calling into cpu_v7_do_suspend, but when returned
from this routine, r11 is corrupted and lead to kernel fault.
Doing save/restore for those corrupted registers is a must in
assemble code.

Signed-off-by: Anson Huang 
Reviewed-by: Nicolas Pitre 
Signed-off-by: Russell King 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

x86/signal: Fix restart_syscall number for x32 tasks

2016-10-26T15:15:33+00:00

commit 22eab1108781eff09961ae7001704f7bd8fb1dce upstream.

When restarting a syscall with regs->ax == -ERESTART_RESTARTBLOCK,
regs->ax is assigned to a restart_syscall number.  For x32 tasks, this
syscall number must have __X32_SYSCALL_BIT set, otherwise it will be
an x86_64 syscall number instead of a valid x32 syscall number. This
issue has been there since the introduction of x32.

Reported-by: strace/tests/restart_syscall.test
Reported-and-tested-by: Elvira Khabirova 
Signed-off-by: Dmitry V. Levin 
Cc: Elvira Khabirova 
Link: http://lkml.kernel.org/r/20151130215436.GA25996@altlinux.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Zefan Li

x86/cpu: Call verify_cpu() after having entered long mode too

2016-10-26T15:15:27+00:00

commit 04633df0c43d710e5f696b06539c100898678235 upstream.

When we get loaded by a 64-bit bootloader, kernel entry point is
startup_64 in head_64.S. We don't trust any and all bootloaders because
some will fiddle with CPU configuration so we go ahead and massage each
CPU into sanity again.

For example, some dell BIOSes have this XD disable feature which set
IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround
for other OSes but Linux sure doesn't need it.

A similar thing is present in the Surface 3 firmware - see
https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit
only on the BSP:

  # rdmsr -a 0x1a0
  400850089
  850089
  850089
  850089

I know, right?!

There's not even an off switch in there.

So fix all those cases by sanitizing the 64-bit entry point too. For
that, make verify_cpu() callable in 64-bit mode also.

Requested-and-debugged-by: "H. Peter Anvin" 
Reported-and-tested-by: Bastien Nocera 
Signed-off-by: Borislav Petkov 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.de
Signed-off-by: Thomas Gleixner 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

MIPS: atomic: Fix comment describing atomic64_add_unless's return value.

2016-10-26T15:15:23+00:00

commit f25319d2cb439249a6859f53ad42ffa332b0acba upstream.

Signed-off-by: Ralf Baechle 
Fixes: f24219b4e90cf70ec4a211b17fbabc725a0ddf3c
(cherry picked from commit f0a232cde7be18a207fd057dd79bbac8a0a45dec)
Signed-off-by: Zefan Li

ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode

2016-10-26T15:15:23+00:00

commit 54c09889bff6d99c8733eed4a26c9391b177c88b upstream.

The z2 machine calls pxa27x_set_pwrmode() in order to power off
the machine, but this function gets discarded early at boot because
it is marked __init, as pointed out by kbuild:

WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the function z2_power_off() to the function .init.text:pxa27x_set_pwrmode()
The function z2_power_off() references
the function __init pxa27x_set_pwrmode().
This is often because z2_power_off lacks a __init
annotation or the annotation of pxa27x_set_pwrmode is wrong.

This removes the __init section modifier to fix rebooting and the
build error.

Signed-off-by: Arnd Bergmann 
Fixes: ba4a90a6d86a ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available")
Signed-off-by: Robert Jarzmik 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

x86/iopl/64: Properly context-switch IOPL on Xen PV

2016-04-27T10:55:30+00:00

commit b7a584598aea7ca73140cb87b40319944dd3393f upstream.

On Xen PV, regs->flags doesn't reliably reflect IOPL and the
exit-to-userspace code doesn't change IOPL.  We need to context
switch it manually.

I'm doing this without going through paravirt because this is
specific to Xen PV.  After the dust settles, we can merge this with
the 32-bit code, tidy up the iopl syscall implementation, and remove
the set_iopl pvop entirely.

Fixes XSA-171.

Reviewewd-by: Jan Beulich 
Signed-off-by: Andy Lutomirski 
Cc: Andrew Cooper 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
[ kamal: backport to 3.19-stable: no X86_FEATURE_XENPV so just call
  xen_pv_domain() directly ]
Acked-by: Andy Lutomirski  kernel.org>
Signed-off-by: Kamal Mostafa  canonical.com>
Signed-off-by: Zefan Li

x86/process: Add proper bound checks in 64bit get_wchan()

2016-04-27T10:55:25+00:00

commit eddd3826a1a0190e5235703d1e666affa4d13b96 upstream.

Dmitry Vyukov reported the following using trinity and the memory
error detector AddressSanitizer
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).

[ 124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on
address ffff88002e280000
[ 124.576801] ffff88002e280000 is located 131938492886538 bytes to
the left of 28857600-byte region [ffffffff81282e0a, ffffffff82e0830a)
[ 124.578633] Accessed by thread T10915:
[ 124.579295] inlined in describe_heap_address
./arch/x86/mm/asan/report.c:164
[ 124.579295] #0 ffffffff810dd277 in asan_report_error
./arch/x86/mm/asan/report.c:278
[ 124.580137] #1 ffffffff810dc6a0 in asan_check_region
./arch/x86/mm/asan/asan.c:37
[ 124.581050] #2 ffffffff810dd423 in __tsan_read8 ??:0
[ 124.581893] #3 ffffffff8107c093 in get_wchan
./arch/x86/kernel/process_64.c:444

The address checks in the 64bit implementation of get_wchan() are
wrong in several ways:

 - The lower bound of the stack is not the start of the stack
   page. It's the start of the stack page plus sizeof (struct
   thread_info)

 - The upper bound must be:

       top_of_stack - TOP_OF_KERNEL_STACK_PADDING - 2 * sizeof(unsigned long).

   The 2 * sizeof(unsigned long) is required because the stack pointer
   points at the frame pointer. The layout on the stack is: ... IP FP
   ... IP FP. So we need to make sure that both IP and FP are in the
   bounds.

Fix the bound checks and get rid of the mix of numeric constants, u64
and unsigned long. Making all unsigned long allows us to use the same
function for 32bit as well.

Use READ_ONCE() when accessing the stack. This does not prevent a
concurrent wakeup of the task and the stack changing, but at least it
avoids TOCTOU.

Also check task state at the end of the loop. Again that does not
prevent concurrent changes, but it avoids walking for nothing.

Add proper comments while at it.

Reported-by: Dmitry Vyukov 
Reported-by: Sasha Levin 
Based-on-patch-from: Wolfram Gloger 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Reviewed-by: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Andrey Konovalov 
Cc: Kostya Serebryany 
Cc: Alexander Potapenko 
Cc: kasan-dev 
Cc: Denys Vlasenko 
Cc: Andi Kleen 
Cc: Wolfram Gloger 
Link: http://lkml.kernel.org/r/20150930083302.694788319@linutronix.de
Signed-off-by: Thomas Gleixner 
[lizf: Backported to 3.4:
 - s/READ_ONCE/ACCESS_ONCE
 - remove TOP_OF_KERNEL_STACK_PADDING]
Signed-off-by: Zefan Li

x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map

2016-04-27T10:55:24+00:00

commit 64c98e7f49100b637cd20a6c63508caed6bbba7a upstream.

Sanitizing the e820 map may produce extra E820 entries which would result in
the topmost E820 entries being removed. The removed entries would typically
include the top E820 usable RAM region and thus result in the domain having
signicantly less RAM available to it.

Fix by allowing sanitize_e820_map to use the full size of the allocated E820
array.

Signed-off-by: Malcolm Crossley 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
[lizf: Backported to 3.4: s/map/xen_e820_map]
Signed-off-by: Zefan Li

m68k: Define asmlinkage_protect

2016-04-27T10:55:24+00:00

commit 8474ba74193d302e8340dddd1e16c85cc4b98caf upstream.

Make sure the compiler does not modify arguments of syscall functions.
This can happen if the compiler generates a tailcall to another
function.  For example, without asmlinkage_protect sys_openat is compiled
into this function:

sys_openat:
	clr.l %d0
	move.w 18(%sp),%d0
	move.l %d0,16(%sp)
	jbra do_sys_open

Note how the fourth argument is modified in place, modifying the register
%d4 that gets restored from this stack slot when the function returns to
user-space.  The caller may expect the register to be unmodified across
system calls.

Signed-off-by: Andreas Schwab 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Zefan Li