01 Jul, 2020
1 commit
-
[ Upstream commit a6379f0ad6375a707e915518ecd5c2270afcd395 ]
In case of failure of check_expect_hints_stats(), the resources
allocated by objagg_hints_get should be freed. The patch fixes
this issue.Signed-off-by: Aditya Pakki
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
24 Jun, 2020
1 commit
-
[ Upstream commit acaab7335bd6f0c0b54ce3a00bd7f18222ce0f5f ]
The zlib inflate code has an old micro-optimization based on the
assumption that for pre-increment memory accesses, the compiler will
generate code that fits better into the processor's pipeline than what
would be generated for post-increment memory accesses.This optimization was already removed in upstream zlib in 2016:
https://github.com/madler/zlib/commit/9aaec95e8211This optimization causes UB according to C99, which says in section 6.5.6
"Additive operators": "If both the pointer operand and the result point to
elements of the same array object, or one past the last element of the
array object, the evaluation shall not produce an overflow; otherwise, the
behavior is undefined".This UB is not only a theoretical concern, but can also cause trouble for
future work on compiler-based sanitizers.According to the zlib commit, this optimization also is not optimal
anymore with modern compilers.Replace uses of OFF, PUP and UP_UNALIGNED with their definitions in the
POSTINC case, and remove the macro definitions, just like in the upstream
patch.Signed-off-by: Jann Horn
Signed-off-by: Andrew Morton
Cc: Mikhail Zaslonko
Link: http://lkml.kernel.org/r/20200507123112.252723-1-jannh@google.com
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
22 Jun, 2020
2 commits
-
[ Upstream commit adb72ae1915db28f934e9e02c18bfcea2f3ed3b7 ]
Patch series "Fix some incompatibilites between KASAN and FORTIFY_SOURCE", v4.
3 KASAN self-tests fail on a kernel with both KASAN and FORTIFY_SOURCE:
memchr, memcmp and strlen.When FORTIFY_SOURCE is on, a number of functions are replaced with
fortified versions, which attempt to check the sizes of the operands.
However, these functions often directly invoke __builtin_foo() once they
have performed the fortify check. The compiler can detect that the
results of these functions are not used, and knows that they have no other
side effects, and so can eliminate them as dead code.Why are only memchr, memcmp and strlen affected?
================================================Of string and string-like functions, kasan_test tests:
* strchr -> not affected, no fortified version
* strrchr -> likewise
* strcmp -> likewise
* strncmp -> likewise* strnlen -> not affected, the fortify source implementation calls the
underlying strnlen implementation which is instrumented, not
a builtin* strlen -> affected, the fortify souce implementation calls a __builtin
version which the compiler can determine is dead.* memchr -> likewise
* memcmp -> likewise* memset -> not affected, the compiler knows that memset writes to its
first argument and therefore is not dead.Why does this not affect the functions normally?
================================================In string.h, these functions are not marked as __pure, so the compiler
cannot know that they do not have side effects. If relevant functions are
marked as __pure in string.h, we see the following warnings and the
functions are elided:lib/test_kasan.c: In function `kasan_memchr':
lib/test_kasan.c:606:2: warning: statement with no effect [-Wunused-value]
memchr(ptr, '1', size + 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~
lib/test_kasan.c: In function `kasan_memcmp':
lib/test_kasan.c:622:2: warning: statement with no effect [-Wunused-value]
memcmp(ptr, arr, size+1);
^~~~~~~~~~~~~~~~~~~~~~~~
lib/test_kasan.c: In function `kasan_strings':
lib/test_kasan.c:645:2: warning: statement with no effect [-Wunused-value]
strchr(ptr, '1');
^~~~~~~~~~~~~~~~
...This annotation would make sense to add and could be added at any point,
so the behaviour of test_kasan.c should change.The fix
=======Make all the functions that are pure write their results to a global,
which makes them live. The strlen and memchr tests now pass.The memcmp test still fails to trigger, which is addressed in the next
patch.[dja@axtens.net: drop patch 3]
Link: http://lkml.kernel.org/r/20200424145521.8203-2-dja@axtens.net
Fixes: 0c96350a2d2f ("lib/test_kasan.c: add tests for several string/memory API functions")
Signed-off-by: Daniel Axtens
Signed-off-by: Andrew Morton
Tested-by: David Gow
Reviewed-by: Dmitry Vyukov
Cc: Daniel Micay
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Link: http://lkml.kernel.org/r/20200423154503.5103-1-dja@axtens.net
Link: http://lkml.kernel.org/r/20200423154503.5103-2-dja@axtens.net
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit 18f1ca46858eac22437819937ae44aa9a8f9f2fa ]
When building 64r6_defconfig with CONFIG_MIPS32_O32 disabled and
CONFIG_CRYPTO_RSA enabled:lib/mpi/generic_mpih-mul1.c:37:24: error: invalid use of a cast in a
inline asm context requiring an l-value: remove the cast
or build with -fheinous-gnu-extensions
umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/mpi/longlong.h:664:22: note: expanded from macro 'umul_ppmm'
: "=d" ((UDItype)(w0))
~~~~~~~~~~^~~
lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
inline asm context requiring an l-value: remove the cast
or build with -fheinous-gnu-extensions
umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/mpi/longlong.h:668:22: note: expanded from macro 'umul_ppmm'
: "=d" ((UDItype)(w1))
~~~~~~~~~~^~~
2 errors generated.This special case for umul_ppmm for MIPS64r6 was added in
commit bbc25bee37d2b ("lib/mpi: Fix umul_ppmm() for MIPS64r6"), due to
GCC being inefficient and emitting a __multi3 intrinsic.There is no such issue with clang; with this patch applied, I can build
this configuration without any problems and there are no link errors
like mentioned in the commit above (which I can still reproduce with
GCC 9.3.0 when that commit is reverted). Only use this definition when
GCC is being used.This really should have been caught by commit b0c091ae04f67 ("lib/mpi:
Eliminate unused umul_ppmm definitions for MIPS") when I was messing
around in this area but I was not testing 64-bit MIPS at the time.Link: https://github.com/ClangBuiltLinux/linux/issues/885
Reported-by: Dmitry Golovin
Signed-off-by: Nathan Chancellor
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
17 Jun, 2020
1 commit
-
commit b5265c813ce4efbfa2e46fd27cdf9a7f44a35d2e upstream.
In some rare cases, for input data over 32 KB, lzo-rle could encode two
different inputs to the same compressed representation, so that
decompression is then ambiguous (i.e. data may be corrupted - although
zram is not affected because it operates over 4 KB pages).This modifies the compressor without changing the decompressor or the
bitstream format, such that:- there is no change to how data produced by the old compressor is
decompressed- an old decompressor will correctly decode data from the updated
compressor- performance and compression ratio are not affected
- we avoid introducing a new bitstream format
In testing over 12.8M real-world files totalling 903 GB, three files
were affected by this bug. I also constructed 37M semi-random 64 KB
files totalling 2.27 TB, and saw no affected files. Finally I tested
over files constructed to contain each of the ~1024 possible bad input
sequences; for all of these cases, updated lzo-rle worked correctly.There is no significant impact to performance or compression ratio.
Signed-off-by: Dave Rodgman
Signed-off-by: Andrew Morton
Cc: Mark Rutland
Cc: Dave Rodgman
Cc: Willy Tarreau
Cc: Sergey Senozhatsky
Cc: Markus F.X.J. Oberhumer
Cc: Minchan Kim
Cc: Nitin Gupta
Cc: Chao Yu
Cc:
Link: http://lkml.kernel.org/r/20200507100203.29785-1-dave.rodgman@arm.com
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
27 May, 2020
1 commit
-
commit 7bd57fbc4a4ddedc664cad0bbced1b469e24e921 upstream.
I don't see what security concern is addressed by obfuscating NULL
and IS_ERR() error pointers, printed with %p/%pK. Given the number
of sites where %p is used (over 10000) and the fact that NULL pointers
aren't uncommon, it probably wouldn't take long for an attacker to
find the hash that corresponds to 0. Although harder, the same goes
for most common error values, such as -1, -2, -11, -14, etc.The NULL part actually fixes a regression: NULL pointers weren't
obfuscated until commit 3e5903eb9cff ("vsprintf: Prevent crash when
dereferencing invalid pointers") which went into 5.2. I'm tacking
the IS_ERR() part on here because error pointers won't leak kernel
addresses and printing them as pointers shouldn't be any different
from e.g. %d with PTR_ERR_OR_ZERO(). Obfuscating them just makes
debugging based on existing pr_debug and friends excruciating.Note that the "always print 0's for %pK when kptr_restrict == 2"
behaviour which goes way back is left as is.Example output with the patch applied:
ptr error-ptr NULL
%p: 0000000001f8cc5b fffffffffffffff2 0000000000000000
%pK, kptr = 0: 0000000001f8cc5b fffffffffffffff2 0000000000000000
%px: ffff888048c04020 fffffffffffffff2 0000000000000000
%pK, kptr = 1: ffff888048c04020 fffffffffffffff2 0000000000000000
%pK, kptr = 2: 0000000000000000 0000000000000000 0000000000000000Fixes: 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
Signed-off-by: Ilya Dryomov
Reviewed-by: Petr Mladek
Reviewed-by: Sergey Senozhatsky
Reviewed-by: Andy Shevchenko
Acked-by: Steven Rostedt (VMware)
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
10 May, 2020
2 commits
-
[ Upstream commit e537654b7039aacfe8ae629d49655c0e5692ad44 ]
Implement a resource managed strongly uncachable ioremap function.
Cc: # v4.19+
Tested-by: AceLan Kao
Signed-off-by: Tuowen Zhao
Acked-by: Mika Westerberg
Acked-by: Andy Shevchenko
Acked-by: Luis Chamberlain
Signed-off-by: Lee Jones
Signed-off-by: Sasha Levin -
[ Upstream commit 5990cdee689c6885b27c6d969a3d58b09002b0bc ]
0day reports over and over on an powerpc randconfig with clang:
lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
inline asm context requiring an l-value: remove the cast or build with
-fheinous-gnu-extensionsRemove the superfluous casts, which have been done previously for x86
and arm32 in commit dea632cadd12 ("lib/mpi: fix build with clang") and
commit 7b7c1df2883d ("lib/mpi/longlong.h: fix building with 32-bit
x86").Reported-by: kbuild test robot
Signed-off-by: Nathan Chancellor
Acked-by: Herbert Xu
Signed-off-by: Michael Ellerman
Link: https://github.com/ClangBuiltLinux/linux/issues/991
Link: https://lore.kernel.org/r/20200413195041.24064-1-natechancellor@gmail.com
Signed-off-by: Sasha Levin
29 Apr, 2020
1 commit
-
[ Upstream commit 06bd48b6cd97ef3889b68c8e09014d81dbc463f1 ]
You can build a user-space test program for the raid6 library code,
like this:$ cd lib/raid6/test
$ makeThe command in $(shell ...) function is evaluated by /bin/sh by default.
(or, you can specify the shell by passing SHELL= from command line)Currently '>&/dev/null' is used to sink both stdout and stderr. Because
this code is bash-ism, it only works when /bin/sh is a symbolic link to
bash (this is the case on RHEL etc.)This does not work on Ubuntu where /bin/sh is a symbolic link to dash.
I see lots of
/bin/sh: 1: Syntax error: Bad fd number
and
warning "your version of binutils lacks ... support"
Replace it with portable '>/dev/null 2>&1'.
Fixes: 4f8c55c5ad49 ("lib/raid6: build proper files on corresponding arch")
Signed-off-by: Masahiro Yamada
Acked-by: H. Peter Anvin (Intel)
Reviewed-by: Jason A. Donenfeld
Acked-by: Ingo Molnar
Reviewed-by: Nick Desaulniers
Signed-off-by: Sasha Levin
23 Apr, 2020
1 commit
-
commit 7d32e69310d67e6b04af04f26193f79dfc2f05c7 upstream.
Currently turning on DEBUG_INFO_SPLIT when DEBUG_INFO_BTF is also
enabled will produce invalid btf file, since gen_btf function in
link-vmlinux.sh script doesn't handle *.dwo files.Enabling DEBUG_INFO_REDUCED will also produce invalid btf file,
and using GCC_PLUGIN_RANDSTRUCT with BTF makes no sense.Fixes: e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")
Reported-by: Jann Horn
Reported-by: Liu Yiding
Signed-off-by: Slava Bacherikov
Signed-off-by: Daniel Borkmann
Reviewed-by: Kees Cook
Acked-by: KP Singh
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20200402204138.408021-1-slava@bacher09.org
Signed-off-by: Greg Kroah-Hartman
17 Apr, 2020
2 commits
-
commit 7e934cf5ace1dceeb804f7493fa28bb697ed3c52 upstream.
xas_for_each_marked() is using entry == NULL as a termination condition
of the iteration. When xas_for_each_marked() is used protected only by
RCU, this can however race with xas_store(xas, NULL) in the following
way:TASK1 TASK2
page_cache_delete() find_get_pages_range_tag()
xas_for_each_marked()
xas_find_marked()
off = xas_find_chunk()xas_store(&xas, NULL)
xas_init_marks(&xas);
...
rcu_assign_pointer(*slot, NULL);
entry = xa_entry(off);And thus xas_for_each_marked() terminates prematurely possibly leading
to missed entries in the iteration (translating to missing writeback of
some pages or a similar problem).If we find a NULL entry that has been marked, skip it (unless we're trying
to allocate an entry).Reported-by: Jan Kara
CC: stable@vger.kernel.org
Fixes: ef8e5717db01 ("page cache: Convert delete_batch to XArray")
Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Greg Kroah-Hartman -
commit c36d451ad386b34f452fc3c8621ff14b9eaa31a6 upstream.
Inspired by the recent Coverity report, I looked for other places where
the offset wasn't being converted to an unsigned long before being
shifted, and I found one in xas_pause() when the entry being paused is
of order >32.Fixes: b803b42823d0 ("xarray: Add XArray iterators")
Signed-off-by: Matthew Wilcox (Oracle)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
13 Apr, 2020
1 commit
-
commit d5767057c9a76a29f073dad66b7fa12a90e8c748 upstream.
ext2_swab() is defined locally in lib/find_bit.c However it is not
specific to ext2, neither to bitmaps.There are many potential users of it, so rename it to just swab() and
move to include/uapi/linux/swab.hABI guarantees that size of unsigned long corresponds to BITS_PER_LONG,
therefore drop unneeded cast.Link: http://lkml.kernel.org/r/20200103202846.21616-1-yury.norov@gmail.com
Signed-off-by: Yury Norov
Cc: Allison Randal
Cc: Joe Perches
Cc: Thomas Gleixner
Cc: William Breathitt Gray
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
08 Apr, 2020
1 commit
-
[ Upstream commit bd40b17ca49d7d110adf456e647701ce74de2241 ]
Coverity pointed out that xas_sibling() was shifting xa_offset without
promoting it to an unsigned long first, so the shift could cause an
overflow and we'd get the wrong answer. The fix is obvious, and the
new test-case provokes UBSAN to report an error:
runtime error: shift exponent 60 is too large for 32-bit type 'int'Fixes: 19c30f4dd092 ("XArray: Fix xa_find_after with multi-index entries")
Reported-by: Bjorn Helgaas
Reported-by: Kees Cook
Signed-off-by: Matthew Wilcox (Oracle)
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin
05 Mar, 2020
1 commit
-
commit 7ecaf069da52e472d393f03e79d721aabd724166 upstream.
Currently, some sanity checks for uapi headers are done by
scripts/headers_check.pl, which is wired up to the 'headers_check'
target in the top Makefile.It is true compiling headers has better test coverage, but there
are still several headers excluded from the compile test. I like
to keep headers_check.pl for a while, but we can delete a lot of
code by moving the build rule to usr/include/Makefile.Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman
29 Feb, 2020
1 commit
-
commit 305e519ce48e935702c32241f07d393c3c8fed3e upstream.
Walter Wu has reported a potential case in which init_stack_slab() is
called after stack_slabs[STACK_ALLOC_MAX_SLABS - 1] has already been
initialized. In that case init_stack_slab() will overwrite
stack_slabs[STACK_ALLOC_MAX_SLABS], which may result in a memory
corruption.Link: http://lkml.kernel.org/r/20200218102950.260263-1-glider@google.com
Fixes: cd11016e5f521 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB")
Signed-off-by: Alexander Potapenko
Reported-by: Walter Wu
Cc: Dmitry Vyukov
Cc: Matthias Brugger
Cc: Thomas Gleixner
Cc: Josh Poimboeuf
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
24 Feb, 2020
3 commits
-
[ Upstream commit 4e456fee215677584cafa7f67298a76917e89c64 ]
Clang warns:
../lib/scatterlist.c:314:5: warning: misleading indentation; statement
is not part of the previous 'if' [-Wmisleading-indentation]
return -ENOMEM;
^
../lib/scatterlist.c:311:4: note: previous statement is here
if (prv)
^
1 warning generated.This warning occurs because there is a space before the tab on this
line. Remove it so that the indentation is consistent with the Linux
kernel coding style and clang no longer warns.Link: http://lkml.kernel.org/r/20191218033606.11942-1-natechancellor@gmail.com
Link: https://github.com/ClangBuiltLinux/linux/issues/830
Fixes: edce6820a9fd ("scatterlist: prevent invalid free when alloc fails")
Signed-off-by: Nathan Chancellor
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit 35fd7a637c42bb54ba4608f4d40ae6e55fc88781 ]
The counters obj_pool_free, and obj_nr_tofree, and the flag obj_freeing are
read locklessly outside the pool_lock critical sections. If read with plain
accesses, this would result in data races.This is addressed as follows:
* reads outside critical sections become READ_ONCE()s (pairing with
WRITE_ONCE()s added);* writes become WRITE_ONCE()s (pairing with READ_ONCE()s added); since
writes happen inside critical sections, only the write and not the read
of RMWs needs to be atomic, thus WRITE_ONCE(var, var +/- X) is
sufficient.The data races were reported by KCSAN:
BUG: KCSAN: data-race in __free_object / fill_pool
write to 0xffffffff8beb04f8 of 4 bytes by interrupt on cpu 1:
__free_object+0x1ee/0x8e0 lib/debugobjects.c:404
__debug_check_no_obj_freed+0x199/0x330 lib/debugobjects.c:969
debug_check_no_obj_freed+0x3c/0x44 lib/debugobjects.c:994
slab_free_hook mm/slub.c:1422 [inline]read to 0xffffffff8beb04f8 of 4 bytes by task 1 on cpu 2:
fill_pool+0x3d/0x520 lib/debugobjects.c:135
__debug_object_init+0x3c/0x810 lib/debugobjects.c:536
debug_object_init lib/debugobjects.c:591 [inline]
debug_object_activate+0x228/0x320 lib/debugobjects.c:677
debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline]BUG: KCSAN: data-race in __debug_object_init / fill_pool
read to 0xffffffff8beb04f8 of 4 bytes by task 10 on cpu 6:
fill_pool+0x3d/0x520 lib/debugobjects.c:135
__debug_object_init+0x3c/0x810 lib/debugobjects.c:536
debug_object_init_on_stack+0x39/0x50 lib/debugobjects.c:606
init_timer_on_stack_key kernel/time/timer.c:742 [inline]write to 0xffffffff8beb04f8 of 4 bytes by task 1 on cpu 3:
alloc_object lib/debugobjects.c:258 [inline]
__debug_object_init+0x717/0x810 lib/debugobjects.c:544
debug_object_init lib/debugobjects.c:591 [inline]
debug_object_activate+0x228/0x320 lib/debugobjects.c:677
debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline]BUG: KCSAN: data-race in free_obj_work / free_object
read to 0xffffffff9140c190 of 4 bytes by task 10 on cpu 6:
free_object+0x4b/0xd0 lib/debugobjects.c:426
debug_object_free+0x190/0x210 lib/debugobjects.c:824
destroy_timer_on_stack kernel/time/timer.c:749 [inline]write to 0xffffffff9140c190 of 4 bytes by task 93 on cpu 1:
free_obj_work+0x24f/0x480 lib/debugobjects.c:313
process_one_work+0x454/0x8d0 kernel/workqueue.c:2264
worker_thread+0x9a/0x780 kernel/workqueue.c:2410Reported-by: Qian Cai
Signed-off-by: Marco Elver
Signed-off-by: Thomas Gleixner
Link: https://lore.kernel.org/r/20200116185529.11026-1-elver@google.com
Signed-off-by: Sasha Levin -
[ Upstream commit 5e5ac01c2b8802921fee680518a986011cb59820 ]
The compilation warning is redefination showed as following:
In file included from tables.c:2:
../../../include/linux/export.h:180: warning: "EXPORT_SYMBOL" redefined
#define EXPORT_SYMBOL(sym) __EXPORT_SYMBOL(sym, "")In file included from tables.c:1:
../../../include/linux/raid/pq.h:61: note: this is the location of the previous definition
#define EXPORT_SYMBOL(sym)Fixes: 69a94abb82ee ("export.h, genksyms: do not make genksyms calculate CRC of trimmed symbols")
Signed-off-by: Zhengyuan Liu
Signed-off-by: Song Liu
Signed-off-by: Sasha Levin
11 Feb, 2020
1 commit
-
commit 3e21d9a501bf99aee2e5835d7f34d8c823f115b5 upstream.
In case memory resources for _ptr2_ were allocated, release them before
return.Notice that in case _ptr1_ happens to be NULL, krealloc() behaves
exactly like kmalloc().Addresses-Coverity-ID: 1490594 ("Resource leak")
Link: http://lkml.kernel.org/r/20200123160115.GA4202@embeddedor
Fixes: 3f15801cdc23 ("lib: add kasan test module")
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Dmitry Vyukov
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
06 Feb, 2020
1 commit
-
[ Upstream commit 82a22311b7a68a78709699dc8c098953b70e4fd2 ]
If we were unlucky enough to call xas_pause() when the index was at
ULONG_MAX (or a multi-slot entry which ends at ULONG_MAX), we would
wrap the index back around to 0 and restart the iteration from the
beginning. Use the XAS_BOUNDS state to indicate that we should just
stop the iteration.Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Sasha Levin
29 Jan, 2020
4 commits
-
commit ab10ae1c3bef56c29bac61e1201c752221b87b41 upstream.
The range passed to user_access_begin() by strncpy_from_user() and
strnlen_user() starts at 'src' and goes up to the limit of userspace
although reads will be limited by the 'count' param.On 32 bits powerpc (book3s/32) access has to be granted for each
256Mbytes segment and the cost increases with the number of segments to
unlock.Limit the range with 'count' param.
Fixes: 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'")
Signed-off-by: Christophe Leroy
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit c44aa5e8ab58b5f4cf473970ec784c3333496a2e upstream.
If you call xas_find() with the initial index > max, it should have
returned NULL but was returning the entry at index.Signed-off-by: Matthew Wilcox (Oracle)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 19c30f4dd0923ef191f35c652ee4058e91e89056 upstream.
If the entry is of an order which is a multiple of XA_CHUNK_SIZE,
the current detection of sibling entries does not work. Factor out
an xas_sibling() function to make xa_find_after() a little more
understandable, and write a new implementation that doesn't suffer from
the same bug.Signed-off-by: Matthew Wilcox (Oracle)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 430f24f94c8a174d411a550d7b5529301922e67a upstream.
If there is an entry at ULONG_MAX, xa_for_each() will overflow the
'index + 1' in xa_find_after() and wrap around to 0. Catch this case
and terminate the loop by returning NULL.Signed-off-by: Matthew Wilcox (Oracle)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2020
1 commit
-
[ Upstream commit df034c93f15ee71df231ff9fe311d27ff08a2a52 ]
Under heavy loads where the kyber I/O scheduler hits the token limits for
its scheduling domains, kyber can become stuck. When active requests
complete, kyber may not be woken up leaving the I/O requests in kyber
stuck.This stuck state is due to a race condition with kyber and the sbitmap
functions it uses to run a callback when enough requests have completed.
The running of a sbt_wait callback can race with the attempt to insert the
sbt_wait. Since sbitmap_del_wait_queue removes the sbt_wait from the list
first then sets the sbq field to NULL, kyber can see the item as not on a
list but the call to sbitmap_add_wait_queue will see sbq as non-NULL. This
results in the sbt_wait being inserted onto the wait list but ws_active
doesn't get incremented. So the sbitmap queue does not know there is a
waiter on a wait list.Since sbitmap doesn't think there is a waiter, kyber may never be
informed that there are domain tokens available and the I/O never advances.
With the sbt_wait on a wait list, kyber believes it has an active waiter
so cannot insert a new waiter when reaching the domain's full state.This race can be fixed by only adding the sbt_wait to the queue if the
sbq field is NULL. If sbq is not NULL, there is already an action active
which will trigger the re-running of kyber. Let it run and add the
sbt_wait to the wait list if still needing to wait.Reviewed-by: Omar Sandoval
Signed-off-by: David Jeffery
Reported-by: John Pittman
Tested-by: John Pittman
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
09 Jan, 2020
1 commit
-
[ Upstream commit ce5c31db3645b649a31044a4d8b6057f6c723702 ]
At the moment, UBSAN report will be serialized using a spin_lock(). On
RT-systems, spinlocks are turned to rt_spin_lock and may sleep. This
will result to the following splat if the undefined behavior is in a
context that can sleep:BUG: sleeping function called from invalid context at /src/linux/kernel/locking/rtmutex.c:968
in_atomic(): 1, irqs_disabled(): 128, pid: 3447, name: make
1 lock held by make/3447:
#0: 000000009a966332 (&mm->mmap_sem){++++}, at: do_page_fault+0x140/0x4f8
irq event stamp: 6284
hardirqs last enabled at (6283): [] _raw_spin_unlock_irqrestore+0x90/0xa0
hardirqs last disabled at (6284): [] _raw_spin_lock_irqsave+0x30/0x78
softirqs last enabled at (2430): [] fpsimd_restore_current_state+0x60/0xe8
softirqs last disabled at (2427): [] fpsimd_restore_current_state+0x28/0xe8
Preemption disabled at:
[] rt_mutex_futex_unlock+0x4c/0xb0
CPU: 3 PID: 3447 Comm: make Tainted: G W 5.2.14-rt7-01890-ge6e057589653 #911
Call trace:
dump_backtrace+0x0/0x148
show_stack+0x14/0x20
dump_stack+0xbc/0x104
___might_sleep+0x154/0x210
rt_spin_lock+0x68/0xa0
ubsan_prologue+0x30/0x68
handle_overflow+0x64/0xe0
__ubsan_handle_add_overflow+0x10/0x18
__lock_acquire+0x1c28/0x2a28
lock_acquire+0xf0/0x370
_raw_spin_lock_irqsave+0x58/0x78
rt_mutex_futex_unlock+0x4c/0xb0
rt_spin_unlock+0x28/0x70
get_page_from_freelist+0x428/0x2b60
__alloc_pages_nodemask+0x174/0x1708
alloc_pages_vma+0x1ac/0x238
__handle_mm_fault+0x4ac/0x10b0
handle_mm_fault+0x1d8/0x3b0
do_page_fault+0x1c8/0x4f8
do_translation_fault+0xb8/0xe0
do_mem_abort+0x3c/0x98
el0_da+0x20/0x24The spin_lock() will protect against multiple CPUs to output a report
together, I guess to prevent them from being interleaved. However, they
can still interleave with other messages (and even splat from
__might_sleep).So the lock usefulness seems pretty limited. Rather than trying to
accomodate RT-system by switching to a raw_spin_lock(), the lock is now
completely dropped.Link: http://lkml.kernel.org/r/20190920100835.14999-1-julien.grall@arm.com
Signed-off-by: Julien Grall
Reported-by: Andre Przywara
Acked-by: Andrey Ryabinin
Cc: Thomas Gleixner
Cc: Sebastian Andrzej Siewior
Cc: Steven Rostedt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
31 Dec, 2019
1 commit
-
[ Upstream commit 9a50dcaf0416a43e1fe411dc61a99c8333c90119 ]
The new check_zeroed_user() function uses variable shifts inside of a
user_access_begin()/user_access_end() section and that results in GCC
emitting __ubsan_handle_shift_out_of_bounds() calls, even though
through value range analysis it would be able to see that the UB in
question is impossible.Annotate and whitelist this UBSAN function; continued use of
user_access_begin()/user_access_end() will undoubtedly result in
further uses of function.Reported-by: Randy Dunlap
Tested-by: Randy Dunlap
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Randy Dunlap
Acked-by: Christian Brauner
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephen Rothwell
Cc: Thomas Gleixner
Cc: cyphar@cyphar.com
Cc: keescook@chromium.org
Cc: linux@rasmusvillemoes.dk
Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
Link: https://lkml.kernel.org/r/20191021131149.GA19358@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
18 Dec, 2019
1 commit
-
commit 702600eef73033ddd4eafcefcbb6560f3e3a90f7 upstream.
Newer versions of awk spit out these fun warnings:
awk: ../lib/raid6/unroll.awk:16: warning: regexp escape sequence `\#' is not a known regexp operatorAs commit 700c1018b86d ("x86/insn: Fix awk regexp warnings") showed, it
turns out that there are a number of awk strings that do not need to be
escaped and newer versions of awk now warn about this.Fix the string up so that no warning is produced. The exact same kernel
module gets created before and after this patch, showing that it wasn't
needed.Link: https://lore.kernel.org/r/20191206152600.GA75093@kroah.com
Signed-off-by: Greg Kroah-Hartman
16 Nov, 2019
1 commit
-
s->dict.allocated was initialized to 0 but never set after a successful
allocation, thus the code always thought that the dictionary buffer has
to be reallocated.Link: http://lkml.kernel.org/r/20191104185107.3b6330df@tukaani.org
Signed-off-by: Lasse Collin
Reported-by: Yu Sun
Acked-by: Daniel Walker
Cc: "Yixia Si (yisi)"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Nov, 2019
1 commit
-
config option GENERIC_IO was removed but still selected by lib/kconfig
This patch finish the cleaning.Fixes: 9de8da47742b ("kconfig: kill off GENERIC_IO option")
Acked-by: Rob Herring
Signed-off-by: Corentin Labbe
Signed-off-by: Linus Torvalds
09 Nov, 2019
1 commit
-
Pull XArray fixes from Matthew Wilcox:
"These all fix various bugs, some of which people have tripped over and
some of which have been caught by automatic tools"* tag 'xarray-5.4' of git://git.infradead.org/users/willy/linux-dax:
idr: Fix idr_alloc_u32 on 32-bit systems
idr: Fix integer overflow in idr_for_each_entry
radix tree: Remove radix_tree_iter_find
idr: Fix idr_get_next_ul race with idr_remove
XArray: Fix xas_next() with a single entry at 0
07 Nov, 2019
1 commit
-
In the current code, we use the atomic_cmpxchg() to serialize the output
of the dump_stack(), but this implementation suffers the thundering herd
problem. We have observed such kind of livelock on a Marvell cn96xx
board(24 cpus) when heavily using the dump_stack() in a kprobe handler.
Actually we can let the competitors to wait for the releasing of the
lock before jumping to atomic_cmpxchg(). This will definitely mitigate
the thundering herd problem. Thanks Linus for the suggestion.[akpm@linux-foundation.org: fix comment]
Link: http://lkml.kernel.org/r/20191030031637.6025-1-haokexin@gmail.com
Fixes: b58d977432c8 ("dump_stack: serialize the output from dump_stack()")
Signed-off-by: Kevin Hao
Suggested-by: Linus Torvalds
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
03 Nov, 2019
1 commit
-
Attempting to allocate an entry at 0xffffffff when one is already
present would succeed in allocating one at 2^32, which would confuse
everything. Return -ENOSPC in this case, as expected.Signed-off-by: Matthew Wilcox (Oracle)
02 Nov, 2019
1 commit
-
Commit 5c089fd0c734 ("idr: Fix idr_get_next race with idr_remove")
neglected to fix idr_get_next_ul(). As far as I can tell, nobody's
actually using this interface under the RCU read lock, but fix it now
before anybody decides to use it.Fixes: 5c089fd0c734 ("idr: Fix idr_get_next race with idr_remove")
Signed-off-by: Matthew Wilcox (Oracle)
23 Oct, 2019
1 commit
-
A recent commit removed the NULL pointer check from the clock_getres()
implementation causing a test case to fault.POSIX requires an explicit NULL pointer check for clock_getres() aside of
the validity check of the clock_id argument for obscure reasons.Add it back for both 32bit and 64bit.
Note, this is only a partial revert of the offending commit which does not
bring back the broken fallback invocation in the the 32bit compat
implementations of clock_getres() and clock_gettime().Fixes: a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL pointer checks")
Reported-by: Andreas Schwab
Signed-off-by: Thomas Gleixner
Tested-by: Christophe Leroy
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1910211202260.1904@nanos.tec.linutronix.de
19 Oct, 2019
1 commit
-
…kernel/git/brauner/linux
Pull usercopy test fixlets from Christian Brauner:
"This contains two improvements for the copy_struct_from_user() tests:- a coding style change to get rid of the ugly "if ((ret |= test()))"
pointed out when pulling the original patchset.- avoid a soft lockups when running the usercopy tests on machines
with large page sizes by scanning only a 1024 byte region"* tag 'copy-struct-from-user-v5.4-rc4' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux:
usercopy: Avoid soft lockups in test_check_nonzero_user()
lib: test_user_copy: style cleanup
16 Oct, 2019
1 commit
-
On a machine with a 64K PAGE_SIZE, the nested for loops in
test_check_nonzero_user() can lead to soft lockups, eg:watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [modprobe:611]
Modules linked in: test_user_copy(+) vmx_crypto gf128mul crc32c_vpmsum virtio_balloon ip_tables x_tables autofs4
CPU: 4 PID: 611 Comm: modprobe Tainted: G L 5.4.0-rc1-gcc-8.2.0-00001-gf5a1a536fa14-dirty #1151
...
NIP __might_sleep+0x20/0xc0
LR __might_fault+0x40/0x60
Call Trace:
check_zeroed_user+0x12c/0x200
test_user_copy_init+0x67c/0x1210 [test_user_copy]
do_one_initcall+0x60/0x340
do_init_module+0x7c/0x2f0
load_module+0x2d94/0x30e0
__do_sys_finit_module+0xc8/0x150
system_call+0x5c/0x68Even with a 4K PAGE_SIZE the test takes multiple seconds. Instead
tweak it to only scan a 1024 byte region, but make it cross the
page boundary.Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
Suggested-by: Aleksa Sarai
Signed-off-by: Michael Ellerman
Reviewed-by: Aleksa Sarai
Acked-by: Christian Brauner
Link: https://lore.kernel.org/r/20191016122732.13467-1-mpe@ellerman.id.au
Signed-off-by: Christian Brauner
15 Oct, 2019
2 commits
-
Make sure allocations from kmem_cache_alloc_bulk() and
kmem_cache_free_bulk() are properly initialized.Link: http://lkml.kernel.org/r/20191007091605.30530-2-glider@google.com
Signed-off-by: Alexander Potapenko
Cc: Kees Cook
Cc: Christoph Lameter
Cc: Laura Abbott
Cc: Thibaut Sautereau
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Kmemleak is falsely reporting a leak of the slab allocation in
sctp_stream_init_ext():BUG: memory leak
unreferenced object 0xffff8881114f5d80 (size 96):
comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
[] slab_post_alloc_hook mm/slab.h:439 [inline]
[] slab_alloc mm/slab.c:3326 [inline]
[] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
[] kmalloc include/linux/slab.h:547 [inline]
[] kzalloc include/linux/slab.h:742 [inline]
[] sctp_stream_init_ext+0x2b/0xa0 net/sctp/stream.c:157
[] sctp_sendmsg_to_asoc+0x946/0xa00 net/sctp/socket.c:1882
[] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102
[...]But it's freed later. Kmemleak misses the allocation because its
pointer is stored in the generic radix tree sctp_stream::out, and the
generic radix tree uses raw pages which aren't tracked by kmemleak.Fix this by adding the kmemleak hooks to the generic radix tree code.
Link: http://lkml.kernel.org/r/20191004065039.727564-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers
Reported-by:
Reviewed-by: Marcelo Ricardo Leitner
Acked-by: Neil Horman
Reviewed-by: Catalin Marinas
Cc: Kent Overstreet
Cc: Vlad Yasevich
Cc: Xin Long
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
