linux-stable.git/lib, branch v4.1.45

lib/Kconfig.debug: fix frv build failure

2017-09-10T20:36:07+00:00

[ Upstream commit da0510c47519fe0999cffe316e1d370e29f952be ]

The build of frv allmodconfig was failing with the errors like:

  /tmp/cc0JSPc3.s: Assembler messages:
  /tmp/cc0JSPc3.s:1839: Error: symbol `.LSLT0' is already defined
  /tmp/cc0JSPc3.s:1842: Error: symbol `.LASLTP0' is already defined
  /tmp/cc0JSPc3.s:1969: Error: symbol `.LELTP0' is already defined
  /tmp/cc0JSPc3.s:1970: Error: symbol `.LELT0' is already defined

Commit 866ced950bcd ("kbuild: Support split debug info v4") introduced
splitting the debug info and keeping that in a separate file.  Somehow,
the frv-linux gcc did not like that and I am guessing that instead of
splitting it started copying.  The first report about this is at:

  https://lists.01.org/pipermail/kbuild-all/2015-July/010527.html.

I will try and see if this can work with frv and if still fails I will
open a bug report with gcc.  But meanwhile this is the easiest option to
solve build failure of frv.

Fixes: 866ced950bcd ("kbuild: Support split debug info v4")
Link: http://lkml.kernel.org/r/1482062348-5352-1-git-send-email-sudipm.mukherjee@gmail.com
Signed-off-by: Sudip Mukherjee 
Reported-by: Fengguang Wu 
Cc: Andi Kleen 
Cc: David Howells 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

swiotlb: ensure that page-sized mappings are page-aligned

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

[ Upstream commit 602d9858f07c72eab64f5f00e2fae55f9902cfbe ]

Some drivers do depend on page mappings to be page aligned.

Swiotlb already enforces such alignment for mappings greater than page,
extend that to page-sized mappings as well.

Without this fix, nvme hits BUG() in nvme_setup_prps(), because that routine
assumes page-aligned mappings.

Signed-off-by: Nikita Yushchenko 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Sasha Levin

lib/cmdline.c: fix get_options() overflow while parsing ranges

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

[ Upstream commit a91e0f680bcd9e10c253ae8b62462a38bd48f09f ]

When using get_options() it's possible to specify a range of numbers,
like 1-100500.  The problem is that it doesn't track array size while
calling internally to get_range() which iterates over the range and
fills the memory with numbers.

Link: http://lkml.kernel.org/r/2613C75C-B04D-4BFF-82A6-12F97BA0F620@gmail.com
Signed-off-by: Ilya V. Matveychikov 
Cc: Jonathan Corbet 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

usercopy: Adjust tests to deal with SMAP/PAN

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

[ Upstream commit f5f893c57e37ca730808cb2eee3820abd05e7507 ]

Under SMAP/PAN/etc, we cannot write directly to userspace memory, so
this rearranges the test bytes to get written through copy_to_user().
Additionally drops the bad copy_from_user() test that would trigger a
memcpy() against userspace on failure.

Signed-off-by: Kees Cook 
Signed-off-by: Sasha Levin

fix iov_iter_fault_in_readable()

2016-10-03T12:35:04+00:00

[ Upstream commit d4690f1e1cdabb4d61207b6787b1605a0dc0aeab ]

... by turning it into what used to be multipages counterpart

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

dma-debug: avoid spinlock recursion when disabling dma-debug

2016-06-06T23:12:35+00:00

[ Upstream commit 3017cd63f26fc655d56875aaf497153ba60e9edf ]

With netconsole (at least) the pr_err("...  disablingn") call can
recurse back into the dma-debug code, where it'll try to grab
free_entries_lock again.  Avoid the problem by doing the printk after
dropping the lock.

Link: http://lkml.kernel.org/r/1463678421-18683-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

lib: lz4: fixed zram with lz4 on big endian machines

2016-04-20T05:08:56+00:00

[ Upstream commit 3e26a691fe3fe1e02a76e5bab0c143ace4b137b4 ]

Based on Sergey's test patch [1], this fixes zram with lz4 compression
on big endian cpus.

Note that the 64-bit preprocessor test is not a cleanup, it's part of
the fix, since those identifiers are bogus (for example, __ppc64__
isn't defined anywhere else in the kernel, which means we'd fall into
the 32-bit definitions on ppc64).

Tested on ppc64 with no regression on x86_64.

[1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4

Cc: stable@vger.kernel.org
Suggested-by: Sergey Senozhatsky 
Signed-off-by: Rui Salvaterra 
Reviewed-by: Sergey Senozhatsky 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

assoc_array: don't call compare_object() on a node

2016-04-20T05:08:51+00:00

[ Upstream commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 ]

Changes since V1: fixed the description and added KASan warning.

In assoc_array_insert_into_terminal_node(), we call the
compare_object() method on all non-empty slots, even when they're
not leaves, passing a pointer to an unexpected structure to
compare_object(). Currently it causes an out-of-bound read access
in keyring_compare_object detected by KASan (see below). The issue
is easily reproduced with keyutils testsuite.
Only call compare_object() when the slot is a leave.

KASan warning:
==================================================================
BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838
Read of size 8 by task keyctl/1655
=============================================================================
BUG kmalloc-192 (Not tainted): kasan: bad access detected
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647
	___slab_alloc+0x563/0x5c0
	__slab_alloc+0x51/0x90
	kmem_cache_alloc_trace+0x263/0x300
	assoc_array_insert+0xfd0/0x3a60
	__key_link_begin+0xfc/0x270
	key_create_or_update+0x459/0xaf0
	SyS_add_key+0x1ba/0x350
	entry_SYSCALL_64_fastpath+0x12/0x76
INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080
INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1

Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00  ...`............
Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff  ...`.......`....
Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
CPU: 0 PID: 1655 Comm: keyctl Tainted: G    B           4.5.0-rc4-kasan+ #291
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491
 ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969
 ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650
Call Trace:
 [] dump_stack+0x85/0xc4
 [] print_trailer+0xf9/0x150
 [] object_err+0x34/0x40
 [] kasan_report_error+0x230/0x550
 [] ? keyring_get_key_chunk+0x13e/0x210
 [] __asan_report_load_n_noabort+0x5d/0x70
 [] ? keyring_compare_object+0x213/0x240
 [] keyring_compare_object+0x213/0x240
 [] assoc_array_insert+0x86c/0x3a60
 [] ? assoc_array_cancel_edit+0x70/0x70
 [] ? __key_link_begin+0x20d/0x270
 [] __key_link_begin+0xfc/0x270
 [] key_create_or_update+0x459/0xaf0
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? key_type_lookup+0xc0/0xc0
 [] ? lookup_user_key+0x13d/0xcd0
 [] ? memdup_user+0x53/0x80
 [] SyS_add_key+0x1ba/0x350
 [] ? key_get_type_from_user.constprop.6+0xa0/0xa0
 [] ? retint_user+0x18/0x23
 [] ? trace_hardirqs_on_caller+0x3fe/0x580
 [] ? trace_hardirqs_on_thunk+0x17/0x19
 [] entry_SYSCALL_64_fastpath+0x12/0x76
Memory state around the buggy address:
 ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
 ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
>ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                        ^
 ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00
==================================================================

Signed-off-by: Jerome Marchand 
Signed-off-by: David Howells 
cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

lib/ucs2_string: Correct ucs2 -> utf8 conversion

2016-04-12T02:44:23+00:00

[ Upstream commit a68075908a37850918ad96b056acc9ac4ce1bd90 ]

The comparisons should be >= since 0x800 and 0x80 require an additional bit
to store.

For the 3 byte case, the existing shift would drop off 2 more bits than
intended.

For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
byte 2.

Signed-off-by: Jason Andryuk 
Reviewed-by: Laszlo Ersek 
Cc: Peter Jones 
Cc: Matthew Garrett 
Cc: "Lee, Chun-Yi" 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

lib/ucs2_string: Add ucs2 -> utf8 helper functions

2016-04-12T02:44:22+00:00

[ Upstream commit 73500267c930baadadb0d02284909731baf151f7 ]

This adds ucs2_utf8size(), which tells us how big our ucs2 string is in
bytes, and ucs2_as_utf8, which translates from ucs2 to utf8..

Signed-off-by: Peter Jones 
Tested-by: Lee, Chun-Yi 
Acked-by: Matthew Garrett 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin