linux-stable.git/arch/arm64/include, 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: 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 extension of smp_store_release value

2017-07-31T17:37:47+00:00

[ Upstream commit 994870bead4ab19087a79492400a5478e2906196 ]

When an inline assembly operand's type is narrower than the register it
is allocated to, the least significant bits of the register (up to the
operand type's width) are valid, and any other bits are permitted to
contain any arbitrary value. This aligns with the AAPCS64 parameter
passing rules.

Our __smp_store_release() implementation does not account for this, and
implicitly assumes that operands have been zero-extended to the width of
the type being stored to. Thus, we may store unknown values to memory
when the value type is narrower than the pointer type (e.g. when storing
a char to a long).

This patch fixes the issue by casting the value operand to the same
width as the pointer operand in all cases, which ensures that the value
is zero-extended as we expect. We use the same union trickery as
__smp_load_acquire and {READ,WRITE}_ONCE() to avoid GCC complaining that
pointers are potentially cast to narrower width integers in unreachable
paths.

A whitespace issue at the top of __smp_store_release() is also
corrected.

No changes are necessary for __smp_load_acquire(). Load instructions
implicitly clear any upper bits of the register, and the compiler will
only consider the least significant bits of the register as valid
regardless.

Fixes: 47933ad41a86 ("arch: Introduce smp_load_acquire(), smp_store_release()")
Fixes: 878a84d5a8a1 ("arm64: add missing data types in smp_load_acquire/smp_store_release")
Cc:  # 3.14.x-
Acked-by: Will Deacon 
Signed-off-by: Mark Rutland 
Cc: Matthias Kaehlcke 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: entry: improve data abort handling of tagged pointers

2017-06-26T02:02:20+00:00

[ Upstream commit 276e93279a630657fff4b086ba14c95955912dfa ]

When handling a data abort from EL0, we currently zero the top byte of
the faulting address, as we assume the address is a TTBR0 address, which
may contain a non-zero address tag. However, the address may be a TTBR1
address, in which case we should not zero the top byte. This patch fixes
that. The effect is that the full TTBR1 address is passed to the task's
signal handler (or printed out in the kernel log).

When handling a data abort from EL1, we leave the faulting address
intact, as we assume it's either a TTBR1 address or a TTBR0 address with
tag 0x00. This is true as far as I'm aware, we don't seem to access a
tagged TTBR0 address anywhere in the kernel. Regardless, it's easy to
forget about address tags, and code added in the future may not always
remember to remove tags from addresses before accessing them. So add tag
handling to the EL1 data abort handler as well. This also makes it
consistent with the EL0 data abort handler.

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

kvm arm: Move fake PGD handling to arch specific files

2017-06-08T10:12:19+00:00

[ Upstream commit 120f0779c3ed89c25ef1db943feac8ed73a0d7f9 ]

Rearrange the code for fake pgd handling, which is applicable
only for arm64. This will later be removed once we introduce
the stage2 page table walker macros.

Reviewed-by: Marc Zyngier 
Reviewed-by: Christoffer Dall 
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Sasha Levin

arm64: uaccess: ensure extension of access_ok() addr

2017-05-28T10:36:09+00:00

[ Upstream commit a06040d7a791a9177581dcf7293941bd92400856 ]

Our access_ok() simply hands its arguments over to __range_ok(), which
implicitly assummes that the addr parameter is 64 bits wide. This isn't
necessarily true for compat code, which might pass down a 32-bit address
parameter.

In these cases, we don't have a guarantee that the address has been zero
extended to 64 bits, and the upper bits of the register may contain
unknown values, potentially resulting in a suprious failure.

Avoid this by explicitly casting the addr parameter to an unsigned long
(as is done on other architectures), ensuring that the parameter is
widened appropriately.

Fixes: 0aea86a2176c ("arm64: User access library functions")
Cc:  # 3.7.x-
Acked-by: Will Deacon 
Signed-off-by: Mark Rutland 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm/arm64: KVM: Enforce unconditional flush to PoC when mapping to stage-2

2017-05-17T19:06:58+00:00

[ Upstream commit 8f36ebaf21fdae99c091c67e8b6fab33969f2667 ]

When we fault in a page, we flush it to the PoC (Point of Coherency)
if the faulting vcpu has its own caches off, so that it can observe
the page we just brought it.

But if the vcpu has its caches on, we skip that step. Bad things
happen when *another* vcpu tries to access that page with its own
caches disabled. At that point, there is no garantee that the
data has made it to the PoC, and we access stale data.

The obvious fix is to always flush to PoC when a page is faulted
in, no matter what the state of the vcpu is.

Cc: stable@vger.kernel.org
Fixes: 2d58b733c876 ("arm64: KVM: force cache clean on page fault when caches are off")
Reviewed-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin

arm64/ptrace: Avoid uninitialised struct padding in fpr_set()

2017-03-06T22:29:27+00:00

[ Upstream commit aeb1f39d814b2e21e5e5706a48834bfd553d0059 ]

This patch adds an explicit __reserved[] field to user_fpsimd_state
to replace what was previously unnamed padding.

This ensures that data in this region are propagated across
assignment rather than being left possibly uninitialised at the
destination.

Cc:  # 3.7.x-
Fixes: 60ffc30d5652 ("arm64: Exception handling")
Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin