linux-stable.git/lib, branch linux-5.14.y

dyndbg: make dyndbg a known cli param

2021-11-17T10:04:26+00:00

[ Upstream commit 5ca173974888368fecfb17ae6fe455df5fd2a9d2 ]

Right now dyndbg shows up as an unknown parameter if used on boot:

    Unknown command line parameters: dyndbg=+p

That's because it is unknown, it doesn't sit in the __param
section, so the processing done to warn users supplying an unknown
parameter doesn't think it is legitimate.

Install a dummy handler to register it. dynamic debug needs to search
the whole command line for modules listed that are currently builtin,
so there's no real work to be done in this callback.

Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters")
Tested-by: Jim Cromie 
Signed-off-by: Andrew Halaney 
Signed-off-by: Jason Baron 
Link: https://lore.kernel.org/r/1634139622-20667-2-git-send-email-jbaron@akamai.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

lib/xz: Validate the value before assigning it to an enum variable

2021-11-17T10:03:52+00:00

[ Upstream commit 4f8d7abaa413c34da9d751289849dbfb7c977d05 ]

This might matter, for example, if the underlying type of enum xz_check
was a signed char. In such a case the validation wouldn't have caught an
unsupported header. I don't know if this problem can occur in the kernel
on any arch but it's still good to fix it because some people might copy
the XZ code to their own projects from Linux instead of the upstream
XZ Embedded repository.

This change may increase the code size by a few bytes. An alternative
would have been to use an unsigned int instead of enum xz_check but
using an enumeration looks cleaner.

Link: https://lore.kernel.org/r/20211010213145.17462-3-xiang@kernel.org
Signed-off-by: Lasse Collin 
Signed-off-by: Gao Xiang 
Signed-off-by: Sasha Levin

lib/xz: Avoid overlapping memcpy() with invalid input with in-place decompression

2021-11-17T10:03:52+00:00

[ Upstream commit 83d3c4f22a36d005b55f44628f46cc0d319a75e8 ]

With valid files, the safety margin described in lib/decompress_unxz.c
ensures that these buffers cannot overlap. But if the uncompressed size
of the input is larger than the caller thought, which is possible when
the input file is invalid/corrupt, the buffers can overlap. Obviously
the result will then be garbage (and usually the decoder will return
an error too) but no other harm will happen when such an over-run occurs.

This change only affects uncompressed LZMA2 chunks and so this
should have no effect on performance.

Link: https://lore.kernel.org/r/20211010213145.17462-2-xiang@kernel.org
Signed-off-by: Lasse Collin 
Signed-off-by: Gao Xiang 
Signed-off-by: Sasha Levin

iov_iter: Fix iov_iter_get_pages{,_alloc} page fault return value

2021-11-17T10:03:50+00:00

[ Upstream commit 814a66741b9ffb5e1ba119e368b178edb0b7322d ]

Both iov_iter_get_pages and iov_iter_get_pages_alloc return the number
of bytes of the iovec they could get the pages for.  When they cannot
get any pages, they're supposed to return 0, but when the start of the
iovec isn't page aligned, the calculation goes wrong and they return a
negative value.  Fix both functions.

In addition, change iov_iter_get_pages_alloc to return NULL in that case
to prevent resource leaks.

Signed-off-by: Andreas Gruenbacher 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

bitfield: build kunit tests without structleak plugin

2021-10-27T07:59:50+00:00

[ Upstream commit a8cf90332ae3e2b53813a146a99261b6a5e16a73 ]

The structleak plugin causes the stack frame size to grow immensely:

lib/bitfield_kunit.c: In function 'test_bitfields_constants':
lib/bitfield_kunit.c:93:1: error: the frame size of 7440 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

Turn it off in this file.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Brendan Higgins 
Reviewed-by: Kees Cook 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

kunit: fix reference count leak in kfree_at_end

2021-10-27T07:59:49+00:00

[ Upstream commit f62314b1ced25c58b86e044fc951cd6a1ea234cf ]

The reference counting issue happens in the normal path of
kfree_at_end(). When kunit_alloc_and_get_resource() is invoked, the
function forgets to handle the returned resource object, whose refcount
increased inside, causing a refcount leak.

Fix this issue by calling kunit_alloc_resource() instead of
kunit_alloc_and_get_resource().

Fixed the following when applying:
Shuah Khan 

CHECK: Alignment should match open parenthesis
+	kunit_alloc_resource(test, NULL, kfree_res_free, GFP_KERNEL,
 				     (void *)to_free);

Signed-off-by: Xiyu Yang 
Signed-off-by: Xin Tan 
Reviewed-by: Daniel Latypov 
Reviewed-by: Brendan Higgins 
Signed-off-by: Shuah Khan 
Signed-off-by: Sasha Levin

kasan: fix Kconfig check of CC_HAS_WORKING_NOSANITIZE_ADDRESS

2021-10-07T05:53:04+00:00

[ Upstream commit fa360beac4b62d54879a88b182afef4b369c9700 ]

In the main KASAN config option CC_HAS_WORKING_NOSANITIZE_ADDRESS is
checked for instrumentation-based modes.  However, if
HAVE_ARCH_KASAN_HW_TAGS is true all modes may still be selected.

To fix, also make the software modes depend on
CC_HAS_WORKING_NOSANITIZE_ADDRESS.

Link: https://lkml.kernel.org/r/20210910084240.1215803-1-elver@google.com
Fixes: 6a63a63ff1ac ("kasan: introduce CONFIG_KASAN_HW_TAGS")
Signed-off-by: Marco Elver 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Dmitry Vyukov 
Cc: Aleksandr Nogikh 
Cc: Taras Madan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

Kconfig.debug: drop selecting non-existing HARDLOCKUP_DETECTOR_ARCH

2021-09-26T12:10:19+00:00

[ Upstream commit 6fe26259b4884b657cbc233fb9cdade9d704976e ]

Commit 05a4a9527931 ("kernel/watchdog: split up config options") adds a
new config HARDLOCKUP_DETECTOR, which selects the non-existing config
HARDLOCKUP_DETECTOR_ARCH.

Hence, ./scripts/checkkconfigsymbols.py warns:

HARDLOCKUP_DETECTOR_ARCH Referencing files: lib/Kconfig.debug

Simply drop selecting the non-existing HARDLOCKUP_DETECTOR_ARCH.

Link: https://lkml.kernel.org/r/20210806115618.22088-1-lukas.bulwahn@gmail.com
Fixes: 05a4a9527931 ("kernel/watchdog: split up config options")
Signed-off-by: Lukas Bulwahn 
Cc: Nicholas Piggin 
Cc: Masahiro Yamada 
Cc: Babu Moger 
Cc: Don Zickus 
Cc: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

math: RATIONAL_KUNIT_TEST should depend on RATIONAL instead of selecting it

2021-09-26T12:10:19+00:00

[ Upstream commit 8ba739ede49dec361ddcb70afe24986b4b8cfe17 ]

RATIONAL_KUNIT_TEST selects RATIONAL, thus enabling an optional feature
the user may not want to have enabled.  Fix this by making the test depend
on RATIONAL instead.

Link: https://lkml.kernel.org/r/20210706100945.3803694-3-geert@linux-m68k.org
Fixes: b6c75c4afceb8bc0 ("lib/math/rational: add Kunit test cases")
Signed-off-by: Geert Uytterhoeven 
Cc: Andy Shevchenko 
Cc: Brendan Higgins 
Cc: Colin Ian King 
Cc: Trent Piepho 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

lib/test_stackinit: Fix static initializer test

2021-09-18T11:44:03+00:00

commit f9398f15605a50110bf570aaa361163a85113dd1 upstream.

The static initializer test got accidentally converted to a dynamic
initializer. Fix this and retain the giant padding hole without using
an aligned struct member.

Fixes: 50ceaa95ea09 ("lib: Introduce test_stackinit module")
Cc: Ard Biesheuvel 
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20210723221933.3431999-2-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman