linux.git/arch, branch v3.15.3

x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)

2014-07-01T03:14:04+00:00

commit 554086d85e71f30abe46fc014fea31929a7c6a8a upstream.

The bad syscall nr paths are their own incomprehensible route
through the entry control flow.  Rearrange them to work just like
syscalls that return -ENOSYS.

This fixes an OOPS in the audit code when fast-path auditing is
enabled and sysenter gets a bad syscall nr (CVE-2014-4508).

This has probably been broken since Linux 2.6.27:
af0575bba0 i386 syscall audit fast-path

Cc: Roland McGrath 
Reported-by: Toralf Förster 
Signed-off-by: Andy Lutomirski 
Link: http://lkml.kernel.org/r/e09c499eade6fc321266dd6b54da7beb28d6991c.1403558229.git.luto@amacapital.net
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, x32: Use compat shims for io_{setup,submit}

2014-07-01T03:14:01+00:00

commit 7fd44dacdd803c0bbf38bf478d51d280902bb0f1 upstream.

The io_setup takes a pointer to a context id of type aio_context_t.
This in turn is typed to a __kernel_ulong_t.  We could tweak the
exported headers to define this as a 64bit quantity for specific
ABIs, but since we already have a 32bit compat shim for the x86 ABI,
let's just re-use that logic.  The libaio package is also written to
expect this as a pointer type, so a compat shim would simplify that.

The io_submit func operates on an array of pointers to iocb structs.
Padding out the array to be 64bit aligned is a huge pain, so convert
it over to the existing compat shim too.

We don't convert io_getevents to the compat func as its only purpose
is to handle the timespec struct, and the x32 ABI uses 64bit times.

With this change, the libaio package can now pass its testsuite when
built for the x32 ABI.

Signed-off-by: Mike Frysinger 
Link: http://lkml.kernel.org/r/1399250595-5005-1-git-send-email-vapier@gentoo.org
Cc: H.J. Lu 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86-32, espfix: Remove filter for espfix32 due to race

2014-07-01T03:14:01+00:00

commit 246f2d2ee1d715e1077fc47d61c394569c8ee692 upstream.

It is not safe to use LAR to filter when to go down the espfix path,
because the LDT is per-process (rather than per-thread) and another
thread might change the descriptors behind our back.  Fortunately it
is always *safe* (if a bit slow) to go down the espfix path, and a
32-bit LDT stack segment is extremely rare.

Signed-off-by: H. Peter Anvin 
Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

arm64: mm: remove broken &= operator from pmd_mknotpresent

2014-07-01T03:14:01+00:00

commit e3a920afc3482e954834a4ed95908c4bc5e4c000 upstream.

This should be a plain old '&' and could easily lead to undefined
behaviour if the target of a pmd_mknotpresent invocation was the same
as the parameter.

Fixes: 9c7e535fcc17 (arm64: mm: Route pmd thp functions through pte equivalents)
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64/dma: Removing ARCH_HAS_DMA_GET_REQUIRED_MASK macro

2014-07-01T03:14:01+00:00

commit f3a183cb422574014538017b5b291a416396f97e upstream.

Arm64 does not define dma_get_required_mask() function.
Therefore, it should not define the ARCH_HAS_DMA_GET_REQUIRED_MASK.
This causes build errors in some device drivers (e.g. mpt2sas)

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: uid16: fix __kernel_old_{gid,uid}_t definitions

2014-07-01T03:14:01+00:00

commit 34c65c43f1518bf85f93526ad373adc6a683b4c5 upstream.

Whilst native arm64 applications don't have the 16-bit UID/GID syscalls
wired up, compat tasks can still access them. The 16-bit wrappers for
these syscalls use __kernel_old_uid_t and __kernel_old_gid_t, which must
be 16-bit data types to maintain compatibility with the 16-bit UIDs used
by compat applications.

This patch defines 16-bit __kernel_old_{gid,uid}_t types for arm64
instead of using the 32-bit types provided by asm-generic.

Signed-off-by: Will Deacon 
Acked-by: Arnd Bergmann 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: DT: fix OpenBlocks AX3-4 RAM size

2014-07-01T03:14:01+00:00

commit e47043aea3853a74a9aa5726a1faa916d7462ab7 upstream.

The OpenBlocks AX3-4 has a non-DT bootloader.  It also comes with 1GB of
soldered on RAM, and a DIMM slot for expansion.

Unfortunately, atags_to_fdt() doesn't work in big-endian mode, so we see
the following failure when attempting to boot a big-endian kernel:

  686 slab pages
  17 pages shared
  0 pages swap cached
  [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
  Kernel panic - not syncing: Out of memory and no killable processes...

  CPU: 1 PID: 351 Comm: kworker/u4:0 Not tainted 3.15.0-rc8-next-20140603 #1
  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
  [] (show_stack) from [] (dump_stack+0x78/0x94)
  [] (dump_stack) from [] (panic+0x90/0x21c)
  [] (panic) from [] (out_of_memory+0x320/0x340)
  [] (out_of_memory) from [] (__alloc_pages_nodemask+0x874/0x930)
  [] (__alloc_pages_nodemask) from [] (handle_mm_fault+0x744/0x96c)
  [] (handle_mm_fault) from [] (__get_user_pages+0xd0/0x4c0)
  [] (__get_user_pages) from [] (get_arg_page+0x54/0xbc)
  [] (get_arg_page) from [] (copy_strings+0x278/0x29c)
  [] (copy_strings) from [] (copy_strings_kernel+0x20/0x28)
  [] (copy_strings_kernel) from [] (do_execve+0x3a8/0x4c8)
  [] (do_execve) from [] (____call_usermodehelper+0x15c/0x194)
  [] (____call_usermodehelper) from [] (ret_from_fork+0x14/0x3c)
  CPU0: stopping
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140603 #1
  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
  [] (show_stack) from [] (dump_stack+0x78/0x94)
  [] (dump_stack) from [] (handle_IPI+0x138/0x174)
  [] (handle_IPI) from [] (armada_370_xp_handle_irq+0xb0/0xcc)
  [] (armada_370_xp_handle_irq) from [] (__irq_svc+0x40/0x50)
  Exception stack(0xc0b6bf68 to 0xc0b6bfb0)
  bf60:                   e9fad598 00000000 00f509a3 00000000 c0b6a000 c0b724c4
  bf80: c0b72458 c0b6a000 00000000 00000000 c0b66da0 c0b6a000 00000000 c0b6bfb0
  bfa0: c027bb94 c027bb24 60000313 ffffffff
  [] (__irq_svc) from [] (cpu_startup_entry+0x54/0x214)
  [] (cpu_startup_entry) from [] (start_kernel+0x318/0x37c)
  [] (start_kernel) from [<00208078>] (0x208078)
  ---[ end Kernel panic - not syncing: Out of memory and no killable processes...

A similar failure will also occur if ARM_ATAG_DTB_COMPAT isn't selected.

Fix this by setting a sane default (1 GB) in the dts file.

Signed-off-by: Jason Cooper 
Tested-by: Kevin Hilman 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP2+: gpmc: enable BCH_HW ecc-scheme for AM43xx platforms

2014-07-01T03:13:59+00:00

commit 2e091d13e65d26f21159323b95b426e5bc42670c upstream.

Fixes: commit 0611c41934ab35ce84dea34ab291897ad3cbc7be
ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms and ECC schemes

Though the commit log of above commit mentions AM43xx platforms, but code change
missed AM43xx. This patch adds AM43xx to list of those SoC which have built-in
ELM hardware engine, so that BCH ecc-schemes with hardware error-correction can
be enabled on AM43xx devices.

Reported-by: Roger Quadros 
Signed-off-by: Pekon Gupta 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: 8037/1: mm: support big-endian page tables

2014-07-01T03:13:59+00:00

commit 86f40622af7329375e38f282f6c0aab95f3e5f72 upstream.

When enable LPAE and big-endian in a hisilicon board, while specify
mem=384M mem=512M@7680M, will get bad page state:

Freeing unused kernel memory: 180K (c0466000 - c0493000)
BUG: Bad page state in process init  pfn:fa442
page:c7749840 count:0 mapcount:-1 mapping:  (null) index:0x0
page flags: 0x40000400(reserved)
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 3.10.27+ #66
[] (unwind_backtrace+0x0/0x11c) from [] (show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] (bad_page+0xd4/0x104)
[] (bad_page+0xd4/0x104) from [] (free_pages_prepare+0xa8/0x14c)
[] (free_pages_prepare+0xa8/0x14c) from [] (free_hot_cold_page+0x18/0xf0)
[] (free_hot_cold_page+0x18/0xf0) from [] (handle_pte_fault+0xcf4/0xdc8)
[] (handle_pte_fault+0xcf4/0xdc8) from [] (handle_mm_fault+0xf4/0x120)
[] (handle_mm_fault+0xf4/0x120) from [] (do_page_fault+0xfc/0x354)
[] (do_page_fault+0xfc/0x354) from [] (do_DataAbort+0x2c/0x90)
[] (do_DataAbort+0x2c/0x90) from [] (__dabt_usr+0x34/0x40)

The bad pfn:fa442 is not system memory(mem=384M mem=512M@7680M), after debugging,
I find in page fault handler, will get wrong pfn from pte just after set pte,
as follow:
do_anonymous_page()
{
	...
	set_pte_at(mm, address, page_table, entry);

	//debug code
	pfn = pte_pfn(entry);
	pr_info("pfn:0x%lx, pte:0x%llxn", pfn, pte_val(entry));

	//read out the pte just set
	new_pte = pte_offset_map(pmd, address);
	new_pfn = pte_pfn(*new_pte);
	pr_info("new pfn:0x%lx, new pte:0x%llxn", pfn, pte_val(entry));
	...
}

pfn:   0x1fa4f5,     pte:0xc00001fa4f575f
new_pfn:0xfa4f5, new_pte:0xc00000fa4f5f5f	//new pfn/pte is wrong.

The bug is happened in cpu_v7_set_pte_ext(ptep, pte):
An LPAE PTE is a 64bit quantity, passed to cpu_v7_set_pte_ext in the r2 and r3 registers.
On an LE kernel, r2 contains the LSB of the PTE, and r3 the MSB.
On a BE kernel, the assignment is reversed.

Unfortunately, the current code always assumes the LE case,
leading to corruption of the PTE when clearing/setting bits.

This patch fixes this issue much like it has been done already in the
cpu_v7_switch_mm case.

Signed-off-by: Jianguo Wu 
Acked-by: Marc Zyngier 
Acked-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: stacktrace: avoid listing stacktrace functions in stacktrace

2014-07-01T03:13:59+00:00

commit 3683f44c42e991d313dc301504ee0fca1aeb8580 upstream.

While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as follows:

 [] save_stack_trace_tsk+0x0/0x98
 [] save_stack_trace+0x24/0x28
 ...

This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong
thing (which is the number of stack frames to avoid recording.)

Perversely, it does the right thing when passed a non-current thread.  Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.

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