commit c61bd26ae81a896c8660150b4e356153da30880a Author: Greg Kroah-Hartman Date: Sat May 25 16:20:19 2024 +0200 Linux 5.15.160 Link: https://lore.kernel.org/r/20240523130327.956341021@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Harshit Mogalapalli Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Kelsey Steele Signed-off-by: Greg Kroah-Hartman commit 0df819cac13e9688fb496cba3e210633b6df8a03 Author: Akira Yokosawa Date: Wed May 1 12:16:11 2024 +0900 docs: kernel_include.py: Cope with docutils 0.21 commit d43ddd5c91802a46354fa4c4381416ef760676e2 upstream. Running "make htmldocs" on a newly installed Sphinx 7.3.7 ends up in a build error: Sphinx parallel build error: AttributeError: module 'docutils.nodes' has no attribute 'reprunicode' docutils 0.21 has removed nodes.reprunicode, quote from release note [1]: * Removed objects: docutils.nodes.reprunicode, docutils.nodes.ensure_str() Python 2 compatibility hacks Sphinx 7.3.0 supports docutils 0.21 [2]: kernel_include.py, whose origin is misc.py of docutils, uses reprunicode. Upstream docutils removed the offending line from the corresponding file (docutils/docutils/parsers/rst/directives/misc.py) in January 2022. Quoting the changelog [3]: Deprecate `nodes.reprunicode` and `nodes.ensure_str()`. Drop uses of the deprecated constructs (not required with Python 3). Do the same for kernel_include.py. Tested against: - Sphinx 2.4.5 (docutils 0.17.1) - Sphinx 3.4.3 (docutils 0.17.1) - Sphinx 5.3.0 (docutils 0.18.1) - Sphinx 6.2.1 (docutils 0.19) - Sphinx 7.2.6 (docutils 0.20.1) - Sphinx 7.3.7 (docutils 0.21.2) Link: http://www.docutils.org/RELEASE-NOTES.html#release-0-21-2024-04-09 [1] Link: https://www.sphinx-doc.org/en/master/changes.html#release-7-3-0-released-apr-16-2024 [2] Link: https://github.com/docutils/docutils/commit/c8471ce47a24 [3] Signed-off-by: Akira Yokosawa Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/faf5fa45-2a9d-4573-9d2e-3930bdc1ed65@gmail.com Signed-off-by: Greg Kroah-Hartman commit 1786e0c96af1d455a4cc1632b7c36b838ca1232e Author: Thomas Weißschuh Date: Tue Apr 23 12:34:25 2024 +0200 admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET commit 8af2d1ab78f2342f8c4c3740ca02d86f0ebfac5a upstream. sched_core_share_pid() copies the cookie to userspace with put_user(id, (u64 __user *)uaddr), expecting 64 bits of space. The "unsigned long" datatype that is documented in core-scheduling.rst however is only 32 bits large on 32 bit architectures. Document "unsigned long long" as the correct data type that is always 64bits large. This matches what the selftest cs_prctl_test.c has been doing all along. Fixes: 0159bb020ca9 ("Documentation: Add usecases, design and interface for core scheduling") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/util-linux/df7a25a0-7923-4f8b-a527-5e6f0064074d@t-8ch.de/ Signed-off-by: Thomas Weißschuh Reviewed-by: Chris Hyser Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240423-core-scheduling-cookie-v1-1-5753a35f8dfc@weissschuh.net Signed-off-by: Greg Kroah-Hartman commit 96f650995c70237b061b497c66755e32908f8972 Author: Jarkko Sakkinen Date: Mon May 13 21:19:04 2024 +0300 KEYS: trusted: Do not use WARN when encode fails commit 050bf3c793a07f96bd1e2fd62e1447f731ed733b upstream. When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. Cc: stable@vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 00548ac6b14428719c970ef90adae2b3b48c0cdf Author: AngeloGioacchino Del Regno Date: Thu Mar 21 09:46:13 2024 +0100 remoteproc: mediatek: Make sure IPI buffer fits in L2TCM commit 331f91d86f71d0bb89a44217cc0b2a22810bbd42 upstream. The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well. Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic. To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core). Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW") Signed-off-by: AngeloGioacchino Del Regno Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240321084614.45253-2-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit da6504c63f78026855699eeb55a63c467fc58a87 Author: Daniel Thompson Date: Wed Apr 24 15:21:41 2024 +0100 serial: kgdboc: Fix NMI-safety problems from keyboard reset code commit b2aba15ad6f908d1a620fd97f6af5620c3639742 upstream. Currently, when kdb is compiled with keyboard support, then we will use schedule_work() to provoke reset of the keyboard status. Unfortunately schedule_work() gets called from the kgdboc post-debug-exception handler. That risks deadlock since schedule_work() is not NMI-safe and, even on platforms where the NMI is not directly used for debugging, the debug trap can have NMI-like behaviour depending on where breakpoints are placed. Fix this by using the irq work system, which is NMI-safe, to defer the call to schedule_work() to a point when it is safe to call. Reported-by: Liuye Closes: https://lore.kernel.org/all/20240228025602.3087748-1-liu.yeC@h3c.com/ Cc: stable@vger.kernel.org Reviewed-by: Douglas Anderson Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20240424-kgdboc_fix_schedule_work-v2-1-50f5a490aec5@linaro.org Signed-off-by: Daniel Thompson Signed-off-by: Greg Kroah-Hartman commit 1768f29972cdf464f9d5ed39e5c252905d902235 Author: Heikki Krogerus Date: Tue May 7 16:43:16 2024 +0300 usb: typec: ucsi: displayport: Fix potential deadlock commit b791a67f68121d69108640d4a3e591d210ffe850 upstream. The function ucsi_displayport_work() does not access the connector, so it also must not acquire the connector lock. This fixes a potential deadlock scenario: ucsi_displayport_work() -> lock(&con->lock) typec_altmode_vdm() dp_altmode_vdm() dp_altmode_work() typec_altmode_enter() ucsi_displayport_enter() -> lock(&con->lock) Reported-by: Mathias Nyman Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20240507134316.161999-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ddbcd7d36e3899cdb255fbbeef40127f6ef39d98 Author: Carlos Llamas Date: Sun Apr 21 17:37:49 2024 +0000 binder: fix max_thread type inconsistency commit 42316941335644a98335f209daafa4c122f28983 upstream. The type defined for the BINDER_SET_MAX_THREADS ioctl was changed from size_t to __u32 in order to avoid incompatibility issues between 32 and 64-bit kernels. However, the internal types used to copy from user and store the value were never updated. Use u32 to fix the inconsistency. Fixes: a9350fc859ae ("staging: android: binder: fix BINDER_SET_MAX_THREADS declaration") Reported-by: Arve Hjønnevåg Cc: stable@vger.kernel.org Signed-off-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240421173750.3117808-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit 7e6d6f27522bcd037856234b720ff607b9c4a09b Author: Srinivasan Shanmugam Date: Tue Dec 26 15:32:19 2023 +0530 drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() commit b8d55a90fd55b767c25687747e2b24abd1ef8680 upstream. Return invalid error code -EINVAL for invalid block id. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176) Suggested-by: Hawking Zhang Cc: Tao Zhou Cc: Hawking Zhang Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher [Ajay: applied AMDGPU_RAS_BLOCK_COUNT condition to amdgpu_ras_query_error_status() as amdgpu_ras_query_error_status_helper() not present in v5.15 amdgpu_ras_query_error_status_helper() was introduced in 8cc0f5669eb6] Signed-off-by: Ajay Kaher Signed-off-by: Greg Kroah-Hartman commit c9f2b6d88e650bdb0f285a0622eef796d3e04be6 Author: Sean Christopherson Date: Wed Mar 22 07:32:59 2023 -0700 KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection commit 6c41468c7c12d74843bb414fc00307ea8a6318c3 upstream. When injecting an exception into a vCPU in Real Mode, suppress the error code by clearing the flag that tracks whether the error code is valid, not by clearing the error code itself. The "typo" was introduced by recent fix for SVM's funky Paged Real Mode. Opportunistically hoist the logic above the tracepoint so that the trace is coherent with respect to what is actually injected (this was also the behavior prior to the buggy commit). Fixes: b97f07458373 ("KVM: x86: determine if an exception has an error code only when injecting it.") Cc: stable@vger.kernel.org Cc: Maxim Levitsky Signed-off-by: Sean Christopherson Message-Id: <20230322143300.2209476-2-seanjc@google.com> Signed-off-by: Paolo Bonzini [nsaenz: backport to 5.15.y] Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Greg Kroah-Hartman Acked-by: Sean Christopherson commit 2750d7641d0825aeb1e4d3b40c627ff3e3670d24 Author: Eric Dumazet Date: Tue Oct 3 18:34:55 2023 +0000 netlink: annotate data-races around sk->sk_err commit d0f95894fda7d4f895b29c1097f92d7fee278cb2 upstream. syzbot caught another data-race in netlink when setting sk->sk_err. Annotate all of them for good measure. BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg write to 0xffff8881613bb220 of 4 bytes by task 28147 on cpu 0: netlink_recvmsg+0x448/0x780 net/netlink/af_netlink.c:1994 sock_recvmsg_nosec net/socket.c:1027 [inline] sock_recvmsg net/socket.c:1049 [inline] __sys_recvfrom+0x1f4/0x2e0 net/socket.c:2229 __do_sys_recvfrom net/socket.c:2247 [inline] __se_sys_recvfrom net/socket.c:2243 [inline] __x64_sys_recvfrom+0x78/0x90 net/socket.c:2243 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd write to 0xffff8881613bb220 of 4 bytes by task 28146 on cpu 1: netlink_recvmsg+0x448/0x780 net/netlink/af_netlink.c:1994 sock_recvmsg_nosec net/socket.c:1027 [inline] sock_recvmsg net/socket.c:1049 [inline] __sys_recvfrom+0x1f4/0x2e0 net/socket.c:2229 __do_sys_recvfrom net/socket.c:2247 [inline] __se_sys_recvfrom net/socket.c:2243 [inline] __x64_sys_recvfrom+0x78/0x90 net/socket.c:2243 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00000000 -> 0x00000016 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 28146 Comm: syz-executor.0 Not tainted 6.6.0-rc3-syzkaller-00055-g9ed22ae6be81 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20231003183455.3410550-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: yenchia.chen Signed-off-by: Greg Kroah-Hartman commit 7cff4103be7c402ecc3e7bf8f95a64089e3c91b8 Author: Eric Dumazet Date: Mon Apr 3 21:46:43 2023 +0000 netlink: annotate lockless accesses to nlk->max_recvmsg_len commit a1865f2e7d10dde00d35a2122b38d2e469ae67ed upstream. syzbot reported a data-race in data-race in netlink_recvmsg() [1] Indeed, netlink_recvmsg() can be run concurrently, and netlink_dump() also needs protection. [1] BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg read to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0: netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg net/socket.c:1038 [inline] __sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194 __do_sys_recvfrom net/socket.c:2212 [inline] __se_sys_recvfrom net/socket.c:2208 [inline] __x64_sys_recvfrom+0x78/0x90 net/socket.c:2208 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd write to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1: netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg net/socket.c:1038 [inline] ____sys_recvmsg+0x156/0x310 net/socket.c:2720 ___sys_recvmsg net/socket.c:2762 [inline] do_recvmmsg+0x2e5/0x710 net/socket.c:2856 __sys_recvmmsg net/socket.c:2935 [inline] __do_sys_recvmmsg net/socket.c:2958 [inline] __se_sys_recvmmsg net/socket.c:2951 [inline] __x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0x0000000000001000 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 Fixes: 9063e21fb026 ("netlink: autosize skb lengthes") Reported-by: syzbot Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230403214643.768555-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: yenchia.chen Signed-off-by: Greg Kroah-Hartman commit 3ade391adc584f17b5570fd205de3ad029090368 Author: Jakub Kicinski Date: Tue Feb 6 17:18:21 2024 -0800 net: tls: handle backlogging of crypto requests commit 8590541473188741055d27b955db0777569438e3 upstream. Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical. Fixes: a54667f6728c ("tls: Add support for encryption using async offload accelerator") Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records") Co-developed-by: Sabrina Dubroca Signed-off-by: Sabrina Dubroca Link: https://lore.kernel.org/netdev/9681d1febfec295449a62300938ed2ae66983f28.1694018970.git.sd@queasysnail.net/ Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller [v5.15: fixed contextual merge-conflicts in tls_decrypt_done and tls_encrypt_done] Cc: # 5.15 Signed-off-by: Shaoying Xu Signed-off-by: Greg Kroah-Hartman commit f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7 Author: Jakub Kicinski Date: Tue Feb 6 17:18:19 2024 -0800 tls: fix race between async notify and socket close commit aec7961916f3f9e88766e2688992da6980f11b8d upstream. The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires. Reported-by: valis Fixes: 0cada33241d9 ("net/tls: fix race condition causing kernel panic") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Reviewed-by: Eric Dumazet Reviewed-by: Sabrina Dubroca Signed-off-by: David S. Miller [v5.15: fixed contextual conflicts in struct tls_sw_context_rx and func init_ctx_rx; replaced DEBUG_NET_WARN_ON_ONCE with BUILD_BUG_ON_INVALID since they're equivalent when DEBUG_NET is not defined] Cc: # 5.15 Signed-off-by: Shaoying Xu Signed-off-by: Greg Kroah-Hartman commit 94afddde1e9285c0aa25a8bb1f4734071e56055b Author: Jakub Kicinski Date: Tue Feb 6 17:18:18 2024 -0800 net: tls: factor out tls_*crypt_async_wait() commit c57ca512f3b68ddcd62bda9cc24a8f5584ab01b1 upstream. Factor out waiting for async encrypt and decrypt to finish. There are already multiple copies and a subsequent fix will need more. No functional changes. Note that crypto_wait_req() returns wait->err Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Reviewed-by: Sabrina Dubroca Signed-off-by: David S. Miller Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close") [v5.15: removed changes in tls_sw_splice_eof and adjusted waiting factor out for async descrypt in tls_sw_recvmsg] Cc: # 5.15 Signed-off-by: Shaoying Xu Signed-off-by: Greg Kroah-Hartman commit fb782814bf09199283e565c7e6d0b6b155363273 Author: Sabrina Dubroca Date: Mon Oct 9 22:50:46 2023 +0200 tls: extract context alloc/initialization out of tls_set_sw_offload commit 615580cbc99af0da2d1c7226fab43a3d5003eb97 upstream. Simplify tls_set_sw_offload a bit. Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close") [v5.15: fixed contextual conflicts from unavailable init_waitqueue_head and skb_queue_head_init calls in tls_set_sw_offload and init_ctx_rx] Cc: # 5.15 Signed-off-by: Shaoying Xu Signed-off-by: Greg Kroah-Hartman commit 704402f913b809345b2372a05d7822d03f29f923 Author: Jakub Kicinski Date: Fri Apr 8 11:31:27 2022 -0700 tls: rx: simplify async wait commit 37943f047bfb88ba4dfc7a522563f57c86d088a0 upstream. Since we are protected from async completions by decrypt_compl_lock we can drop the async_notify and reinit the completion before we start waiting. Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close") Signed-off-by: Shaoying Xu Signed-off-by: Greg Kroah-Hartman commit cc4fac519d28ef0155fd424e479c36ac1732f3c2 Author: Doug Berger Date: Thu Apr 25 15:27:21 2024 -0700 net: bcmgenet: synchronize UMAC_CMD access commit 0d5e2a82232605b337972fb2c7d0cbc46898aca1 upstream. The UMAC_CMD register is written from different execution contexts and has insufficient synchronization protections to prevent possible corruption. Of particular concern are the acceses from the phy_device delayed work context used by the adjust_link call and the BH context that may be used by the ndo_set_rx_mode call. A spinlock is added to the driver to protect contended register accesses (i.e. reg_lock) and it is used to synchronize accesses to UMAC_CMD. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Cc: stable@vger.kernel.org Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1d5d18efc181f62d2af657f1b4b72d075535ee95 Author: Doug Berger Date: Thu Apr 25 15:27:19 2024 -0700 net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access commit d85cf67a339685beae1d0aee27b7f61da95455be upstream. The EXT_RGMII_OOB_CTRL register can be written from different contexts. It is predominantly written from the adjust_link handler which is synchronized by the phydev->lock, but can also be written from a different context when configuring the mii in bcmgenet_mii_config(). The chances of contention are quite low, but it is conceivable that adjust_link could occur during resume when WoL is enabled so use the phydev->lock synchronizer in bcmgenet_mii_config() to be sure. Fixes: afe3f907d20f ("net: bcmgenet: power on MII block for all MII modes") Cc: stable@vger.kernel.org Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 52c4287f23c84c32412525538e2e95ba395180ff Author: Harshit Mogalapalli Date: Mon May 6 01:46:35 2024 -0700 Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems" This reverts commit 0d29b474fb90ff35920642f378d9baace9b47edd which is commit 91b80cc5b39f00399e8e2d17527cad2c7fa535e2 upstream. map_hugetlb.c:18:10: fatal error: vm_util.h: No such file or directory 18 | #include "vm_util.h" | ^~~~~~~~~~~ compilation terminated. vm_util.h is not present in 5.15.y, as commit:642bc52aed9c ("selftests: vm: bring common functions to a new file") is not present in stable kernels <=6.1.y Signed-off-by: Harshit Mogalapalli commit 1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf Author: Jarkko Sakkinen Date: Mon May 20 02:31:53 2024 +0300 KEYS: trusted: Fix memory leak in tpm2_key_encode() commit ffcaa2172cc1a85ddb8b783de96d38ca8855e248 upstream. 'scratch' is never freed. Fix this by calling kfree() in the success, and in the error case. Cc: stable@vger.kernel.org # +v5.13 Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 9b8a8e5e81295883a3722bebb49259fa755ab4a0 Author: NeilBrown Date: Tue Jul 18 16:38:08 2023 +1000 nfsd: don't allow nfsd threads to be signalled. commit 3903902401451b1cd9d797a8c79769eb26ac7fe5 upstream. The original implementation of nfsd used signals to stop threads during shutdown. In Linux 2.3.46pre5 nfsd gained the ability to shutdown threads internally it if was asked to run "0" threads. After this user-space transitioned to using "rpc.nfsd 0" to stop nfsd and sending signals to threads was no longer an important part of the API. In commit 3ebdbe5203a8 ("SUNRPC: discard svo_setup and rename svc_set_num_threads_sync()") (v5.17-rc1~75^2~41) we finally removed the use of signals for stopping threads, using kthread_stop() instead. This patch makes the "obvious" next step and removes the ability to signal nfsd threads - or any svc threads. nfsd stops allowing signals and we don't check for their delivery any more. This will allow for some simplification in later patches. A change worth noting is in nfsd4_ssc_setup_dul(). There was previously a signal_pending() check which would only succeed when the thread was being shut down. It should really have tested kthread_should_stop() as well. Now it just does the latter, not the former. Signed-off-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 44889eacfe1f49d894ff60d460533f0a744c6c8a Author: Sergey Shtylyov Date: Wed Jul 19 23:22:52 2023 +0300 pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin() commit ecfe9a015d3e1e46504d5b3de7eef1f2d186194a upstream. pinctrl_register_one_pin() doesn't check the result of radix_tree_insert() despite they both may return a negative error code. Linus Walleij said he has copied the radix tree code from kernel/irq/ where the functions calling radix_tree_insert() are *void* themselves; I think it makes more sense to propagate the errors from radix_tree_insert() upstream if we can do that... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/20230719202253.13469-3-s.shtylyov@omp.ru Signed-off-by: Linus Walleij Cc: "Hemdan, Hagar Gamal Halim" Signed-off-by: Greg Kroah-Hartman commit a32c8f951c8a456c1c251e1dcdf21787f8066445 Author: Jose Fernandez Date: Mon Apr 22 08:35:44 2024 -0600 drm/amd/display: Fix division by zero in setup_dsc_config commit 130afc8a886183a94cf6eab7d24f300014ff87ba upstream. When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113. Reviewed-by: Rodrigo Siqueira Signed-off-by: Jose Fernandez Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3113 Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Cc: "Limonciello, Mario" Signed-off-by: Greg Kroah-Hartman