linux-stable.git/arch, branch v3.18.82

security/keys: add CONFIG_KEYS_COMPAT to Kconfig

2017-11-18T10:06:31+00:00

commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 upstream.

CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.

At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.

This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.

[DH: Modified to remove arm64 compat enablement also as requested by Eric
 Biggers]

Signed-off-by: Bilal Amarni 
Signed-off-by: David Howells 
Reviewed-by: Arnd Bergmann 
cc: Eric Biggers 
Signed-off-by: James Morris 
Cc: James Cowgill 
Signed-off-by: Greg Kroah-Hartman

Revert "ARM: dts: imx53-qsb-common: fix FEC pinmux config"

2017-11-18T10:06:30+00:00

This reverts commit 2eb85ef18c6570e8a59643cd8d5a66122461b1fc which is
commit 8b649e426336d7d4800ff9c82858328f4215ba01 upstream.

Turns out not to be a good idea in the stable kernels for now as Patrick
writes:
	As discussed for 4.4 stable queue this patch might break
	existing machines, if they use a different pinmux configuration
	with their own bootloader.

Reported-by: Patrick Brünn 
Cc: Shawn Guo 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context

2017-11-15T09:04:14+00:00

commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream.

The warning below says it all:

  BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1
  caller is __this_cpu_preempt_check
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4
  Call Trace:
   dump_stack
   check_preemption_disabled
   ? do_early_param
   __this_cpu_preempt_check
   arch_perfmon_init
   op_nmi_init
   ? alloc_pci_root_info
   oprofile_arch_init
   oprofile_init
   do_one_initcall
   ...

These accessors should not have been used in the first place: it is PPro so
no mixed silicon revisions and thus it can simply use boot_cpu_data.

Reported-by: Fengguang Wu 
Tested-by: Fengguang Wu 
Fix-creation-mandated-by: Linus Torvalds 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: Robert Richter 
Cc: x86@kernel.org
Signed-off-by: Greg Kroah-Hartman

MIPS: AR7: Ensure that serial ports are properly set up

2017-11-15T09:04:13+00:00

commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream.

Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is
never copied, resulting in a dead port.

Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type")
Signed-off-by: Oswald Buddenhagen 
[jonas.gorski: add Fixes tag]
Signed-off-by: Jonas Gorski 
Reviewed-by: Florian Fainelli 
Cc: Ralf Baechle 
Cc: Greg Kroah-Hartman 
Cc: Yoshihiro YUNOMAE 
Cc: Nicolas Schichan 
Cc: Oswald Buddenhagen 
Cc: linux-mips@linux-mips.org
Cc: linux-serial@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17543/
Signed-off-by: James Hogan 
Signed-off-by: Greg Kroah-Hartman

MIPS: Fix CM region target definitions

2017-11-15T09:04:13+00:00

commit 6a6cba1d945a7511cdfaf338526871195e420762 upstream.

The default CM target field in the GCR_BASE register is encoded with 0
meaning memory & 1 being reserved. However the definitions we use for
those bits effectively get these two values backwards - likely because
they were copied from the definitions for the CM regions where the
target is encoded differently. This results in use setting up GCR_BASE
with the reserved target value by default, rather than targeting memory
as intended. Although we currently seem to get away with this it's not a
great idea to rely upon.

Fix this by changing our macros to match the documentated target values.

The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add
generic CM probe & access code") in the Linux v3.15 cycle, and was
likely carried forwards from older but unused code introduced by
commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the
v2.6.26 cycle.

Fixes: 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code")
Signed-off-by: Paul Burton 
Reported-by: Matt Redfearn 
Reviewed-by: James Hogan 
Cc: Matt Redfearn 
Cc: Ralf Baechle 
Cc: linux-mips@linux-mips.org
Cc:  # v3.15+
Patchwork: https://patchwork.linux-mips.org/patch/17562/
Signed-off-by: James Hogan 
[jhogan@kernel.org: Backported 3.15..4.13]
Signed-off-by: Greg Kroah-Hartman

MIPS: microMIPS: Fix incorrect mask in insn_table_MM

2017-11-15T09:04:13+00:00

commit 77238e76b9156d28d86c1e31c00ed2960df0e4de upstream.

It seems that this is a typo error and the proper bit masking is
"RT | RS" instead of "RS | RS".

This issue was detected with the help of Coccinelle.

Fixes: d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction")
Reported-by: Julia Lawall 
Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: James Hogan 
Patchwork: https://patchwork.linux-mips.org/patch/17551/
Signed-off-by: James Hogan 
[jhogan@kernel.org: Backported 3.16..4.12]
Signed-off-by: Greg Kroah-Hartman

ARM: 8720/1: ensure dump_instr() checks addr_limit

2017-11-15T09:04:13+00:00

commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream.

When CONFIG_DEBUG_USER is enabled, 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.

So that we can use the same code to dump user instructions and kernel
instructions, the common dumping code is factored out to __dump_instr(),
with the fs manipulated appropriately in dump_instr() around calls to
this.

Signed-off-by: Mark Rutland 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

crypto: x86/sha1-mb - fix panic due to unaligned access

2017-11-15T09:04:13+00:00

commit d041b557792c85677f17e08eee535eafbd6b9aa2 upstream.

struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc()
and later passed in sha1_mb_flusher_mgr_flush_avx2() function where
instructions vmovdqa used to access the struct. vmovdqa requires
16-bytes aligned argument, but nothing guarantees that struct
sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will
generate GP fault.

Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
requirements.

Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2")
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix register offsets for the IRDA serial port

2017-11-15T09:04:12+00:00

[ Upstream commit a752ba18af8285e3eeda572f40dddaebff0c3621 ]

Even though most of its registers are 8-bit wide, the IRDA has two
16-bit registers that make it a 16-bit peripheral and not a 8-bit
peripheral with addresses shifted by one. Fix the registers offset in
the driver and the platform data regshift value.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6

2017-11-15T09:04:11+00:00

[ Upstream commit 4cd6a59f5c1a9b0cca0da09fbba42b9450ffc899 ]

We have more than four uarts on some SoCs and that can cause
noise with errors while booting.

Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman