| Age | Commit message (Collapse) | Author |
|---|
|
This is the 5.15.154 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmYWoCsACgkQONu9yGCS
# aT4kexAAq18sMargvRMhSjsMtcrT8A/a9riOcjRjf60TfJOPSMYsHSx5rc7wuOr5
# j7LenaBJLR1nbBYuxzmH+RlXHI9CNqp24UHup6Qj8KeAxW9efkEP2Q27Dylk+Lke
# XA7lnC2xceS/eCU1uNtYLjnzc2FfxpOdYlAAaNbxIhbn3Z2yomWD3FcwJyVAPdU1
# gl8TWqMFG+RDYy3xB8zE/AV+9J1X1UQgjhOX+uMOwmb8XBJl4GCSDNMMTf62XqfZ
# g0Y5y+h/9nhT4esDrkWQkUd9P//3oyVJ/z2CdsiJ9wJXjHJSOmna/MbZEJjkTUzH
# pxrYWNSCoMLpWxy8f9ajbFoOnDN7pAAuShNEFzFqjUEx06UdvTEG/osPSCFHCwpr
# 3HdsiPCkjalyK9NESLAKj6s99A0CN7vUT1QeJsXwLcYlAs7TBnC9ITMa2DpvjZ2k
# 7flENlsIrZHfLjEre7Wt28AlDYECkHEHr01W3J2Tz15K2F3telmsUd6jnVKyqmjC
# 6NkVQUUqflTtc9fjUBxSqKGmGcCwMEzcy74AG03B3Rf7etCGWdyFglhLW7Ce1600
# +b9rNjHEcnTfaOQ1Z2iD8yC2leGUaedbIpmmtUwqPS4RcKzbLV8Fs8yOYlD13jPO
# CH9qc8yhA5BWf2+kZiiyTLeQY5mhvTfhHL1UADkCjk+phQsq7Sk=
# =dFke
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 10 Apr 2024 10:20:27 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit d49a0626216b95cd4bf696f6acf55f39a16ab0bb upstream.
Generic function-alignment infrastructure.
Architectures can select FUNCTION_ALIGNMENT_xxB symbols; the
FUNCTION_ALIGNMENT symbol is then set to the largest such selected
size, 0 otherwise.
>From this the -falign-functions compiler argument and __ALIGN macro
are set.
This incorporates the DEBUG_FORCE_FUNCTION_ALIGN_64B knob and future
alignment requirements for x86_64 (later in this series) into a single
place.
NOTE: also removes the 0x90 filler byte from the generic __ALIGN
primitive, that value makes no sense outside of x86.
NOTE: .balign 0 reverts to a no-op.
Requested-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: I053b3c408d56988381feb8c8bdb5e27ea221755f
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220915111143.719248727@infradead.org
[cascardo: adjust context at arch/x86/Kconfig]
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit e10aea105e9ed14b62a11844fec6aaa87c6935a3 ]
The out-of-bounds test allocates an object that is three bytes too short
in order to validate the bounds checking. Starting with gcc-14, this
causes a compile-time warning as gcc has grown smart enough to understand
the sizeof() logic:
mm/kasan/kasan_test.c: In function 'kmalloc_oob_16':
mm/kasan/kasan_test.c:443:14: error: allocation of insufficient size '13' for type 'struct <anonymous>' with size '16' [-Werror=alloc-size]
443 | ptr1 = kmalloc(sizeof(*ptr1) - 3, GFP_KERNEL);
| ^
Hide the actual computation behind a RELOC_HIDE() that ensures
the compiler misses the intentional bug.
Link: https://lkml.kernel.org/r/20240212111609.869266-1-arnd@kernel.org
Fixes: 3f15801cdc23 ("lib: add kasan test module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 758cabae312d3aded781aacc6d0c946b299c52df ]
With HW tag-based KASAN, error checks are performed implicitly by the
load and store instructions in the memcpy implementation. A failed
check results in tag checks being disabled and execution will keep
going. As a result, under HW tag-based KASAN, prior to commit
1b0668be62cf ("kasan: test: disable kmalloc_memmove_invalid_size for
HW_TAGS"), this memcpy would end up corrupting memory until it hits an
inaccessible page and causes a kernel panic.
This is a pre-existing issue that was revealed by commit 285133040e6c
("arm64: Import latest memcpy()/memmove() implementation") which changed
the memcpy implementation from using signed comparisons (incorrectly,
resulting in the memcpy being terminated early for negative sizes) to
using unsigned comparisons.
It is unclear how this could be handled by memcpy itself in a reasonable
way. One possibility would be to add an exception handler that would
force memcpy to return if a tag check fault is detected -- this would
make the behavior roughly similar to generic and SW tag-based KASAN.
However, this wouldn't solve the problem for asynchronous mode and also
makes memcpy behavior inconsistent with manually copying data.
This test was added as a part of a series that taught KASAN to detect
negative sizes in memory operations, see commit 8cceeff48f23 ("kasan:
detect negative size in memory operation function"). Therefore we
should keep testing for negative sizes with generic and SW tag-based
KASAN. But there is some value in testing small memcpy overflows, so
let's add another test with memcpy that does not destabilize the kernel
by performing out-of-bounds writes, and run it in all modes.
Link: https://linux-review.googlesource.com/id/I048d1e6a9aff766c4a53f989fb0c83de68923882
Link: https://lkml.kernel.org/r/20210910211356.3603758-1-pcc@google.com
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Acked-by: Marco Elver <elver@google.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Evgenii Stepanov <eugenis@google.com>
Cc: Alexander Potapenko <glider@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Stable-dep-of: e10aea105e9e ("kasan/test: avoid gcc warning for intentional overflow")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7626913652cc786c238e2dd7d8740b17d41b2637 ]
The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(),
which means MMIO mappings are leaked.
Move the guard so we call iounmap() for MMIO mappings.
Fixes: 316e8d79a095 ("pci_iounmap'2: Electric Boogaloo: try to make sense of it all")
Link: https://lore.kernel.org/r/20240131090023.12331-2-pstanner@redhat.com
Reported-by: Danilo Krummrich <dakr@redhat.com>
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: <stable@vger.kernel.org> # v5.15+
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
Linux 5.15.153
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmYDTp4ACgkQ3qZv95d3
# LNytng/+LA5JjTwpYPtEJVEdEo2RIAZHC8BXmgSVclP7nskYDQL+P70G3FdDvJQT
# DS90xLpuyrJsYVbro9dhJ7+nkc5c62043t46fZdOfSh4jqq1oj7TQ8HLLqnOzaqu
# 5/C5YSDDxqoiUsG8IgUg9qlBQATpKlD2/gEY7Vl6JL1xsatviCX5Slnrlm2MC6rZ
# Ojv3ROKOk9OHfdwRi9RYUvH+Q05Wh/bkv4ZGJwhlGb3YbuKeYHqiS1Bpvo9BVpG7
# 7kZPOFhhcJ2RZ2zdcCpwTMWgiTEZV4CtL8to0pHoDs2/wswv8arDMyE+LXr8iQIj
# XYyyLuDParb9lJzr5PgvN8CFlF2EktrycsaT0Jk4ekiUQsdq4bvyKpBkbv1HtPm1
# MpkH58xQf590A7k+wki0WQI8Q4oLmWCbzkdw2LIbojISa5Tza9ivq6pcMBaugRTY
# DXpphQuw9ScT35yrXdaPLnjc/PpNIjxqCcSvcewfOggfaU13kghfmaANiBvjLSJs
# R91tHo26P3I1li3YvI4dc5rq8AIJhFwvcqsQ6Uv7pkc1pR6H1viIBJMb68swRFL4
# 4imFR5gCLuoks8lIVcDLNNebnbmzu7Fhdh42asQMRajSDY/TqlSO7g+QiAd/nK/x
# GVV+RFxAvadYO2yQqdpKL68EOnhSl/b+t0T2EpKsPDSdEATsFdo=
# =KytE
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 26 Mar 2024 06:39:26 PM EDT
# gpg: using RSA key E27E5D8A3403A2EF66873BBCDEA66FF797772CDC
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 843a8851e89e2e85db04caaf88d8554818319047 ]
lib/test_blackhole_dev.c sets a variable that is never read, causing
this following building warning:
lib/test_blackhole_dev.c:32:17: warning: variable 'ethh' set but not used [-Wunused-but-set-variable]
Remove the variable struct ethhdr *ethh, which is unused.
Fixes: 509e56b37cc3 ("blackhole_dev: add a selftest")
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d2733a026fc7247ba42d7a8e1b737cf14bf1df21 ]
The correct format specifier for p - n (both p and n are pointers) is
%td, as the type should be ptrdiff_t.
This was discovered by annotating KUnit assertion macros with gcc's
printf specifier, but note that gcc incorrectly suggested a %d or %ld
specifier (depending on the pointer size of the architecture being
built).
Fixes: 0ea09083116d ("lib/cmdline: Allow get_options() to take 0 to validate the input")
Signed-off-by: David Gow <davidgow@google.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Daniel Latypov <dlatypov@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.15.150 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXhyIMACgkQONu9yGCS
# aT5h3hAAjwfrpfkyZCFnYb5KWR06B1quaY2u0Tw5wKoLvtIhbnxBeNW0w+YuXr2p
# GV6Dlozx4RnRdnJFIs0R98APPgw7SY8QRfPTsr2xoMr96FUg6VFuZFv4HyRBbDac
# NqKOVQvWXGgC/56uGnw1IcewUcZtmT/QfwthEtfjfBzKdqJC0HnGhSGPDUeimw9k
# h9jghsdWYZB4ykMSz22VngsztJJ60t5EAlwEMueBQsQeRPODcvGE1va9Jlpgjw66
# D4e6+ZGosQP/f9lezvYiESV1dzSRUTpgyl8wky3hSoYQmSBMi6BHq2v6ECn9t2LK
# bVMVRzY+OK1AHXzkxHsb/QhHJfS4YNbHmFzpHVenf6I/VsFsxwtKeoT23PCeAMqh
# 72v2RnJNDCSdydb3iYKx8s7hpkWumPS4LS0EOEh64+gFo/+TfMyWqIeSJfGmyhx8
# 60DX4FLWjqymP96OU7UjbvnlBhGlL2OmoDzgxGaQ9jFH3Kfmx30yMY3RtIb3Qhic
# OiATTmRmRwICUYNskXn3e1jFVW/2a/aEEanCqEi2xBCzGMSzqeAw4hv9EIZOgVcE
# FC3a09HpR4G4xP57ZYcz4Dry9xs8HoJJrAQwUUJ6X7SqHZWaiSt92ZblebLeaAbH
# uo+PFmG7m9HSv/s66JB5+fW7H6RRnM+ozJ91Iy5N3T356n03N2o=
# =hhwy
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 01 Mar 2024 07:22:27 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 8b64d420fe2450f82848178506d3e3a0bd195539 ]
syzbot is reporting false a positive ODEBUG message immediately after
ODEBUG was disabled due to OOM.
[ 1062.309646][T22911] ODEBUG: Out of memory. ODEBUG disabled
[ 1062.886755][ T5171] ------------[ cut here ]------------
[ 1062.892770][ T5171] ODEBUG: assert_init not available (active state 0) object: ffffc900056afb20 object type: timer_list hint: process_timeout+0x0/0x40
CPU 0 [ T5171] CPU 1 [T22911]
-------------- --------------
debug_object_assert_init() {
if (!debug_objects_enabled)
return;
db = get_bucket(addr);
lookup_object_or_alloc() {
debug_objects_enabled = 0;
return NULL;
}
debug_objects_oom() {
pr_warn("Out of memory. ODEBUG disabled\n");
// all buckets get emptied here, and
}
lookup_object_or_alloc(addr, db, descr, false, true) {
// this bucket is already empty.
return ERR_PTR(-ENOENT);
}
// Emits false positive warning.
debug_print_object(&o, "assert_init");
}
Recheck debug_object_enabled in debug_print_object() to avoid that.
Reported-by: syzbot <syzbot+7937ba6a50bdd00fffdf@syzkaller.appspotmail.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/492fe2ae-5141-d548-ebd5-62f5fe2e57f7@I-love.SAKURA.ne.jp
Closes: https://syzkaller.appspot.com/bug?extid=7937ba6a50bdd00fffdf
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.15.149 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXYT2wACgkQONu9yGCS
# aT6i6w//WPR54VwLS08xIhUBZlaUbSxtQW4IASxE87RklBpl60NvxGQjYpmRTuim
# 428ek+PI6qLJnQpESN4s4zf2/q2+VUmbp98Bib4Yi2AtO0GRlk9kg10CA+Rda32l
# qddiOpjIZfW2PkxegZ2tE29plgDQT3GWWjaDVSuZMvTVJmftvw6j4A0T9QiXeXOo
# jGWzzQSOhbebKxXeSnecNg9CFGmzt9YeiJOPO05f67c8MK9JurF6WxkCVZ9VxF2b
# INF21WUqKRB7gNdsJQb8sbaf0sjnVMOpP1lTjcU/IFEKmriVyT/ImyX9KPS3p7cj
# 3ZAIZzmCVSM/ATYJm52p31QhytGHe45qf6knr2GQ/FJOhQxsGHKtj47zao9lo2Hi
# /JpvyVnh1dWmcv2LtrDPjmRf/QnixVX3Kp/mn4zamp9n7/DqsJ14DSwf4plo/d7d
# jN41GBb69e8kI+9rB8uK6pD8ua+gmXaIJW6DF4SySzovG4WYKE88xecrsmegSlOH
# AOlr3JWzRE0PW3JHkk9Jc0ZPJrHivp1jv7RPS8i0A1JT+/dFx/B/BdDwhNLX3P/w
# ysLaxaF9BAB4+5O6CsW6U0y9CFEZgbBKsVJu5ZY6rvZA8YDPgcfoUB5bZKRnWYcz
# Menq1D7tr8hZbQWXbOgu/XyNJJXMl3C2b/j2V2GpNybVm/uXQrs=
# =HI6Z
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 23 Feb 2024 02:55:24 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit ba3c5574203034781ac4231acf117da917efcd2a ]
When the mpi_ec_ctx structure is initialized, some fields are not
cleared, causing a crash when referencing the field when the
structure was released. Initially, this issue was ignored because
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
For example, this error will be triggered when calculating the
Za value for SM2 separately.
Fixes: d58bb7e55a8a ("lib/mpi: Introduce ec implementation to MPI library")
Cc: stable@vger.kernel.org # v6.5
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 9bb6362652f3f4d74a87d572a91ee1b38e673ef6 ]
After release of the hashbucket lock the tracking object can be modified or
freed by a concurrent thread. Using it in such a case is error prone, even
for printing the object state:
1. T1 tries to deactivate destroyed object, debugobjects detects it,
hash bucket lock is released.
2. T2 preempts T1 and frees the tracking object.
3. The freed tracking object is allocated and initialized for a
different to be tracked kernel object.
4. T1 resumes and reports error for wrong kernel object.
Create a local copy of the tracking object before releasing the hash bucket
lock and use the local copy for reporting and fixups to prevent this.
Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20231025-debugobjects_fix-v3-1-2bc3bf7084c2@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.15.148 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWy5lAACgkQONu9yGCS
# aT7qwRAAl0pWI9Dwywt2Yn7Rd350Vz974RsctlTWtheBztaZ/589Vdj4xO6do3A1
# FWjG0bWBibs1TnfazplWNSApxHy+eYnxwiWUzxPDhJnRJGp4I0NBsnCkRjNCVRqN
# xlXvzc6vwdnNs9enX/NSTUvA3+AkHRURJbPO5MJypmFL6+eR6SibTBWRwsLZGtTR
# KB9OZZM8UFwH5DPO0VYEVqyfBeehXCM3FukQ5M/2QjRTPpu8PyX1hNOu3rGak/jr
# bnL4AdHG3RcdbKc6r3nMSzW3ep0nJ3pgi2eZlH6QsV+fBxiuw6vdzk9LwUhc1ggR
# DaFlPbczM6hSkLW06zI2Z8cmkLlWfR3zINin+Y4CM0Tl5CSjW9gImj9XqP97Oenc
# H5P72ErFx0U9sNmkmr2KR3MiRP1ESLxgc2dwJc5AAJHT75WZO6fZiEXnKVH9sf6M
# pXNu7GiGcW+2kwnVInUxce3CaoTYtCFjrYmVJ7c+GSseMpgKneXSTARr6Kd3HtBS
# F7R6Uwqy/I6m0JtXYpLbc9TGXypzVygLMTZBbxAU9KOfaaWhbyVWw73dmP5EZQGr
# GSHysnBGTX0liUxbEVisS/0ClFsb2ws1BSSiJ9TaaOVyg7f9xC0R/17C9jUSaQOS
# QCwIPdQuKsLs4zM3IuWGi7vlSFYkEz4VljC4abe3OfkptjoozdI=
# =hc5X
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 25 Jan 2024 05:53:04 PM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 34dfd5bb2e5507e69d9b6d6c90f546600c7a4977 ]
Move the call to kunit_suite_has_succeeded() after the check that
the kunit_suite pointer is valid.
This was found by smatch:
lib/kunit/debugfs.c:66 debugfs_print_results() warn: variable
dereferenced before check 'suite' (see line 63)
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: 38289a26e1b8 ("kunit: fix debugfs code to use enum kunit_status, not bool")
Reviewed-by: Rae Moar <rmoar@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit af73483f4e8b6f5c68c9aa63257bdd929a9c194a ]
The IDA usually detects double-frees, but that detection failed to
consider the case when there are no nearby IDs allocated and so we have a
NULL bitmap rather than simply having a clear bit. Add some tests to the
test-suite to be sure we don't inadvertently reintroduce this problem.
Unfortunately they're quite noisy so include a message to disregard
the warnings.
Reported-by: Zhenghan Wang <wzhmmmmm@gmail.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.15.146 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWYDqcACgkQONu9yGCS
# aT6oag//XS7Yvh5iblvruCoweAzN7O4H3O4flPMA5eOyiC3ZPS9ab/+6wToqUqz5
# Bfq4ocSX9bWCRCqb3Nb4R+6TyXhdrkfrkMquvSp+fira4jYBVPAKs1+CNEBd9tJr
# MgwSgHH6hDmxhOJsVCWuQkQgkSQUgcEqDYhsI59Xj+VBlAgtjco1JT1YeUxFUii6
# ibFN4RMbMXRETh3OonhfpxlAG7nSPepcgY/9A5+llZLamSW6D5dGkzOwMPxhl+qV
# AilmoUVeTvKEZqSReS9XKyQqZwNtylIu6UBBBOrteG4Rz4MGn9VUtcCJgrGEpS2q
# jkbyHTHXyGt19akQ/4cpSQjlDs6qi5EafdOcooBYOybL8PXldlXuppR2huhNsKcd
# wsym5lO1bwTgEGbOWu4RPXGPeNQ7h2pNItHMWEZ3ZS4qb1tUBfB636Q6apUBObNz
# NAtqZ4LwNRzy+SsP8aq1ezjVVp5e1ubJfDjwq5zjO80PfGOO2gtyDEI56vpsGs5n
# YhW4UkXbtzdu7qTNu54y5XzUhER90lK8uM8DM9QUW8bPtr1SAvn3WSTR723ld7bO
# 1UE8d9PYvZmbubX8PlycgbyXkdEwvyLiuAJ3boIOQYKDsnBCKsn/a990Znlyk/A9
# jZA4EKWu+DBdwO4yGGgGtAWViNLfx+6HfH89aqKsJBBuQ6aszFU=
# =9uci
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 05 Jan 2024 09:13:59 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 5c47251e8c4903111608ddcba2a77c0c425c247c upstream.
A refcount issue can appeared in __fwnode_link_del() due to the
pr_debug() call:
WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
Call Trace:
<TASK>
...
of_node_get+0x1e/0x30
of_fwnode_get+0x28/0x40
fwnode_full_name_string+0x34/0x90
fwnode_string+0xdb/0x140
...
vsnprintf+0x17b/0x630
...
__fwnode_link_del+0x25/0xa0
fwnode_links_purge+0x39/0xb0
of_node_release+0xd9/0x180
...
Indeed, an fwnode (of_node) is being destroyed and so, of_node_release()
is called because the of_node refcount reached 0.
From of_node_release() several function calls are done and lead to
a pr_debug() calls with %pfwf to print the fwnode full name.
The issue is not present if we change %pfwf to %pfwP.
To print the full name, %pfwf iterates over the current node and its
parents and obtain/drop a reference to all nodes involved.
In order to allow to print the full name (%pfwf) of a node while it is
being destroyed, do not obtain/drop a reference to this current node.
Fixes: a92eb7621b9f ("lib/vsprintf: Make use of fwnode API to obtain node names and separators")
Cc: stable@vger.kernel.org
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20231114152655.409331-1-herve.codina@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.15.142 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmVyyjsACgkQONu9yGCS
# aT4AihAAmtfvpHdsEqaSkAIcG/izQepGxIXoTUClStnxi9Zz58GGWTI5J9mRqBkZ
# T5l/rfFHKFLmzO8XnUFHtWcnNL3OWQg57TNBGmg7YXQGEtJUlbAfcF3YUujnD6uc
# fXzZHvyW2IiEBiH8t0QAKlwLph7c4lPpfGtWu38yiUk9LjF4BkXNa3KbRCkinp17
# n9SlAV6aJNi+eeVfE61Zl+ZQxnH0h/Ds4WAEz+FqDtIHTiqmNOVxoBn0qlgyZCJ7
# Bu/PWYky/6/Up8sos9c+zkOWCxtthmaKkNKuyC3ODFlALCo8xL8axHvKNKrKUXPs
# X1EPPOpgChUgiajhJozel/LG7WN8SykZsQS9pU6cbDU22FBNhee9TmAV6R7g1igH
# hX2O/R/bKJ1e7vOPanU77OAiscDnW88hqN2Av0vEesPxGnvTGxf7hvO+EcEVb0CM
# mzw/gBZHL8TAUorXES6TFUsTpCDEnvMjqousvoZotx05vUavyDboj5MqczeU6CTP
# N1QghdXo5kRVxwMCgRysclxoM+LYuqg5lf4utoZIn/NjWu2As/gAMTIBuOHxMreh
# aWLkQ3+1yN6V0ts724m++FCwVXhHaCYrA8s1WvUgJos5rbDC5WjFAdH9z1lP/pYI
# vysb4Ck1f/Ib3BdvCnsXOyBZEg+sTJZX/kwr9HpuUE4CsUUD+zM=
# =Ih9q
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 08 Dec 2023 02:48:11 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit e5f3e299a2b1e9c3ece24a38adfc089aef307e8a upstream.
Those return codes are only defined for the parisc architecture and
are leftovers from when we wanted to be HP-UX compatible.
They are not returned by any Linux kernel syscall but do trigger
problems with the glibc strerrorname_np() and strerror() functions as
reported in glibc issue #31080.
There is no need to keep them, so simply remove them.
Signed-off-by: Helge Deller <deller@gmx.de>
Reported-by: Bruno Haible <bruno@clisp.org>
Closes: https://sourceware.org/bugzilla/show_bug.cgi?id=31080
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.15.137 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmU45u0ACgkQONu9yGCS
# aT56RBAAkIaBAWcPIG5PQPXAU4d5jhKf6aHU6rNeT4j/aq/N5Q3P428T6S96JyO0
# dH1owiiBFiBEjfkpeOn3mDLdBSBQG483pefDBUZC5RmesGDGusGmNdVumRjxSiCT
# 7hD08Fr0enCBoyL/TLj5g08Y4JEL3qyC/+n8TWUXazI+M7WtDvrp2NCejqnD68Ii
# T8L7Q/LERPdv6OD3ve6MHjRCRB/AzYqbqczFusm3o+fI85VkZEeFb1BJxLVmRM/k
# eKRB28zssEcC4YBa4C7J8SlLaYUqmuTUG86Fuw0hJz59zAUPUwFZF0Sq0QFVZ68T
# 71QLtkKQgH6gIG19ar7NU7lEwbBivW8TSQ+MxR2mzfNeoy8KFWiq12gJFCUd0SVl
# 8Hk4PHHijpaZtqexRkmhgAOr8tyHn9GB0dvAb07ywPEbixJ9Bdi4Kqqsy1U6ALoy
# l2qzUu0W6iLyh0nYu96sK8fG6WTMPLqSyGaDAQugCUTkRl2UEI2DbTc6i+AcfYUg
# h9Cds3By0lZndsls5z62G+T06zYClGblZPd1uJS38WYDzNfrQx5qNtojoHXRpNOn
# OvTW/PWi6KMdENPrGZoug75oNhEkik7VLrf2UwPHYUjU4KiH6PqaK88Z509uD45h
# JwG04GdaecOa9gfvnDO2OhLhpfJ6JTvIvNHvCe1W/VT+9W0tMps=
# =Qo25
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 25 Oct 2023 05:59:09 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit cc6003916ed46d7a67d91ee32de0f9138047d55f upstream.
In workloads where this_cpu operations are frequently performed,
enabling DEBUG_PREEMPT may result in significant increase in
runtime overhead due to frequent invocation of
__this_cpu_preempt_check() function.
This can be demonstrated through benchmarks such as hackbench where this
configuration results in a 10% reduction in performance, primarily due to
the added overhead within memcg charging path.
Therefore, do not to enable DEBUG_PREEMPT by default and make users aware
of its potential impact on performance in some workloads.
hackbench-process-sockets
debug_preempt no_debug_preempt
Amean 1 0.4743 ( 0.00%) 0.4295 * 9.45%*
Amean 4 1.4191 ( 0.00%) 1.2650 * 10.86%*
Amean 7 2.2677 ( 0.00%) 2.0094 * 11.39%*
Amean 12 3.6821 ( 0.00%) 3.2115 * 12.78%*
Amean 21 6.6752 ( 0.00%) 5.7956 * 13.18%*
Amean 30 9.6646 ( 0.00%) 8.5197 * 11.85%*
Amean 48 15.3363 ( 0.00%) 13.5559 * 11.61%*
Amean 79 24.8603 ( 0.00%) 22.0597 * 11.27%*
Amean 96 30.1240 ( 0.00%) 26.8073 * 11.01%*
Link: https://lkml.kernel.org/r/20230121033942.350387-1-42.hyeyoo@gmail.com
Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Davidlohr Bueso <dave@stgolabs.net>
Cc: Ben Segall <bsegall@google.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Luiz Capitulino <luizcap@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.15.136 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUxmicACgkQONu9yGCS
# aT72ww/+ONp7PjBMab42i3fTVr5bnHXGRBuWhjMZf5aTG1oI9saDyRd7TZgS/ZCa
# dM77g2KZ2DseWFWFBlWAb1j1jSjcdt4/ccFWGLs9mUDgnQwfmifB2MB5qOQI3rSE
# 1dgbCZ7gU4KCBr3KdUXEgc5eCm2J0giMvv+TwvMDTPCZKiJ5u+6oMYLPMygUZ50s
# NTwLpMfLTpOkyqSF5iieAzZE0X0/X21WQ7Y+DsRsAOn7Fi8xmE8crzE8qchoYIHn
# 53Lwj1EnOriWEQxZe1jSBeHKB4+IZsn/WMNz3VM8YRPW20Kd6NtaXjc4KNC8tAPE
# eKhn5eOA3v5VloH6i0MwUNXKfOLgw8/AdXe7VtAj67M4zOrO1OmPG5T+3Pi4i567
# CSL983iYxtJiXFps11XQmOwzDngRxPQ87dgynJkWEPHOv0hMT8vH/LpUxr0KvNY6
# Gir7jiz3+dgw2xiVTBvvfeAnF7VzKtmzTQINh4uT6YET+/BWJo5A+bNx7ZuqIeH7
# eKejJlUeKe/aHX1n+SqywpucgyajVQdmYD1eL7aywp1gs9ja5Je/Go1Xmb7I6IGa
# 4e7eD6S93QwMhBYHdW8uI7Ri4Bolvhbh4Hx3jnLGkvlRATaFcXDPBt1MRFZv6gWC
# jcQrktj6m1QNQj4V1UqrKwvZCurRVHXWWs33htTA7ibm9dSA+WM=
# =zAWK
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 19 Oct 2023 05:05:43 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit efb78fa86e95 ("lib/test_meminit: allocate pages up to order
MAX_ORDER") works great in kernels 6.4 and newer thanks to commit
23baf831a32c ("mm, treewide: redefine MAX_ORDER sanely"), but for older
kernels, the loop is off by one, which causes crashes when the test
runs.
Fix this up by changing "<= MAX_ORDER" "< MAX_ORDER" to allow the test
to work properly for older kernel branches.
Fixes: 7ad44409cd3b ("lib/test_meminit: allocate pages up to order MAX_ORDER")
Cc: Andrew Donnellan <ajd@linux.ibm.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Xiaoke Wang <xkernel.wang@foxmail.com>
Cc: <stable@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.15.133 stable release
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUOq3oACgkQONu9yGCS
# aT6+5A//YHQ1kMXB9u4AvvKP5RaOpQxKmarumYWw1gKsLJ5uzGlw5zryPzq353Pu
# aoCBIbYospy7p5zLu+UCMZBH/hWWoKbsvsR2FUBLW9q3L/BvREwZY0HTeGEWSDB1
# Z6TIu6ESSFJ1QWSRJDikchaCqcpFWJNcuWRJXnpXJV9NzGF1ERcjwIUtD4a05C2Z
# xLJpu7HpBE2dVgQn+yepXNaHtRIsIuVv83xNjj4IMhhU+L9CnR9kJlJ4tICvlphi
# 7ub+lPVBEBU8g9+3tbYSwbw0OLRZ5VG1VKUhrmP1LA2joQY3lTiB1ojdGtVEmYBQ
# FHAvJME6D5DSap3LrK/4kUbytp2CjB0yHHi5B8nYnOfm7NXfL9WMOUnYVtirA/Qz
# yW7/SN52zrHzXp4WVruJrc67XO347WEEZ9uhHWL6MVYouwkARa0DZjahqtxwY5Ds
# Qh7uwUmyE6GZ8vbcCgsrCNl8+gQaeF6w2nDmqLGigpalSwWxkBrtZnfB85WqfUfJ
# pGpJdDIqQUYB1ahTmSW8eHvm9Dm1wUmheRuDBsURxxYq97Gmy8fOa8PVwbVCjS5q
# EHhzbX6aC9m4kPg7mUhWRNxjGpmyntvXwZ6oF3J+MIl0vsjjo7uXxRIrH1q+hn4f
# TKPCC8EYM9IMAn8PpBIKDd/xhoBF/hgHbzhsuKNb5mEZlIO0GI0=
# =RCtk
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 23 Sep 2023 05:10:18 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
# Conflicts:
# fs/jbd2/transaction.c
|
|
This is the 5.15.132 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUJdpAACgkQONu9yGCS
# aT7LKA//TbjfOj1RRRPE916bAbXiUwXoDDOFaAnUj8+QRLAxDB6g8U2uAMRdPwrE
# ChCFkRfma3u1hUloRp4w+IVxDNpyeTYDkK7VK5P0GSX+CUJj8ZtVCGMIYcyzdK18
# UHff2rCQVhkfzfXPxUVYws2JEtFqxeO1VsNJEVFLhMJ1NHePLyrMFyAQNLrLlk8K
# mxHjjpNdImSdgh8agAgioUaq+RvrWt2X0CTL8NC3HAU4PwMuDjTiB2YFD3PcQloS
# Pszqw1oenTQG9PwuwtnWJyn2U0RkD+IkEXj99ED/ocs73aHOmQ31jjcDXcz3gNJ5
# dZVktqD7y1tAQlivvsiwgumeJWxBQ9u5bEf1i8bAYfjelT6TyNuhk+JDWGRBYetd
# fOddhoNHw7KFvB8RKNSW/R+gt6RaeQZB8JN+9qF6vlit/uSP3wC0klKV56gKhXY9
# DMQ9j/FCLHrxOo5vgvMu5LTXJOyn/hgdQ9kYVT7Yz4Y2JDuFR6pE4xzuVsxIhnyX
# TIzp8ywsAKDl2d2OZCzp5S9YXxkVDBj0xJIxFSjyq9JPW9iVh18AEsIgkvwBjh/P
# 5okd3AIw+zU45dHDDsnePslFxl90La5cACuwEJzGsGuDYomdiUeqSCkB/5zcAWTn
# nra2BuxEI/DVHOifygJ4rZA9IBxIUoPrAbIPHR1Knjll+lfSVGY=
# =blAW
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 19 Sep 2023 06:23:12 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 4d0fe8c52bb3029d83e323c961221156ab98680b ]
When I register a kset in the following way:
static struct kset my_kset;
kobject_set_name(&my_kset.kobj, "my_kset");
ret = kset_register(&my_kset);
A null pointer dereference exception is occurred:
[ 4453.568337] Unable to handle kernel NULL pointer dereference at \
virtual address 0000000000000028
... ...
[ 4453.810361] Call trace:
[ 4453.813062] kobject_get_ownership+0xc/0x34
[ 4453.817493] kobject_add_internal+0x98/0x274
[ 4453.822005] kset_register+0x5c/0xb4
[ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset]
... ...
Because I didn't initialize my_kset.kobj.ktype.
According to the description in Documentation/core-api/kobject.rst:
- A ktype is the type of object that embeds a kobject. Every structure
that embeds a kobject needs a corresponding ktype.
So add sanity check to make sure kset->kobj.ktype is not NULL.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20230805084114.1298-2-thunder.leizhen@huaweicloud.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 9e47a758b70167c9301d2b44d2569f86c7796f2d ]
During NVMeTCP Authentication a controller can trigger a kernel
oops by specifying the 8192 bit Diffie Hellman group and passing
a correctly sized, but zeroed Diffie Hellamn value.
mpi_cmp_ui() was detecting this if the second parameter was 0,
but 1 is passed from dh_is_pubkey_valid(). This causes the null
pointer u->d to be dereferenced towards the end of mpi_cmp_ui()
Signed-off-by: Mark O'Donovan <shiftee@posteo.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
test_number_prefix()
commit 92382d744176f230101d54f5c017bccd62770f01 upstream.
A recent change in clang allows it to consider more expressions as
compile time constants, which causes it to point out an implicit
conversion in the scanf tests:
lib/test_scanf.c:661:2: warning: implicit conversion from 'int' to 'unsigned char' changes value from -168 to 88 [-Wconstant-conversion]
661 | test_number_prefix(unsigned char, "0xA7", "%2hhx%hhx", 0, 0xa7, 2, check_uchar);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/test_scanf.c:609:29: note: expanded from macro 'test_number_prefix'
609 | T result[2] = {~expect[0], ~expect[1]}; \
| ~ ^~~~~~~~~~
1 warning generated.
The result of the bitwise negation is the type of the operand after
going through the integer promotion rules, so this truncation is
expected but harmless, as the initial values in the result array get
overwritten by _test() anyways. Add an explicit cast to the expected
type in test_number_prefix() to silence the warning. There is no
functional change, as all the tests still pass with GCC 13.1.0 and clang
18.0.0.
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linuxq/issues/1899
Link: https://github.com/llvm/llvm-project/commit/610ec954e1f81c0e8fcadedcd25afe643f5a094e
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20230807-test_scanf-wconstant-conversion-v2-1-839ca39083e1@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 2a15de80dd0f7e04a823291aa9eb49c5294f56af ]
The relevant parameter is 'start' and not 'nextid'
Fixes: 460488c58ca8 ("idr: Remove idr_alloc_ext")
Signed-off-by: Ariel Marcovitch <arielmarcovitch@gmail.com>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit efb78fa86e95832b78ca0ba60f3706788a818938 upstream.
test_pages() tests the page allocator by calling alloc_pages() with
different orders up to order 10.
However, different architectures and platforms support different maximum
contiguous allocation sizes. The default maximum allocation order
(MAX_ORDER) is 10, but architectures can use CONFIG_ARCH_FORCE_MAX_ORDER
to override this. On platforms where this is less than 10, test_meminit()
will blow up with a WARN(). This is expected, so let's not do that.
Replace the hardcoded "10" with the MAX_ORDER macro so that we test
allocations up to the expected platform limit.
Link: https://lkml.kernel.org/r/20230714015238.47931-1-ajd@linux.ibm.com
Fixes: 5015a300a522 ("lib: introduce test_meminit module")
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Reviewed-by: Alexander Potapenko <glider@google.com>
Cc: Xiaoke Wang <xkernel.wang@foxmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.15.129 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTvT7YACgkQONu9yGCS
# aT65pQ/+Ko+cSATQarGOACdQ6dEs1JwPnHkfnvroQedYVo/U2kmtjMCb84BNM7GQ
# u68xlJAG/SEhF5775iE5OT72dK/UdyNZtydGvNReJrdJ1wL7MAtaDzLEqr4W5RB8
# buRtcVofW4bi+kvAhGWnU7D0qT/ZdHYX64GKfAqf5/fR/p3ZVxB66VPI9VX5LKTa
# dE85Y7rLEApDlDTm/frhAiUijXYS27tJKuyqyWG/gRlCiZA6jeoaU90l5iU7jkPz
# LWwcRQ35PMNfpxSyOZdCx11a/zlHR+mw0l5+wxF+u6toWLH+kckWwWMoIKr/Il0H
# DZNPYMDn27uNKG+DHndY28/bwj7mAHgAtuTmHpdGfJa4/9zJRN6KDJQrtL+7O9wF
# eZTzMV7RpEZzVTyueUhOExaAy1zlap2QW5f8MLOQFGMrxD8oQYEprMkp2jcv4rst
# cVO2ayALcyrzWc9FdYwq4XpqL9rdG0LxqM6YQpCz77vBWlSpOseyyqfBX79r6eKk
# S2oNFYLgHBJDjOrsKoaHOmpej42/x4B2yktCmwzQdkNCtyBs/lqWfD+xr3yyiy2J
# h2p1+kzEpghHdIjqEG0sMW2NMSimScsCZzGoqYKLJ/LZRfC2BaFgkqxWpZtzku8K
# Ch8ITZSxEHHKCH+sF/LofhT4nJEGwUt0vIIZcHvtDxaFb32yris=
# =ruaG
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 30 Aug 2023 10:18:30 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit d59070d1076ec5114edb67c87658aeb1d691d381 upstream.
Recent versions of clang warn about an unused variable, though older
versions saw the 'slot++' as a use and did not warn:
radix-tree.c:1136:50: error: parameter 'slot' set but not used [-Werror,-Wunused-but-set-parameter]
It's clearly not needed any more, so just remove it.
Link: https://lkml.kernel.org/r/20230811131023.2226509-1-arnd@kernel.org
Fixes: 3a08cd52c37c7 ("radix tree: Remove multiorder support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peng Zhang <zhangpeng.00@bytedance.com>
Cc: Rong Tao <rongtao@cestc.cn>
Cc: Tom Rix <trix@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 382d4cd1847517ffcb1800fd462b625db7b2ebea upstream.
The gcc compiler translates on some architectures the 64-bit
__builtin_clzll() function to a call to the libgcc function __clzdi2(),
which should take a 64-bit parameter on 32- and 64-bit platforms.
But in the current kernel code, the built-in __clzdi2() function is
defined to operate (wrongly) on 32-bit parameters if BITS_PER_LONG ==
32, thus the return values on 32-bit kernels are in the range from
[0..31] instead of the expected [0..63] range.
This patch fixes the in-kernel functions __clzdi2() and __ctzdi2() to
take a 64-bit parameter on 32-bit kernels as well, thus it makes the
functions identical for 32- and 64-bit kernels.
This bug went unnoticed since kernel 3.11 for over 10 years, and here
are some possible reasons for that:
a) Some architectures have assembly instructions to count the bits and
which are used instead of calling __clzdi2(), e.g. on x86 the bsr
instruction and on ppc cntlz is used. On such architectures the
wrong __clzdi2() implementation isn't used and as such the bug has
no effect and won't be noticed.
b) Some architectures link to libgcc.a, and the in-kernel weak
functions get replaced by the correct 64-bit variants from libgcc.a.
c) __builtin_clzll() and __clzdi2() doesn't seem to be used in many
places in the kernel, and most likely only in uncritical functions,
e.g. when printing hex values via seq_put_hex_ll(). The wrong return
value will still print the correct number, but just in a wrong
formatting (e.g. with too many leading zeroes).
d) 32-bit kernels aren't used that much any longer, so they are less
tested.
A trivial testcase to verify if the currently running 32-bit kernel is
affected by the bug is to look at the output of /proc/self/maps:
Here the kernel uses a correct implementation of __clzdi2():
root@debian:~# cat /proc/self/maps
00010000-00019000 r-xp 00000000 08:05 787324 /usr/bin/cat
00019000-0001a000 rwxp 00009000 08:05 787324 /usr/bin/cat
0001a000-0003b000 rwxp 00000000 00:00 0 [heap]
f7551000-f770d000 r-xp 00000000 08:05 794765 /usr/lib/hppa-linux-gnu/libc.so.6
...
and this kernel uses the broken implementation of __clzdi2():
root@debian:~# cat /proc/self/maps
0000000010000-0000000019000 r-xp 00000000 000000008:000000005 787324 /usr/bin/cat
0000000019000-000000001a000 rwxp 000000009000 000000008:000000005 787324 /usr/bin/cat
000000001a000-000000003b000 rwxp 00000000 00:00 0 [heap]
00000000f73d1000-00000000f758d000 r-xp 00000000 000000008:000000005 794765 /usr/lib/hppa-linux-gnu/libc.so.6
...
Signed-off-by: Helge Deller <deller@gmx.de>
Fixes: 4df87bb7b6a22 ("lib: add weak clz/ctz functions")
Cc: Chanho Min <chanho.min@lge.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@vger.kernel.org # v3.11+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.15.121 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmS9E3sACgkQONu9yGCS
# aT573w//WOG9AJV335EzZh9gjjxGg6nbJZZzLAbvC7XgY+ECVPfajaDAMMP7nGM5
# s2CQsbVFp22Rm73r8DVZmGJqAZzATSO1b09yUQZKcN/wWYqQYVzqqSp+vJfTY2zQ
# TcNsd2+8AFAZm2e5GBS3HFCBc+I3VqOVyuDBNvf5T+EGZNoJ8mNhVBkpnWudAPwc
# ALapsdAov0iv7Rv2pMcroSIKGk/VhERsbzEUV4xRvPH2UqmVVMASrZwWM4DKs1+t
# GuePKKloR60Tm+e6ZvVCjdXJlLcgRd4+o9RY9TCdKonsa9xuv0l3p5FwpjhdGIVc
# tw6LtiafMhQ2WWybvusMnSaNGhLJuPg2FM95PfUtarg0COflljrssz0mW+zGJpwP
# P1f5iKUFZmGQ3Is9ddrO4JoQQokgxDQ/ojhmoRv3tjnG+gMPadQi8wBuasipVt3u
# ho2Y7+U6wKfFOPIcUFS4qPMrjCvw28OdAIG6aF5vdd3SIiKejFuO/rMBCx9tHuLJ
# x6wPua6Xtmt0WSFlt8J8mcvnQOSj8gK4EIDfJlcXvNsmA0oHvOv+uEHSuxfxZaIq
# c23EPGjG+YXmPBJPmdV8WFzVaQc3xYgsg3gMVj99Zx0yTmT2viZmsJkWI/Uz/IKc
# G1HEJbuNniuyL4l4nZnNDr44UbA/i38IRy8+Ol8ATToGvDLSUvs=
# =XbDI
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 23 Jul 2023 07:48:11 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 7dae593cd226a0bca61201cf85ceb9335cf63682 ]
In a couple of situations like
name = kstrndup(buf, count, GFP_KERNEL);
if (!name)
return -ENOSPC;
the error is not actually "No space left on device", but "Out of memory".
It is semantically correct to return -ENOMEM in all failed kstrndup()
and kzalloc() cases in this driver, as it is not a problem with disk
space, but with kernel memory allocator failing allocation.
The semantically correct should be:
name = kstrndup(buf, count, GFP_KERNEL);
if (!name)
return -ENOMEM;
Cc: Dan Carpenter <error27@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: "Luis R. Rodriguez" <mcgrof@ruslug.rutgers.edu>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Brian Norris <briannorris@chromium.org>
Fixes: c92316bf8e948 ("test_firmware: add batched firmware tests")
Fixes: 0a8adf584759c ("test: add firmware_class loader test")
Fixes: 548193cba2a7d ("test_firmware: add support for firmware_request_platform")
Fixes: eb910947c82f9 ("test: firmware_class: add asynchronous request trigger")
Fixes: 061132d2b9c95 ("test_firmware: add test custom fallback trigger")
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Message-ID: <20230606070808.9300-1-mirsad.todorovac@alu.unizg.hr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6f67fbf8192da80c4db01a1800c7fceaca9cf1f9 ]
The `shift` variable which indicates the offset in the string at which
to start matching the pattern is initialized to `bm->patlen - 1`, but it
is not reset when a new block is retrieved. This means the implemen-
tation may start looking at later and later positions in each successive
block and miss occurrences of the pattern at the beginning. E.g.,
consider a HTTP packet held in a non-linear skb, where the HTTP request
line occurs in the second block:
[... 52 bytes of packet headers ...]
GET /bmtest HTTP/1.1\r\nHost: www.example.com\r\n\r\n
and the pattern is "GET /bmtest".
Once the first block comprising the packet headers has been examined,
`shift` will be pointing to somewhere near the end of the block, and so
when the second block is examined the request line at the beginning will
be missed.
Reinitialize the variable for each new block.
Fixes: 8082e4ed0a61 ("[LIB]: Boyer-Moore extension for textsearch infrastructure strike #2")
Link: https://bugzilla.netfilter.org/show_bug.cgi?id=1390
Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.15.118 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSTAmsACgkQONu9yGCS
# aT6MyA/9FRXd3ydG7b2o+n75Zolt/qzyz8p7YRljp7zF2py6/9NxKKKf0RtMifn0
# KDneJN9HSmkFDrFsZEX1PONHS4346lQpX33yE/6l19zsm/5PygqF7opTF2Amabkc
# 1FiQRb5EemctR902VNalYlSEHVMph0b+8pwMZzz9WjIkkQkOC2Bu+DIovmwk+wwQ
# IwBwq0Qouhp/MZAji+vcvRcvT1cKe8yWo5XEbPDCexJ8CkR3KHmXrWGzmLWKL/LB
# RDOUl71IoEEtepd8lMRMQN6WsYpun+yHE0DummXhNh/Xt8s0VRP73K15SIyIDaim
# TGZ2syUwq6/VWZRh3z5ERek4euaCp7JqYIv/+dnWoKxQvaXDLd4udSGin4AbMjd/
# vwxMsARWXM3i89tKByCryajUmYk6CUdxtf0VF4pJifq3+jbhTMb439tfzv5ja0kl
# umlappmgfc5+1keuHvONZsxMsbb0lhICbvBwXQEvRg0whNS6jMmWoFTc8mzQ1M/m
# qVDjKVWWDdmhTAnhn0MK9Z5HQ1Dnw0uwyObQM7ZHh5PK6PTf4vlY6RVU1NrhqOjK
# xHlEgYJ+GDXvooP8TLGv60K1T8p1YPi80mhYW0Gm8MytnRRlrDVTORgvyOUvlbu/
# BxxvDuOr/LiSn/cgQBC03WKxGbF4LjQsbesnt6xqIbG9aWybax4=
# =H93I
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 21 Jun 2023 10:00:11 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit be37bed754ed90b2655382f93f9724b3c1aae847 ]
Dan Carpenter spotted that test_fw_config->reqs will be leaked if
trigger_batched_requests_store() is called two or more times.
The same appears with trigger_batched_requests_async_store().
This bug wasn't trigger by the tests, but observed by Dan's visual
inspection of the code.
The recommended workaround was to return -EBUSY if test_fw_config->reqs
is already allocated.
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Tianfei Zhang <tianfei.zhang@intel.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Colin Ian King <colin.i.king@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Suggested-by: Dan Carpenter <error27@gmail.com>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20230509084746.48259-2-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4acfe3dfde685a5a9eaec5555351918e2d7266a1 ]
Dan Carpenter spotted a race condition in a couple of situations like
these in the test_firmware driver:
static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
u8 val;
int ret;
ret = kstrtou8(buf, 10, &val);
if (ret)
return ret;
mutex_lock(&test_fw_mutex);
*(u8 *)cfg = val;
mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
}
static ssize_t config_num_requests_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
int rc;
mutex_lock(&test_fw_mutex);
if (test_fw_config->reqs) {
pr_err("Must call release_all_firmware prior to changing config\n");
rc = -EINVAL;
mutex_unlock(&test_fw_mutex);
goto out;
}
mutex_unlock(&test_fw_mutex);
rc = test_dev_config_update_u8(buf, count,
&test_fw_config->num_requests);
out:
return rc;
}
static ssize_t config_read_fw_idx_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
return test_dev_config_update_u8(buf, count,
&test_fw_config->read_fw_idx);
}
The function test_dev_config_update_u8() is called from both the locked
and the unlocked context, function config_num_requests_store() and
config_read_fw_idx_store() which can both be called asynchronously as
they are driver's methods, while test_dev_config_update_u8() and siblings
change their argument pointed to by u8 *cfg or similar pointer.
To avoid deadlock on test_fw_mutex, the lock is dropped before calling
test_dev_config_update_u8() and re-acquired within test_dev_config_update_u8()
itself, but alas this creates a race condition.
Having two locks wouldn't assure a race-proof mutual exclusion.
This situation is best avoided by the introduction of a new, unlocked
function __test_dev_config_update_u8() which can be called from the locked
context and reducing test_dev_config_update_u8() to:
static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
int ret;
mutex_lock(&test_fw_mutex);
ret = __test_dev_config_update_u8(buf, size, cfg);
mutex_unlock(&test_fw_mutex);
return ret;
}
doing the locking and calling the unlocked primitive, which enables both
locked and unlocked versions without duplication of code.
The similar approach was applied to all functions called from the locked
and the unlocked context, which safely mitigates both deadlocks and race
conditions in the driver.
__test_dev_config_update_bool(), __test_dev_config_update_u8() and
__test_dev_config_update_size_t() unlocked versions of the functions
were introduced to be called from the locked contexts as a workaround
without releasing the main driver's lock and thereof causing a race
condition.
The test_dev_config_update_bool(), test_dev_config_update_u8() and
test_dev_config_update_size_t() locked versions of the functions
are being called from driver methods without the unnecessary multiplying
of the locking and unlocking code for each method, and complicating
the code with saving of the return value across lock.
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Tianfei Zhang <tianfei.zhang@intel.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Colin Ian King <colin.i.king@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Suggested-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Link: https://lore.kernel.org/r/20230509084746.48259-1-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f7d85515bd21902b218370a1a6301f76e4e636ff ]
strtobool() is the same as kstrtobool().
However, the latter is more used within the kernel.
In order to remove strtobool() and slightly simplify kstrtox.h, switch to
the other function name.
While at it, include the corresponding header file (<linux/kstrtox.h>)
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/34f04735d20e0138695dd4070651bd860a36b81c.1673688120.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stable-dep-of: 4acfe3dfde68 ("test_firmware: prevent race conditions by a correct implementation of locking")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.15.117 stable release
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSJhK8ACgkQONu9yGCS
# aT5AHQ/9EyhxkEAY0n0khZaeekTHSaL14GL5H1XscTs3DxRxub6E5I93tn5KVj+J
# Mec783ZaFEPlEXKymbRcA3z3GqxxPZ97ECisM43VkhaTNIDtwIZhEm2iYXRc5MbZ
# tErBkUidtebTR56HAZ4XLfkaDC0K6g3jlKMu54NRdBLlSQZJKJdZxCXgkKDfFz6e
# jeFb6SIQqR44ycX13EGNO+BXI3wWqDRikBF2V3UMHKECvaBeJBcHhWLdKh3eCOLU
# yzjWrjOIS1xJB2XpB1Oxw9DwX0pARlTu1aJ47By4agXFtsnwI0TaURYeTeemcStX
# 045F2om78cl2lJdXoIlfpEfPNa4aOM9EyiaUPW4NDxVo8V6in07qFaN3/C680o6p
# QA7tg6jJQfrvxdaO3De1i20WA2Wn1+bHjyZ4aVpVuIpZKa5OJQGAkKKMTZndfJ25
# aotbGdcgWoGocGTg4+E5Ib61S/DLIXjbGLqIGzzE6K24VLdEASVKQVCsPt/QdG8d
# J9julwTemujIhMF9gDhhnCBRu+oziupvZaxQOgsYABEkOHJ51pFTNJvG6EbgXGD3
# BM+nZYres6Mm/6+Uj9StYyOcmdII025ky4A4mjJ82dno7I9qRQshGDUSEtOv9DDS
# xPNoncigoDVh+iX5kan126+8Of2Ne5WajqWIjw8v4yq3AdTT3kg=
# =evAJ
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 14 Jun 2023 05:13:19 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
# Conflicts:
# drivers/ata/ahci.h
|
|
This reverts commit 503e554782c916aec553f790298564a530cf1778 which is
commit 0af462f19e635ad522f28981238334620881badc upstream.
Guenter reports problems with it, and it's not quite obvious why, so
revert it for now.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/d35b1ff1-e198-481c-b1be-9e22445efe06@roeck-us.net
Cc: Ido Schimmel <idosch@nvidia.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 7c5d4801ecf0564c860033d89726b99723c55146 ]
irq_cpu_rmap_release() calls cpu_rmap_put(), which may free the rmap.
So we need to clear the pointer to our glue structure in rmap before
doing that, not after.
Fixes: 4e0473f1060a ("lib: cpu_rmap: Avoid use after free on rmap->obj array entries")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/ZHo0vwquhOy3FaXc@decadent.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.15.116 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSC464ACgkQONu9yGCS
# aT61dQ//bgt3MdF3nEo07Stb94D+bLOwau0kcEfnoz7goLHeQI5mmqmNlCdtmQDq
# gvY/Ut6LItUXbOctCMJGAvHWt+MOzy2lACCd5qI7NyfaSkJgNNBb4xVaG/XjfeB2
# acQ3RXBGa7xOMW677jREc76Yed4pxW6/YC6/C9/jdxoWaW6dRCV4Hju3iUf/oKBo
# iz7LWd0qeOaLIZfC9OS2v+GIZWT2z2bidmJhsjGd1cPm+ip3+YftGiwuzphv/NeY
# hzfVU7Teg874JWocsHixPjyIXZA1I4/VRKkEr4xtI7ooaTulbo1ImrhDm6imdxYp
# 5KJPr39Xm5Y6piUNn72PZ1Wc906XrBIIfP2sgjaMPnqrHOi5B0imnHg1QlRN0+Qk
# Ni9EpQb9GcKlDj5OhXPZ88xntKPtU7+q7TgoUto5DH7cSxelk2BGyrHqEXLQT2YZ
# HP5NvspUjPeAPO9W1CFeTCXrUySAjJayjrd0V7+/N6ii205+aWVsU5HkJ/OFrd6L
# 22wZKk76Fni9FDx8j6wSU0NbZMIrP3/yIth2q7LzR2JPS7IvDsohBz/VLI9wUUkU
# MEKNhQSnldRvhG7hZ6XFG6n/LsnbXWXR2LNI9Vapud4QUYFmTf5cBtjSmSET7Vpd
# Sq9NxL10cVNR4qHmTkMzeNdEAVm1XgKKoot0rvMj7qQNEIoiscc=
# =WxoZ
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 09 Jun 2023 04:32:46 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 48e156023059e57a8fc68b498439832f7600ffff upstream.
The following kernel memory leak was noticed after running
tools/testing/selftests/firmware/fw_run_tests.sh:
[root@pc-mtodorov firmware]# cat /sys/kernel/debug/kmemleak
.
.
.
unreferenced object 0xffff955389bc3400 (size 1024):
comm "test_firmware-0", pid 5451, jiffies 4294944822 (age 65.652s)
hex dump (first 32 bytes):
47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0
[<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240
[<ffffffff962704de>] kmalloc_trace+0x2e/0xc0
[<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180
[<ffffffff95fd813b>] kthread+0x10b/0x140
[<ffffffff95e033e9>] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334b400 (size 1024):
comm "test_firmware-1", pid 5452, jiffies 4294944822 (age 65.652s)
hex dump (first 32 bytes):
47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0
[<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240
[<ffffffff962704de>] kmalloc_trace+0x2e/0xc0
[<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180
[<ffffffff95fd813b>] kthread+0x10b/0x140
[<ffffffff95e033e9>] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334f000 (size 1024):
comm "test_firmware-2", pid 5453, jiffies 4294944822 (age 65.652s)
hex dump (first 32 bytes):
47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0
[<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240
[<ffffffff962704de>] kmalloc_trace+0x2e/0xc0
[<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180
[<ffffffff95fd813b>] kthread+0x10b/0x140
[<ffffffff95e033e9>] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c3348400 (size 1024):
comm "test_firmware-3", pid 5454, jiffies 4294944822 (age 65.652s)
hex dump (first 32 bytes):
47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0
[<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240
[<ffffffff962704de>] kmalloc_trace+0x2e/0xc0
[<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180
[<ffffffff95fd813b>] kthread+0x10b/0x140
[<ffffffff95e033e9>] ret_from_fork+0x29/0x50
[root@pc-mtodorov firmware]#
Note that the size 1024 corresponds to the size of the test firmware
buffer. The actual number of the buffers leaked is around 70-110,
depending on the test run.
The cause of the leak is the following:
request_partial_firmware_into_buf() and request_firmware_into_buf()
provided firmware buffer isn't released on release_firmware(), we
have allocated it and we are responsible for deallocating it manually.
This is introduced in a number of context where previously only
release_firmware() was called, which was insufficient.
Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Tianfei zhang <tianfei.zhang@intel.com>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Zhengchao Shao <shaozhengchao@huawei.com>
Cc: Colin Ian King <colin.i.king@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Link: https://lore.kernel.org/r/20230509084746.48259-3-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.15.114 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmR18k8ACgkQONu9yGCS
# aT4u1RAAmJTe3mZNqWNosxzC61H8Oa6+JUkwWhdQ0x50aDdRW/RLKHGP5USvJRe2
# ER+DjxsiB39F9ZBNsP64f4MIrxCLfAtkzW7T0gNXpIQaaRvLXqq/j+hJOQmMvwEW
# VZajj4geVBbPiwfXlyoBanFF5UZFEOVG9Gx6yoWH7Dl0UmPm06xG2/GvT7fdhLkB
# qtuYWmPnCXbSyaiPe6xfecnVy0uAGLhYgBmsvt1PuS4SWGvGFbeONojzoZOHfRkh
# lKa4NZXZkz3Zf2A556GqaEfU2ESKM5jWDE1SEbiVG9a8iJBANLRlRMm2j5+3XAaB
# YGeEsaB5phRSUhL4PZl1aBe5HgM1euO0AOFaEdJNNXx/5tdYo0xK5MfZePW3hEcT
# 153mkhEhX8n1W5tzmf+qr7hIj2VZ+Pl+VGgYgSbp4F1KDeLoanrf/jTPkf5Id4Uq
# 4VyzijgeufhKtcSJN4lVoss877Xmpm9HPlTj86hYdX/d9H7aemTdoaKc6J7F2j/p
# cFCqb6mczp4Rvh+IWl+wDJiMnnsnYIDXKj0Mcjj+TvrUreg9/mgqQC6IGyf+gjF8
# 1m0Nrqr7Nt37ynq8JS/vn/UHzBBZ3pGGom2qQphZOEtb6G3pO6jAHQ0L9Dy5XH4J
# jzgcNWZ80jpWPvhJdtUEVqbV3dMuNZRNUJ2zV8V0Hwte+cLs12c=
# =ePpD
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 30 May 2023 08:55:43 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit eb799279fb1f9c63c520fe8c1c41cb9154252db6 upstream.
syzbot is reporting a lockdep warning in fill_pool() because the allocation
from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)
and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.
Since fill_pool() might be called with arbitrary locks held, fill_pool()
should not assume that acquiring kswapd_wait::lock is safe.
Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for
!__GFP_DIRECT_RECLAIM allocation.
Fixes: 3ac7fe5a4aab ("infrastructure to debug (dynamic) objects")
Reported-by: syzbot <syzbot+fe0c72f0ccbb93786380@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/6577e1fa-b6ee-f2be-2414-a2b51b1c5e30@I-love.SAKURA.ne.jp
Closes: https://syzkaller.appspot.com/bug?extid=fe0c72f0ccbb93786380
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.15.113 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmRuPSwACgkQONu9yGCS
# aT6/7RAAmy/HYiWHwpje9jcycRZpR31xe8JY/I0zfHGu9f4jDQzT8BOcN7StKydq
# MNTua+PdvksOL0/f2RV+yYbGU2EXB15qPX2vgUj1U+7mSiNNtw5Gox11GCm2qpwg
# 27+gw1kF3OTvxdgIa5x4cPZySOb8W2fZVTBdO5HMxJ7YW3FSHokyn0lWLCvBTQhr
# 2Xp9Dyr1kQ9w0lkfgZ2knqLA6pJ5NT3qfdffuJbQBKHvqMqJy285nVtIcz8qCQXC
# RVaHXqIDphGhjWd3pi55bKmF1afITXuKbDQv/fuH3bmV9+SwuWLzmpE3pdsazF0E
# yRLmWHdM7OkNuxsJ1L8F5Zf+fQMleyEQGL1UFzEtFSmEWoY/TuhfhP6oBAN9IANm
# 1jo9KqnR7hTfGNGMupFDzI/A4WR91/YjmSrU9+SE6oNCdDee7yeB4pg8GzKo2tJY
# wAY3SB0Bynw/apbjt0xkX//tYZuh7DhkD8aPQEcYr4a7KUROpelfmUqGYKmhru2h
# XeZTwryPHlejWsY0Nx95/gVfGpCYXOMvRfsmP2DRtXiZBkoCxUGQ3fUFEPgfvJQC
# mlI+j25OYjxb4NAZokdXXxMsKLYjwxFil3czTi/kVG+0NGIikzIKDBmiyTAKvsa8
# KOTFneccT024Oxr5bzuKh/0hKs4V3fy+0+FVwbp77OKa4+MKu48=
# =dC7R
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 24 May 2023 12:37:00 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 4e0473f1060aa49621d40a113afde24818101d37 ]
When calling irq_set_affinity_notifier() with NULL at the notify
argument, it will cause freeing of the glue pointer in the
corresponding array entry but will leave the pointer in the array. A
subsequent call to free_irq_cpu_rmap() will try to free this entry again
leading to possible use after free.
Fix that by setting NULL to the array entry and checking that we have
non-zero at the array entry when iterating over the array in
free_irq_cpu_rmap().
The current code does not suffer from this since there are no cases
where irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the
notify arg) is called, followed by a call to free_irq_cpu_rmap() so we
don't hit and issue. Subsequent patches in this series excersize this
flow, hence the required fix.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Eli Cohen <elic@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
Bruce Ashfield
Peter Zijlstra
Arnd Bergmann
Peter Collingbourne
Philipp Stanner
Breno Leitao
David Gow
Tetsuo Handa
Tianjia Zhang
Andrzej Hajda
Richard Fitzgerald
Matthew Wilcox (Oracle)
Herve Codina
Helge Deller
Hyeonggon Yoo
Greg Kroah-Hartman
Zhen Lei
Mark O'Donovan
Nathan Chancellor
Ariel Marcovitch
Andrew Donnellan
Mirsad Goran Todorovac
Jeremy Sowden
Christophe JAILLET
Ben Hutchings
Eli Cohen