linux.git/arch, branch v3.10.89

xtensa: don't use echo -e needlessly

2015-09-21T17:00:10+00:00

commit 123f15e669d5a5a2e2f260ba4a5fc2efd93df20e upstream.

-e is not needed to output strings without escape sequences. This breaks
big endian FSF build when the shell is dash, because its builtin echo
doesn't understand '-e' switch and outputs it in the echoed string.

Reported-by: Guenter Roeck 
Signed-off-by: Max Filippov 
Signed-off-by: Chris Zankel 
Cc: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

xtensa: fix kernel register spilling

2015-09-21T17:00:09+00:00

commit 77d6273e79e3a86552fcf10cdd31a69b46ed2ce6 upstream.

call12 can't be safely used as the first call in the inline function,
because the compiler does not extend the stack frame of the bounding
function accordingly, which may result in corruption of local variables.

If a call needs to be done, do call8 first followed by call12.

For pure assembly code in _switch_to increase stack frame size of the
bounding function.

Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

xtensa: fix threadptr reload on return to userspace

2015-09-21T17:00:08+00:00

commit 4229fb12a03e5da5882b420b0aa4a02e77447b86 upstream.

Userspace return code may skip restoring THREADPTR register if there are
no registers that need to be zeroed. This leads to spurious failures in
libc NPTL tests.

Always restore THREADPTR on return to userspace.

Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

crypto: ghash-clmulni: specify context size for ghash async algorithm

2015-09-21T17:00:08+00:00

commit 71c6da846be478a61556717ef1ee1cea91f5d6a8 upstream.

Currently context size (cra_ctxsize) doesn't specified for
ghash_async_alg. Which means it's zero. Thus crypto_create_tfm()
doesn't allocate needed space for ghash_async_ctx, so any
read/write to ctx (e.g. in ghash_async_init_tfm()) is not valid.

Signed-off-by: Andrey Ryabinin 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

arm64/mm: Remove hack in mmap randomize layout

2015-09-13T16:07:59+00:00

commit d6c763afab142a85e4770b4bc2a5f40f256d5c5d upstream.

Since commit 8a0a9bd4db63 ('random: make get_random_int() more
random'), get_random_int() returns a random value for each call,
so comment and hack introduced in mmap_rnd() as part of commit
1d18c47c735e ('arm64: MMU fault handling and page table management')
are incorrects.

Commit 1d18c47c735e seems to use the same hack introduced by
commit a5adc91a4b44 ('powerpc: Ensure random space between stack
and mmaps'), latter copied in commit 5a0efea09f42 ('sparc64: Sharpen
address space randomization calculations.').

But both architectures were cleaned up as part of commit
fa8cbaaf5a68 ('powerpc+sparc64/mm: Remove hack in mmap randomize
layout') as hack is no more needed since commit 8a0a9bd4db63.

So the present patch removes the comment and the hack around
get_random_int() on AArch64's mmap_rnd().

Cc: David S. Miller 
Cc: Anton Blanchard 
Cc: Benjamin Herrenschmidt 
Acked-by: Will Deacon 
Acked-by: Dan McGee 
Signed-off-by: Yann Droneaud 
Signed-off-by: Will Deacon 
Cc: Matthias Brugger 
Signed-off-by: Greg Kroah-Hartman

kvm: x86: fix kvm_apic_has_events to check for NULL pointer

2015-08-17T03:51:43+00:00

commit ce40cd3fc7fa40a6119e5fe6c0f2bc0eb4541009 upstream.

Malicious (or egregiously buggy) userspace can trigger it, but it
should never happen in normal operation.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Wang Kai 
Signed-off-by: Greg Kroah-Hartman

signal: fix information leak in copy_siginfo_from_user32

2015-08-17T03:51:42+00:00

commit 3c00cb5e68dc719f2fc73a33b1b230aadfcb1309 upstream.

This function can leak kernel stack data when the user siginfo_t has a
positive si_code value.  The top 16 bits of si_code descibe which fields
in the siginfo_t union are active, but they are treated inconsistently
between copy_siginfo_from_user32, copy_siginfo_to_user32 and
copy_siginfo_to_user.

copy_siginfo_from_user32 is called from rt_sigqueueinfo and
rt_tgsigqueueinfo in which the user has full control overthe top 16 bits
of si_code.

This fixes the following information leaks:
x86:   8 bytes leaked when sending a signal from a 32-bit process to
       itself. This leak grows to 16 bytes if the process uses x32.
       (si_code = __SI_CHLD)
x86:   100 bytes leaked when sending a signal from a 32-bit process to
       a 64-bit process. (si_code = -1)
sparc: 4 bytes leaked when sending a signal from a 32-bit process to a
       64-bit process. (si_code = any)

parsic and s390 have similar bugs, but they are not vulnerable because
rt_[tg]sigqueueinfo have checks that prevent sending a positive si_code
to a different process.  These bugs are also fixed for consistency.

Signed-off-by: Amanieu d'Antras 
Cc: Oleg Nesterov 
Cc: Ingo Molnar 
Cc: Russell King 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Chris Metcalf 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

signal: fix information leak in copy_siginfo_to_user

2015-08-17T03:51:42+00:00

commit 26135022f85105ad725cda103fa069e29e83bd16 upstream.

This function may copy the si_addr_lsb, si_lower and si_upper fields to
user mode when they haven't been initialized, which can leak kernel
stack data to user mode.

Just checking the value of si_code is insufficient because the same
si_code value is shared between multiple signals.  This is solved by
checking the value of si_signo in addition to si_code.

Signed-off-by: Amanieu d'Antras 
Cc: Oleg Nesterov 
Cc: Ingo Molnar 
Cc: Russell King 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARM: 7819/1: fiq: Cast the first argument of flush_icache_range()

2015-08-17T03:51:42+00:00

commit 7cb3be0a27805c625ff7cce20c53c926d9483243 upstream.

Commit 2ba85e7af4 (ARM: Fix FIQ code on VIVT CPUs) causes the following build warning:

arch/arm/kernel/fiq.c:92:3: warning: passing argument 1 of 'cpu_cache.coherent_kern_range' makes integer from pointer without a cast [enabled by default]

Cast it as '(unsigned long)base' to avoid the warning.

Signed-off-by: Fabio Estevam 
Signed-off-by: Russell King 
Cc: Martin Kaiser 
Signed-off-by: Greg Kroah-Hartman

ARM: Fix FIQ code on VIVT CPUs

2015-08-17T03:51:41+00:00

commit 2ba85e7af4c639d933c9a87a6d7363f2983d5ada upstream.

Aaro Koskinen reports the following oops:
Installing fiq handler from c001b110, length 0x164
Unable to handle kernel paging request at virtual address ffff1224
pgd = c0004000
[ffff1224] *pgd=00000000, *pte=11fff0cb, *ppte=11fff00a
...
[] (set_fiq_handler+0x0/0x6c) from [] (ams_delta_init_fiq+0xa8/0x160)
 r6:00000164 r5:c001b110 r4:00000000 r3:fefecb4c
[] (ams_delta_init_fiq+0x0/0x160) from [] (ams_delta_init+0xd4/0x114)
 r6:00000000 r5:fffece10 r4:c037a9e0
[] (ams_delta_init+0x0/0x114) from [] (customize_machine+0x24/0x30)

This is because the vectors page is now write-protected, and to change
code in there we must write to its original alias.  Make that change,
and adjust the cache flushing such that the code will become visible
to the instruction stream on VIVT CPUs.

Reported-by: Aaro Koskinen 
Tested-by: Aaro Koskinen 
Signed-off-by: Russell King 
Cc: Martin Kaiser 
Signed-off-by: Greg Kroah-Hartman