linux-stable.git/arch/arm64, branch linux-4.1.y

arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage

2018-05-23T01:36:27+00:00

[ Upstream commit 5f16a046f8e144c294ef98cd29d9458b5f8273e5 ]

FUTEX_OP_OPARG_SHIFT instructs the futex code to treat the 12-bit oparg
field as a shift value, potentially leading to a left shift value that
is negative or with an absolute value that is significantly larger then
the size of the type. UBSAN chokes with:

================================================================================
UBSAN: Undefined behaviour in ./arch/arm64/include/asm/futex.h:60:13
shift exponent -1 is negative
CPU: 1 PID: 1449 Comm: syz-executor0 Not tainted 4.11.0-rc4-00005-g977eb52-dirty #11
Hardware name: linux,dummy-virt (DT)
Call trace:
[] dump_backtrace+0x0/0x538 arch/arm64/kernel/traps.c:73
[] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
[] __dump_stack lib/dump_stack.c:16 [inline]
[] dump_stack+0x120/0x188 lib/dump_stack.c:52
[] ubsan_epilogue+0x18/0x98 lib/ubsan.c:164
[] __ubsan_handle_shift_out_of_bounds+0x250/0x294 lib/ubsan.c:421
[] futex_atomic_op_inuser arch/arm64/include/asm/futex.h:60 [inline]
[] futex_wake_op kernel/futex.c:1489 [inline]
[] do_futex+0x137c/0x1740 kernel/futex.c:3231
[] SYSC_futex kernel/futex.c:3281 [inline]
[] SyS_futex+0x114/0x268 kernel/futex.c:3249
[] el0_svc_naked+0x24/0x28
================================================================================
syz-executor1 uses obsolete (PF_INET,SOCK_PACKET)
sock: process `syz-executor0' is using obsolete setsockopt SO_BSDCOMPAT

This patch attempts to fix some of this by:

  * Making encoded_op an unsigned type, so we can shift it left even if
    the top bit is set.

  * Casting to signed prior to shifting right when extracting oparg
    and cmparg

  * Consider only the bottom 5 bits of oparg when using it as a left-shift
    value.

Whilst I think this catches all of the issues, I'd much prefer to remove
this stuff, as I think it's unused and the bugs are copy-pasted between
a bunch of architectures.

Reviewed-by: Robin Murphy 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

arm64: KVM: Correctly handle zero register during MMIO

2018-03-21T03:49:54+00:00

[ Upstream commit bc45a516fa90b43b1898758d8b53b74c24b954e4 ]

On ARM64 register index of 31 corresponds to both zero register and SP.
However, all memory access instructions, use ZR as transfer register. SP
is used only as a base register in indirect memory addressing, or by
register-register arithmetics, which cannot be trapped here.

Correct emulation is achieved by introducing new register accessor
functions, which can do special handling for reg_num == 31. These new
accessors intentionally do not rely on old vcpu_reg() on ARM64, because
it is to be removed. Since the affected code is shared by both ARM
flavours, implementations of these accessors are also added to ARM32 code.

This patch fixes setting MMIO register to a random value (actually SP)
instead of zero by something like:

 *((volatile int *)reg) = 0;

compilers tend to generate "str wzr, [xx]" here

[Marc: Fixed 32bit splat]

Signed-off-by: Pavel Fedin 
Reviewed-by: Marc Zyngier 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin

arm64: Disable unhandled signal log messages by default

2018-03-04T15:28:34+00:00

[ Upstream commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 ]

aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:

sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G        W        4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000

Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.

Cc: 
Signed-off-by: Michael Weiser 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls

2018-03-01T03:09:39+00:00

[ Upstream commit acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd ]

KVM doesn't follow the SMCCC when it comes to unimplemented calls,
and inject an UNDEF instead of returning an error. Since firmware
calls are now used for security mitigation, they are becoming more
common, and the undef is counter productive.

Instead, let's follow the SMCCC which states that -1 must be returned
to the caller when getting an unknown function number.

Cc: 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Sasha Levin

arm64: Initialise high_memory global variable earlier

2018-03-01T00:32:12+00:00

[ Upstream commit f24e5834a2c3f6c5f814a417f858226f0a010ade ]

The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.

We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.

This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.

This patch moves the initialisation of high_memory before it used.

Cc: 
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

arm64: fpsimd: Prevent registers leaking from dead tasks

2018-01-17T17:55:24+00:00

[ Upstream commit 071b6d4a5d343046f253a5a8835d477d93992002 ]

Currently, loading of a task's fpsimd state into the CPU registers
is skipped if that task's state is already present in the registers
of that CPU.

However, the code relies on the struct fpsimd_state * (and by
extension struct task_struct *) to unambiguously identify a task.

There is a particular case in which this doesn't work reliably:
when a task exits, its task_struct may be recycled to describe a
new task.

Consider the following scenario:

 1) Task P loads its fpsimd state onto cpu C.
        per_cpu(fpsimd_last_state, C) := P;
        P->thread.fpsimd_state.cpu := C;

 2) Task X is scheduled onto C and loads its fpsimd state on C.
        per_cpu(fpsimd_last_state, C) := X;
        X->thread.fpsimd_state.cpu := C;

 3) X exits, causing X's task_struct to be freed.

 4) P forks a new child T, which obtains X's recycled task_struct.
	T == X.
	T->thread.fpsimd_state.cpu == C (inherited from P).

 5) T is scheduled on C.
	T's fpsimd state is not loaded, because
	per_cpu(fpsimd_last_state, C) == T (== X) &&
	T->thread.fpsimd_state.cpu == C.

        (This is the check performed by fpsimd_thread_switch().)

So, T gets X's registers because the last registers loaded onto C
were those of X, in (2).

This patch fixes the problem by ensuring that the sched-in check
fails in (5): fpsimd_flush_task_state(T) is called when T is
forked, so that T->thread.fpsimd_state.cpu == C cannot be true.
This relies on the fact that T is not schedulable until after
copy_thread() completes.

Once T's fpsimd state has been loaded on some CPU C there may still
be other cpus D for which per_cpu(fpsimd_last_state, D) ==
&X->thread.fpsimd_state.  But D is necessarily != C in this case,
and the check in (5) must fail.

An alternative fix would be to do refcounting on task_struct.  This
would result in each CPU holding a reference to the last task whose
fpsimd state was loaded there.  It's not clear whether this is
preferable, and it involves higher overhead than the fix proposed
in this patch.  It would also move all the task_struct freeing
work into the context switch critical section, or otherwise some
deferred cleanup mechanism would need to be introduced, neither of
which seems obviously justified.

Cc: 
Fixes: 005f78cd8849 ("arm64: defer reloading a task's FPSIMD state to userland resume")
Signed-off-by: Dave Martin 
Reviewed-by: Ard Biesheuvel 
[will: word-smithed the comment so it makes more sense]
Signed-off-by: Will Deacon 

Signed-off-by: Sasha Levin

arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one

2018-01-17T17:55:24+00:00

[ Upstream commit 26aa7b3b1c0fb3f1a6176a0c1847204ef4355693 ]

VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 47-bit addresses (instead of 48-bit) and also
insufficiently checking the alignment. This patch fixes it.

As an example, with 4k pages, before this patch we have:

  PHYS_MASK_SHIFT = 48
  VTTBR_X = 37 - 24 = 13
  VTTBR_BADDR_SHIFT = 13 - 1 = 12
  VTTBR_BADDR_MASK = ((1 << 35) - 1) << 12 = 0x00007ffffffff000

Which is wrong, because the mask doesn't allow bit 47 of the VTTBR
address to be set, and only requires the address to be 12-bit (4k)
aligned, while it actually needs to be 13-bit (8k) aligned because we
concatenate two 4k tables.

With this patch, the mask becomes 0x0000ffffffffe000, which is what we
want.

Fixes: 0369f6a34b9f ("arm64: KVM: EL2 register definitions")
Cc:  # 3.11.x
Reviewed-by: Suzuki K Poulose 
Reviewed-by: Christoffer Dall 
Signed-off-by: Kristina Martsenko 
Signed-off-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Sasha Levin

arm64: hw_breakpoint: fix watchpoint matching for tagged pointers

2018-01-17T17:55:16+00:00

[ Upstream commit 7dcd9dd8cebe9fa626af7e2358d03a37041a70fb ]

When we take a watchpoint exception, the address that triggered the
watchpoint is found in FAR_EL1. We compare it to the address of each
configured watchpoint to see which one was hit.

The configured watchpoint addresses are untagged, while the address in
FAR_EL1 will have an address tag if the data access was done using a
tagged address. The tag needs to be removed to compare the address to
the watchpoints.

Currently we don't remove it, and as a result can report the wrong
watchpoint as being hit (specifically, always either the highest TTBR0
watchpoint or lowest TTBR1 watchpoint). This patch removes the tag.

Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc:  # 3.12.x-
Acked-by: Mark Rutland 
Acked-by: Will Deacon 
Signed-off-by: Kristina Martsenko 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: ensure __dump_instr() checks addr_limit

2017-12-07T02:19:53+00:00

[ Upstream commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 ]

It's possible for a user to deliberately trigger __dump_instr with a
chosen kernel address.

Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.

Where we use __dump_instr() on kernel text, we already switch to
KERNEL_DS, so this shouldn't adversely affect those cases.

Fixes: 60ffc30d5652810d ("arm64: Exception handling")
Cc: stable@vger.kernel.org
Acked-by: Will Deacon 
Signed-off-by: Mark Rutland 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: Make sure SPsel is always set

2017-11-05T00:17:53+00:00

[ Upstream commit 5371513fb338fb9989c569dc071326d369d6ade8 ]

When the kernel is entered at EL2 on an ARMv8.0 system, we construct
the EL1 pstate and make sure this uses the the EL1 stack pointer
(we perform an exception return to EL1h).

But if the kernel is either entered at EL1 or stays at EL2 (because
we're on a VHE-capable system), we fail to set SPsel, and use whatever
stack selection the higher exception level has choosen for us.

Let's not take any chance, and make sure that SPsel is set to one
before we decide the mode we're going to run in.

Cc: 
Acked-by: Mark Rutland 
Signed-off-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin