linux-stable.git/arch/mips/kernel, branch v3.18.46

KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace

2016-08-22T16:23:21+00:00

[ Upstream commit 20f06ed9f61a185c6dabd662c310bed6189470df ]

MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
calling sys_keyctl.  The latter will work in a lot of cases, thereby hiding
the issue.

Reported-by: Stephan Mueller 
Signed-off-by: David Howells 
cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: keyrings@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13832/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

Revert "MIPS: Reserve nosave data for hibernation"

2016-08-01T15:16:01+00:00

This reverts commit 1dd0964204277108e3e06e7df4c1f06a79d55093.

Signed-off-by: Sasha Levin

MIPS: Reserve nosave data for hibernation

2016-07-12T12:48:19+00:00

[ Upstream commit a95d069204e178f18476f5499abab0d0d9cbc32c ]

After commit 92923ca3aacef63c92d ("mm: meminit: only set page reserved
in the memblock region"), the MIPS hibernation is broken. Because pages
in nosave data section should be "reserved", but currently they aren't
set to "reserved" at initialization. This patch makes hibernation work
again.

Signed-off-by: Huacai Chen 
Cc: Aurelien Jarno 
Cc: Steven J . Hill 
Cc: Fuxin Zhang 
Cc: Zhangjin Wu 
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12888/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC

2016-06-06T23:11:06+00:00

[ Upstream commit e49d38488515057dba8f0c2ba4cfde5be4a7281f ]

Fix a build regression from commit c9017757c532 ("MIPS: init upper 64b
of vector registers when MSA is first used"):

arch/mips/built-in.o: In function `enable_restore_fp_context':
traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'

to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are
unable to figure out that calls to `_init_msa_upper' are indeed dead.
Of the many ways to tackle this failure choose the approach we have
already taken in `thread_msa_context_live'.

[ralf@linux-mips.org: Drop patch segment to junk file.]

Signed-off-by: Maciej W. Rozycki 
Cc: stable@vger.kernel.org # v3.16+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13271/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

MIPS: Avoid using unwind_stack() with usermode

2016-06-03T15:30:38+00:00

[ Upstream commit 81a76d7119f63c359750e4adeff922a31ad1135f ]

When showing backtraces in response to traps, for example crashes and
address errors (usually unaligned accesses) when they are set in debugfs
to be reported, unwind_stack will be used if the PC was in the kernel
text address range. However since EVA it is possible for user and kernel
address ranges to overlap, and even without EVA userland can still
trigger an address error by jumping to a KSeg0 address.

Adjust the check to also ensure that it was running in kernel mode. I
don't believe any harm can come of this problem, since unwind_stack() is
sufficiently defensive, however it is only meant for unwinding kernel
code, so to be correct it should use the raw backtracing instead.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-mips@linux-mips.org
Cc:  # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/11701/
Signed-off-by: Ralf Baechle 
(cherry picked from commit d2941a975ac745c607dfb590e92bb30bc352dad9)
Signed-off-by: Sasha Levin

MIPS: Don't unwind to user mode with EVA

2016-06-03T15:30:37+00:00

[ Upstream commit a816b306c62195b7c43c92cb13330821a96bdc27 ]

When unwinding through IRQs and exceptions, the unwinding only continues
if the PC is a kernel text address, however since EVA it is possible for
user and kernel address ranges to overlap, potentially allowing
unwinding to continue to user mode if the user PC happens to be in the
kernel text address range.

Adjust the check to also ensure that the register state from before the
exception is actually running in kernel mode, i.e. !user_mode(regs).

I don't believe any harm can come of this problem, since the PC is only
output, the stack pointer is checked to ensure it resides within the
task's stack page before it is dereferenced in search of the return
address, and the return address register is similarly only output (if
the PC is in a leaf function or the beginning of a non-leaf function).

However unwind_stack() is only meant for unwinding kernel code, so to be
correct the unwind should stop there.

Signed-off-by: James Hogan 
Reviewed-by: Leonid Yegoshin 
Cc: linux-mips@linux-mips.org
Cc:  # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/11700/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

MIPS: traps: Fix SIGFPE information leak from `do_ov' and `do_trap_or_bp'

2016-03-13T17:53:41+00:00

[ Upstream commit e723e3f7f9591b79e8c56b3d7c5a204a9c571b55 ]

Avoid sending a partially initialised `siginfo_t' structure along SIGFPE
signals issued from `do_ov' and `do_trap_or_bp', leading to information
leaking from the kernel stack.

Signed-off-by: Maciej W. Rozycki 
Cc: stable@vger.kernel.org
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

MIPS: Fix seccomp syscall argument for MIPS64

2015-09-17T05:30:15+00:00

[ Upstream commit 9f161439e4104b641a7bfb9b89581d801159fec8 ]

Commit 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)")
fixed indirect system calls on O32 but it also introduced a bug for MIPS64
where it erroneously modified the v0 (syscall) register with the assumption
that the sycall offset hasn't been taken into consideration. This breaks
seccomp on MIPS64 n64 and n32 ABIs. We fix this by replacing the addition
with a move instruction.

Fixes: 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)")
Cc:  # 3.15+
Reviewed-by: James Hogan 
Signed-off-by: Markos Chandras 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10951/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin

signal: fix information leak in copy_siginfo_from_user32

2015-08-27T17:25:37+00:00

[ Upstream commit 3c00cb5e68dc719f2fc73a33b1b230aadfcb1309 ]

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: Sasha Levin

MIPS: show_stack: Fix stack trace with EVA

2015-08-19T17:14:54+00:00

[ Upstream commit 1e77863a51698c4319587df34171bd823691a66a ]

The show_stack() function deals exclusively with kernel contexts, but if
it gets called in user context with EVA enabled, show_stacktrace() will
attempt to access the stack using EVA accesses, which will either read
other user mapped data, or more likely cause an exception which will be
handled by __get_user().

This is easily reproduced using SysRq t to show all task states, which
results in the following stack dump output:

 Stack : (Bad stack address)

Fix by setting the current user access mode to kernel around the call to
show_stacktrace(). This causes __get_user() to use normal loads to read
the kernel stack.

Now we get the correct output, like this:

 Stack : 00000000 80168960 00000000 004a0000 00000000 00000000 8060016c 1f3abd0c
           1f172cd8 8056f09c 7ff1e450 8014fc3c 00000001 806dd0b0 0000001d 00000002
           1f17c6a0 1f17c804 1f17c6a0 8066f6e0 00000000 0000000a 00000000 00000000
           00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
           00000000 00000000 00000000 00000000 00000000 0110e800 1f3abd6c 1f17c6a0
           ...

Signed-off-by: James Hogan 
Cc: Markos Chandras 
Cc: Leonid Yegoshin 
Cc: linux-mips@linux-mips.org
Cc:  # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/10778/
Signed-off-by: Ralf Baechle 
Signed-off-by: Sasha Levin