linux.git/lib, branch v4.14.124

kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice.

2019-05-31T13:47:32+00:00

[ Upstream commit c03a0fd0b609e2f5c669c2b7f27c8e1928e9196e ]

syzbot is hitting use-after-free bug in uinput module [1]. This is because
kobject_uevent(KOBJ_REMOVE) is called again due to commit 0f4dafc0563c6c49
("Kobject: auto-cleanup on final unref") after memory allocation fault
injection made kobject_uevent(KOBJ_REMOVE) from device_del() from
input_unregister_device() fail, while uinput_destroy_device() is expecting
that kobject_uevent(KOBJ_REMOVE) is not called after device_del() from
input_unregister_device() completed.

That commit intended to catch cases where nobody even attempted to send
"remove" uevents. But there is no guarantee that an event will ultimately
be sent. We are at the point of no return as far as the rest of the kernel
is concerned; there are no repeats or do-overs.

Also, it is not clear whether some subsystem depends on that commit.
If no subsystem depends on that commit, it will be better to remove
the state_{add,remove}_uevent_sent logic. But we don't want to risk
a regression (in a patch which will be backported) by trying to remove
that logic. Therefore, as a first step, let's avoid the use-after-free bug
by making sure that kobject_uevent(KOBJ_REMOVE) won't be triggered twice.

[1] https://syzkaller.appspot.com/bug?id=8b17c134fe938bbddd75a45afaa9e68af43a362d

Reported-by: syzbot 
Analyzed-by: Dmitry Torokhov 
Fixes: 0f4dafc0563c6c49 ("Kobject: auto-cleanup on final unref")
Cc: Kay Sievers 
Signed-off-by: Tetsuo Handa 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

mm/uaccess: Use 'unsigned long' to placate UBSAN warnings on older GCC versions

2019-05-31T13:47:24+00:00

[ Upstream commit 29da93fea3ea39ab9b12270cc6be1b70ef201c9e ]

Randy reported objtool triggered on his (GCC-7.4) build:

  lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x315: call to __ubsan_handle_add_overflow() with UACCESS enabled
  lib/strnlen_user.o: warning: objtool: strnlen_user()+0x337: call to __ubsan_handle_sub_overflow() with UACCESS enabled

This is due to UBSAN generating signed-overflow-UB warnings where it
should not. Prior to GCC-8 UBSAN ignored -fwrapv (which the kernel
uses through -fno-strict-overflow).

Make the functions use 'unsigned long' throughout.

Reported-by: Randy Dunlap 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Randy Dunlap  # build-tested
Acked-by: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: luto@kernel.org
Link: http://lkml.kernel.org/r/20190424072208.754094071@infradead.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

sbitmap: fix improper use of smp_mb__before_atomic()

2019-05-31T13:47:10+00:00

commit a0934fd2b1208458e55fc4b48f55889809fce666 upstream.

This barrier only applies to the read-modify-write operations; in
particular, it does not apply to the atomic_set() primitive.

Replace the barrier with an smp_mb().

Fixes: 6c0ca7ae292ad ("sbitmap: fix wakeup hang after sbq resize")
Cc: stable@vger.kernel.org
Reported-by: "Paul E. McKenney" 
Reported-by: Peter Zijlstra 
Signed-off-by: Andrea Parri 
Reviewed-by: Ming Lei 
Cc: Jens Axboe 
Cc: Omar Sandoval 
Cc: Ming Lei 
Cc: linux-block@vger.kernel.org
Cc: "Paul E. McKenney" 
Cc: Peter Zijlstra 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

x86/mm/mem_encrypt: Disable all instrumentation for early SME setup

2019-05-25T16:25:36+00:00

[ Upstream commit b51ce3744f115850166f3d6c292b9c8cb849ad4f ]

Enablement of AMD's Secure Memory Encryption feature is determined very
early after start_kernel() is entered. Part of this procedure involves
scanning the command line for the parameter 'mem_encrypt'.

To determine intended state, the function sme_enable() uses library
functions cmdline_find_option() and strncmp(). Their use occurs early
enough such that it cannot be assumed that any instrumentation subsystem
is initialized.

For example, making calls to a KASAN-instrumented function before KASAN
is set up will result in the use of uninitialized memory and a boot
failure.

When AMD's SME support is enabled, conditionally disable instrumentation
of these dependent functions in lib/string.c and arch/x86/lib/cmdline.c.

 [ bp: Get rid of intermediary nostackp var and cleanup whitespace. ]

Fixes: aca20d546214 ("x86/mm: Add support to make use of Secure Memory Encryption")
Reported-by: Li RongQing 
Signed-off-by: Gary R Hook 
Signed-off-by: Borislav Petkov 
Cc: Alexander Shishkin 
Cc: Andrew Morton 
Cc: Andy Shevchenko 
Cc: Boris Brezillon 
Cc: Coly Li 
Cc: "dave.hansen@linux.intel.com" 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Kent Overstreet 
Cc: "luto@kernel.org" 
Cc: Masahiro Yamada 
Cc: Matthew Wilcox 
Cc: "mingo@redhat.com" 
Cc: "peterz@infradead.org" 
Cc: Sebastian Andrzej Siewior 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/155657657552.7116.18363762932464011367.stgit@sosrh3.amd.com
Signed-off-by: Sasha Levin

iov_iter: optimize page_copy_sane()

2019-05-21T16:50:21+00:00

commit 6daef95b8c914866a46247232a048447fff97279 upstream.

Avoid cache line miss dereferencing struct page if we can.

page_copy_sane() mostly deals with order-0 pages.

Extra cache line miss is visible on TCP recvmsg() calls dealing
with GRO packets (typically 45 page frags are attached to one skb).

Bringing the 45 struct pages into cpu cache while copying the data
is not free, since the freeing of the skb (and associated
page frags put_page()) can happen after cache lines have been evicted.

Signed-off-by: Eric Dumazet 
Cc: Al Viro 
Signed-off-by: Al Viro 
Cc: Matthew Wilcox 
Signed-off-by: Greg Kroah-Hartman

ubsan: Fix nasty -Wbuiltin-declaration-mismatch GCC-9 warnings

2019-05-10T15:53:08+00:00

commit f0996bc2978e02d2ea898101462b960f6119b18f upstream.

Building lib/ubsan.c with gcc-9 results in a ton of nasty warnings like
this one:

    lib/ubsan.c warning: conflicting types for built-in function
         ‘__ubsan_handle_negate_overflow’; expected ‘void(void *, void *)’ [-Wbuiltin-declaration-mismatch]

The kernel's declarations of __ubsan_handle_*() often uses 'unsigned
long' types in parameters while GCC these parameters as 'void *' types,
hence the mismatch.

Fix this by using 'void *' to match GCC's declarations.

Reported-by: Linus Torvalds 
Signed-off-by: Andrey Ryabinin 
Fixes: c6d308534aef ("UBSAN: run-time undefined behavior sanity checker")
Cc: 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

kasan: prevent compiler from optimizing away memset in tests

2019-05-08T05:20:45+00:00

commit 69ca372c100fba99c78ef826a1795aa86e4f01a8 upstream.

A compiler can optimize away memset calls by replacing them with mov
instructions.  There are KASAN tests that specifically test that KASAN
correctly handles memset calls so we don't want this optimization to
happen.

The solution is to add -fno-builtin flag to test_kasan.ko

Link: http://lkml.kernel.org/r/105ec9a308b2abedb1a0d1fdced0c22d765e4732.1519924383.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov 
Acked-by: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: Geert Uytterhoeven 
Cc: Nick Terrell 
Cc: Chris Mason 
Cc: Yury Norov 
Cc: Al Viro 
Cc: "Luis R . Rodriguez" 
Cc: Palmer Dabbelt 
Cc: "Paul E . McKenney" 
Cc: Jeff Layton 
Cc: "Jason A . Donenfeld" 
Cc: Kostya Serebryany 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Andrey Konovalov 
Signed-off-by: Greg Kroah-Hartman

kasan: remove redundant initialization of variable 'real_size'

2019-05-08T05:20:45+00:00

commit 48c232395431c23d35cf3b4c5a090bd793316578 upstream.

Variable real_size is initialized with a value that is never read, it is
re-assigned a new value later on, hence the initialization is redundant
and can be removed.

Cleans up clang warning:

  lib/test_kasan.c:422:21: warning: Value stored to 'real_size' during its initialization is never read

Link: http://lkml.kernel.org/r/20180206144950.32457-1-colin.king@canonical.com
Signed-off-by: Colin Ian King 
Acked-by: Andrey Ryabinin 
Reviewed-by: Andrew Morton 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Andrey Konovalov 
Signed-off-by: Greg Kroah-Hartman

lib/Kconfig.debug: fix build error without CONFIG_BLOCK

2019-05-02T07:40:28+00:00

commit ae3d6a323347940f0548bbb4b17f0bb2e9164169 upstream.

If CONFIG_TEST_KMOD is set to M, while CONFIG_BLOCK is not set, XFS and
BTRFS can not be compiled successly.

Link: http://lkml.kernel.org/r/20190410075434.35220-1-yuehaibing@huawei.com
Fixes: d9c6a72d6fa2 ("kmod: add test driver to stress test the module loader")
Signed-off-by: YueHaibing 
Reported-by: Hulk Robot 
Reviewed-by: Kees Cook 
Cc: Masahiro Yamada 
Cc: Petr Mladek 
Cc: Andy Shevchenko 
Cc: Matthew Wilcox 
Cc: Joe Lawrence 
Cc: Robin Murphy 
Cc: Luis Chamberlain 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

lib/div64.c: off by one in shift

2019-04-20T07:15:07+00:00

[ Upstream commit cdc94a37493135e355dfc0b0e086d84e3eadb50d ]

fls counts bits starting from 1 to 32 (returns 0 for zero argument).  If
we add 1 we shift right one bit more and loose precision from divisor,
what cause function incorect results with some numbers.

Corrected code was tested in user-space, see bugzilla:
   https://bugzilla.kernel.org/show_bug.cgi?id=202391

Link: http://lkml.kernel.org/r/1548686944-11891-1-git-send-email-sgruszka@redhat.com
Fixes: 658716d19f8f ("div64_u64(): improve precision on 32bit platforms")
Signed-off-by: Stanislaw Gruszka 
Reported-by: Siarhei Volkau 
Tested-by: Siarhei Volkau 
Acked-by: Oleg Nesterov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin