[rocky9_6] History Rebuild for kernel-5.14.0-570.42.2.el9_6 #579
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jira LE-4159 cve CVE-2025-38392 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Ahmed Zaki <ahmed.zaki@intel.com> commit b2beb5b With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated on module load: [ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578 [ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager [ 324.701689] preempt_count: 201, expected: 0 [ 324.701693] RCU nest depth: 0, expected: 0 [ 324.701697] 2 locks held by NetworkManager/1582: [ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0 [ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870 [ 324.701749] Preemption disabled at: [ 324.701752] [<ffffffff9cd23b9d>] __dev_open+0x3dd/0x870 [ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary) [ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022 [ 324.701774] Call Trace: [ 324.701777] <TASK> [ 324.701779] dump_stack_lvl+0x5d/0x80 [ 324.701788] ? __dev_open+0x3dd/0x870 [ 324.701793] __might_resched.cold+0x1ef/0x23d <..> [ 324.701818] __mutex_lock+0x113/0x1b80 <..> [ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf] [ 324.701935] ? kasan_save_track+0x14/0x30 [ 324.701941] idpf_mb_clean+0x143/0x380 [idpf] <..> [ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf] [ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf] [ 324.702021] ? rcu_is_watching+0x12/0xc0 [ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf] <..> [ 324.702122] __hw_addr_sync_dev+0x1cf/0x300 [ 324.702126] ? find_held_lock+0x32/0x90 [ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf] [ 324.702152] __dev_open+0x3f8/0x870 [ 324.702159] ? __pfx___dev_open+0x10/0x10 [ 324.702174] __dev_change_flags+0x443/0x650 <..> [ 324.702208] netif_change_flags+0x80/0x160 [ 324.702218] do_setlink.isra.0+0x16a0/0x3960 <..> [ 324.702349] rtnl_newlink+0x12fd/0x21e0 The sequence is as follows: rtnl_newlink()-> __dev_change_flags()-> __dev_open()-> dev_set_rx_mode() - > # disables BH and grabs "dev->addr_list_lock" idpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON __dev_uc_sync() -> idpf_add_mac_filter -> idpf_add_del_mac_filters -> idpf_send_mb_msg() -> idpf_mb_clean() -> idpf_ctlq_clean_sq() # mutex_lock(cq_lock) Fix by converting cq_lock to a spinlock. All operations under the new lock are safe except freeing the DMA memory, which may use vunmap(). Fix by requesting a contiguous physical memory for the DMA mapping. Fixes: a251eee ("idpf: add SRIOV support and other ndo_ops") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> (cherry picked from commit b2beb5b) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 cve CVE-2025-37803 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Xiaogang Chen <xiaogang.chen@amd.com> commit 021ba7f by casting size_limit_mb to u64 when calculate pglimit. Signed-off-by: Xiaogang Chen<Xiaogang.Chen@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250321164126.329638-1-xiaogang.chen@amd.com Signed-off-by: Christian König <christian.koenig@amd.com> (cherry picked from commit 021ba7f) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Herbert Xu <herbert@gondor.apana.org.au> commit bcd6e41 Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-5.14.0-570.41.1.el9_6/bcd6e41d.failed The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit bcd6e41) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # crypto/crypto_engine.c # include/crypto/engine.h
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Chen Ridong <chenridong@huawei.com> commit 15589bd The tegra_cmac_init or tegra_sha_init function may return an error when memory is exhausted. It should not transfer the request when they return an error. Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Chen Ridong <chenridong@huawei.com> Acked-by: Akhil R <akhilrajeev@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 15589bd) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Colin Ian King <colin.i.king@gmail.com> commit 7b90df7 Currently there is an unnecessary error check on ret without a proceeding assignment to ret that needs checking. The check is redundant and can be removed. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 7b90df7) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Ovidiu Panait <ovidiu.panait.oss@gmail.com> commit 6ef46fe The explicit crypto_engine_stop() call is not needed, as it is already called internally by crypto_engine_exit(). Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 6ef46fe) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit bcfc8fc The buffer which sends the commands to host1x was shared for all tasks in the engine. This causes a problem with the setkey() function as it gets called asynchronous to the crypto engine queue. Modifying the same cmdbuf in setkey() will corrupt the ongoing host1x task and in turn break the encryption/decryption operation. Hence use a separate cmdbuf for setkey(). Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit bcfc8fc) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit 1cb328d Allocate the buffer based on the request instead of a fixed buffer length. In operations which may require larger buffer size, a fixed buffer may fail. Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 1cb328d) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit 1e24594 Call the crypto finalize function before exiting *do_one_req() functions. This allows the driver to take up further requests even if the previous one fails. Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 1e24594) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit dcf8b7e Initialize and check the return value in hash *do_one_req() functions and exit the function if there is an error. This fixes the 'uninitialized variable' warnings reported by testbots. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202412071747.flPux4oB-lkp@intel.com/ Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit dcf8b7e) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit 97ee15e Ahash init() function was called asynchronous to the crypto engine queue. This could corrupt the request context if there is any ongoing operation for the same request. Queue the init function as well to the crypto engine queue so that this scenario can be avoided. Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 97ee15e) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit ff4b7df The intermediate hash values generated during an update task were handled incorrectly in the driver. The values have a defined format for each algorithm. Copying and pasting from the HASH_RESULT register balantly would not work for all the supported algorithms. This incorrect handling causes failures when there is a context switch between multiple operations. To handle the expected format correctly, add a separate buffer for storing the intermediate results for each request. Remove the previous copy/paste functions which read/wrote to the registers directly. Instead configure the hardware to get the intermediate result copied to the buffer and use host1x path to restore the intermediate hash results. Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit ff4b7df) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit ce390d6 Saving and restoring of the intermediate results are needed if there is context switch caused by another ongoing request on the same engine. This is therefore not only to support import/export functionality. Hence, save and restore the intermediate result for every non-first task. Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit ce390d6) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit bde5582 It may happen that the variable req->iv may have stale values or zero sized buffer by default and may end up getting used during encryption/decryption. This inturn may corrupt the results or break the operation. Set the req->iv variable to NULL explicitly for algorithms like AES-ECB where IV is not used. Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit bde5582) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit b157e7a The HW supports only storing 15 keys at a time. This limits the number of tfms that can work without failutes. Reserve keyslots to solve this and use the reserved ones during the encryption/decryption operation. This allow users to have the capability of hardware protected keys and faster operations if there are limited number of tfms while not halting the operation if there are more tfms. Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit b157e7a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit f80a2e2 The intermediate results for HMAC is stored in the allocated keyslot by the hardware. Dynamic allocation of keyslot during an operation is hence not possible. As the number of keyslots are limited in the hardware, fallback to the HMAC software implementation if keyslots are not available Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit f80a2e2) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Nathan Chancellor <nathan@kernel.org> commit 795e5bd When building for 32-bit targets, for which ssize_t is 'int' instead of 'long', there is a warning due to an incorrect format specifier: In file included from include/linux/printk.h:610, from include/linux/kernel.h:31, from include/linux/clk.h:13, from drivers/crypto/tegra/tegra-se-hash.c:7: drivers/crypto/tegra/tegra-se-hash.c: In function 'tegra_sha_prep_cmd': drivers/crypto/tegra/tegra-se-hash.c:343:26: error: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'ssize_t' {aka 'int'} [-Werror=format=] 343 | dev_dbg(se->dev, "msg len %llu msg left %llu sz %lu cfg %#x", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... drivers/crypto/tegra/tegra-se-hash.c:343:59: note: format string is defined here 343 | dev_dbg(se->dev, "msg len %llu msg left %llu sz %lu cfg %#x", | ~~^ | | | long unsigned int | %u cc1: all warnings being treated as errors Use '%zd', the proper specifier for ssize_t, to resolve the warning. Fixes: ff4b7df ("crypto: tegra - Fix HASH intermediate result handling") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 795e5bd) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Akhil R <akhilrajeev@nvidia.com> commit 1ddaff4 Modifying the crypto_request turns out to be not the right way to handle the stale value issue with the IV. Though the IV is not used for AES ECB, it eventually get used in algorithms like LRW in the next step after AES ECB encryption/decryption. Setting req->iv to NULL breaks the implementation of such algorithms. Hence modify only the local reqctx to check for IV. Fixes: bde5582 ("crypto: tegra - Set IV to NULL explicitly for AES ECB") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 1ddaff4) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Jeff Layton <jlayton@kernel.org> commit 9448765 Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-5.14.0-570.41.1.el9_6/94487653.failed In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Acked-by: Tom Talpey <tom@talpey.com> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Jeff Layton <jlayton@kernel.org> Acked-by: Steve French <stfrench@microsoft.com> Message-Id: <20230705190309.579783-72-jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org> (cherry picked from commit 9448765) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/smb/server/smb2pdu.c
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Paulo Alcantara <pc@manguebit.org> commit 0af1561 According to some logs reported by customers, CIFS client might end up reporting unlinked files as existing in stat(2) due to concurrent opens racing with unlink(2). Besides sending the removal request to the server, the unlink process could involve closing any deferred close as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens. Fix this by unhashing the dentry in cifs_unlink() to prevent any subsequent opens. Any open attempts, while we're still unlinking, will block on parent's i_rwsem. Reported-by: Jay Shin <jaeshin@redhat.com> Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Reviewed-by: David Howells <dhowells@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com> (cherry picked from commit 0af1561) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Paulo Alcantara <pc@manguebit.org> commit d84291f Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file. Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target. Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Reviewed-by: David Howells <dhowells@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com> (cherry picked from commit d84291f) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Nick Child <nnac123@linux.ibm.com> commit 127b721 netif_stop_all_queues must be called before calling H_FREE_LOGICAL_LAN. As a result, we can remove the pool_config field from the ibmveth adapter structure. Some device configuration changes call ibmveth_close in order to free the current resources held by the device. These functions then make their changes and call ibmveth_open to reallocate and reserve resources for the device. Prior to this commit, the flag pool_config was used to tell ibmveth_close that it should not halt the transmit queue. pool_config was introduced in commit 860f242 ("[PATCH] ibmveth change buffer pools dynamically") to avoid interrupting the tx flow when making rx config changes. Since then, other commits adopted this approach, even if making tx config changes. The issue with this approach was that the hypervisor freed all of the devices control structures after the hcall H_FREE_LOGICAL_LAN was performed but the transmit queues were never stopped. So the higher layers in the network stack would continue transmission but any H_SEND_LOGICAL_LAN hcall would fail with H_PARAMETER until the hypervisor's structures for the device were allocated with the H_REGISTER_LOGICAL_LAN hcall in ibmveth_open. This resulted in no real networking harm but did cause several of these error messages to be logged: "h_send_logical_lan failed with rc=-4" So, instead of trying to keep the transmit queues alive during network configuration changes, just stop the queues, make necessary changes then restart the queues. Signed-off-by: Nick Child <nnac123@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 127b721) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Dave Marquardt <davemarq@linux.ibm.com> commit 053f3ff v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable. Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool*/*. You can do this easily with a little shell script. This causes a hang. I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684183][ T123] #1: c00000000aee2288 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684194][ T123] #2: c0000000366f4ba8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684205][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_disable+0x30/0x60 [ 243.684216][ T123] #4: c0000003ff9bbf18 (&rq->__lock){-.-.}-{2:2}, at: __schedule+0x138/0x12a0 From the ibmveth debug, two threads are calling veth_pool_store, which calls ibmveth_close and ibmveth_open. Here's the sequence: T4365 T4366 ----------------- ----------------- --------- veth_pool_store veth_pool_store ibmveth_close ibmveth_close napi_disable napi_disable ibmveth_open napi_enable <- HANG ibmveth_close calls napi_disable at the top and ibmveth_open calls napi_enable at the top. https://docs.kernel.org/networking/napi.html]] says The control APIs are not idempotent. Control API calls are safe against concurrent use of datapath APIs but an incorrect sequence of control API calls may result in crashes, deadlocks, or race conditions. For example, calling napi_disable() multiple times in a row will deadlock. In the normal open and close paths, rtnl_mutex is acquired to prevent other callers. This is missing from veth_pool_store. Use rtnl_mutex in veth_pool_store fixes these hangs. Signed-off-by: Dave Marquardt <davemarq@linux.ibm.com> Fixes: 860f242 ("[PATCH] ibmveth change buffer pools dynamically") Reviewed-by: Nick Child <nnac123@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250402154403.386744-1-davemarq@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 053f3ff) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.41.1.el9_6 commit-author Gaurav Batra <gbatra@linux.ibm.com> commit d36e3f1 When a device is opened by a userspace driver, via VFIO interface, DMA window is created. This DMA window has TCE Table and a corresponding data for userview of TCE table. When the userspace driver closes the device, all the above infrastructure is free'ed and the device control given back to kernel. Both DMA window and TCE table is getting free'ed. But due to a code bug, userview of the TCE table is not getting free'ed. This is resulting in a memory leak. Befow is the information from KMEMLEAK unreferenced object 0xc008000022af0000 (size 16777216): comm "senlib_unit_tes", pid 9346, jiffies 4294983174 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): kmemleak_vmalloc+0xc8/0x1a0 __vmalloc_node_range+0x284/0x340 vzalloc+0x58/0x70 spapr_tce_create_table+0x4b0/0x8d0 tce_iommu_create_table+0xcc/0x170 [vfio_iommu_spapr_tce] tce_iommu_create_window+0x144/0x2f0 [vfio_iommu_spapr_tce] tce_iommu_ioctl.part.0+0x59c/0xc90 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x88/0x280 [vfio] sys_ioctl+0xf4/0x160 system_call_exception+0x164/0x310 system_call_vectored_common+0xe8/0x278 unreferenced object 0xc008000023b00000 (size 4194304): comm "senlib_unit_tes", pid 9351, jiffies 4294984116 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): kmemleak_vmalloc+0xc8/0x1a0 __vmalloc_node_range+0x284/0x340 vzalloc+0x58/0x70 spapr_tce_create_table+0x4b0/0x8d0 tce_iommu_create_table+0xcc/0x170 [vfio_iommu_spapr_tce] tce_iommu_create_window+0x144/0x2f0 [vfio_iommu_spapr_tce] tce_iommu_create_default_window+0x88/0x120 [vfio_iommu_spapr_tce] tce_iommu_ioctl.part.0+0x57c/0xc90 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x88/0x280 [vfio] sys_ioctl+0xf4/0x160 system_call_exception+0x164/0x310 system_call_vectored_common+0xe8/0x278 Fixes: f431a8c ("powerpc/iommu: Reimplement the iommu_table_group_ops for pSeries") Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250512224653.35697-1-gbatra@linux.ibm.com (cherry picked from commit d36e3f1) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v5.14~1..kernel-mainline: 324124 Number of commits in rpm: 26 Number of commits matched with upstream: 24 (92.31%) Number of commits in upstream but not in rpm: 324100 Number of commits NOT found in upstream: 2 (7.69%) Rebuilding Kernel on Branch rocky9_6_rebuild_kernel-5.14.0-570.41.1.el9_6 for kernel-5.14.0-570.41.1.el9_6 Clean Cherry Picks: 22 (91.67%) Empty Cherry Picks: 2 (8.33%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-5.14.0-570.41.1.el9_6/rebuild.details.txt Includes: * git commit header above * Empty Commits with upstream SHA * RPM ChangeLog Entries that could not be matched Individual Empty Commit failures contained in the same containing directory. The git message for empty commits will have the path for the failed commit. File names are the first 8 characters of the upstream SHA
jira LE-4159 cve CVE-2025-38332 Rebuild_History Non-Buildable kernel-5.14.0-570.42.2.el9_6 commit-author Daniel Wagner <wagi@kernel.org> commit ae82eaf The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string. Signed-off-by: Daniel Wagner <wagi@kernel.org> Link: https://lore.kernel.org/r/20250409-fix-lpfc-bios-str-v1-1-05dac9e51e13@kernel.org Reviewed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit ae82eaf) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 cve CVE-2025-22097 Rebuild_History Non-Buildable kernel-5.14.0-570.42.2.el9_6 commit-author José Expósito <jose.exposito89@gmail.com> commit ed15511 If the driver initialization fails, the vkms_exit() function might access an uninitialized or freed default_config pointer and it might double free it. Fix both possible errors by initializing default_config only when the driver initialization succeeded. Reported-by: Louis Chauvet <louis.chauvet@bootlin.com> Closes: https://lore.kernel.org/all/Z5uDHcCmAwiTsGte@louis-chauvet-laptop/ Fixes: 2df7af9 ("drm/vkms: Add vkms_config type") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmremann@suse.de> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212084912.3196-1-jose.exposito89@gmail.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> (cherry picked from commit ed15511) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 cve CVE-2025-38449 Rebuild_History Non-Buildable kernel-5.14.0-570.42.2.el9_6 commit-author Thomas Zimmermann <tzimmermann@suse.de> commit 5307dce A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below. [ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]--- Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references. Commit 1a148af ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before. v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/drm_gem.c#L241 # [1] Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Anusha Srivatsa <asrivats@redhat.com> Cc: Christian König <christian.koenig@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: <stable@vger.kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250630084001.293053-1-tzimmermann@suse.de (cherry picked from commit 5307dce) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 cve CVE-2025-38449 Rebuild_History Non-Buildable kernel-5.14.0-570.42.2.el9_6 commit-author Thomas Zimmermann <tzimmermann@suse.de> commit f6bfc9a Acquire GEM handles in drm_framebuffer_init() and release them in the corresponding drm_framebuffer_cleanup(). Ties the handle's lifetime to the framebuffer. Not all GEM buffer objects have GEM handles. If not set, no refcounting takes place. This is the case for some fbdev emulation. This is not a problem as these GEM objects do not use dma-bufs and drivers will not release them while fbdev emulation is running. Framebuffer flags keep a bit per color plane of which the framebuffer holds a GEM handle reference. As all drivers use drm_framebuffer_init(), they will now all hold dma-buf references as fixed in commit 5307dce ("drm/gem: Acquire references on GEM handles for framebuffers"). In the GEM framebuffer helpers, restore the original ref counting on buffer objects. As the helpers for handle refcounting are now no longer called from outside the DRM core, unexport the symbols. v3: - don't mix internal flags with mode flags (Christian) v2: - track framebuffer handle refs by flag - drop gma500 cleanup (Christian) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5307dce ("drm/gem: Acquire references on GEM handles for framebuffers") Reported-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/dri-devel/20250703115915.3096-1-spasswolf@web.de/ Tested-by: Bert Karwatzki <spasswolf@web.de> Tested-by: Mario Limonciello <superm1@kernel.org> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Anusha Srivatsa <asrivats@redhat.com> Cc: Christian König <christian.koenig@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: <stable@vger.kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250707131224.249496-1-tzimmermann@suse.de (cherry picked from commit f6bfc9a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.42.2.el9_6 commit-author Gaurav Batra <gbatra@linux.ibm.com> commit 6aa989a iommu_mem_notifier() is invoked when RAM is dynamically added/removed. This notifier call is responsible to add/remove TCEs from the Dynamic DMA Window (DDW) when TCEs are pre-mapped. TCEs are pre-mapped only for RAM and not for persistent memory (pmemory). For DMA buffers in pmemory, TCEs are dynamically mapped when the device driver instructs to do so. The issue is 'daxctl' command is capable of adding pmemory as "System RAM" after LPAR boot. The command to do so is - daxctl reconfigure-device --mode=system-ram dax0.0 --force This will dynamically add pmemory range to LPAR RAM eventually invoking iommu_mem_notifier(). The address range of pmemory is way beyond the Max RAM that the LPAR can have. Which means, this range is beyond the DDW created for the device, at device initialization time. As a result when TCEs are pre-mapped for the pmemory range, by iommu_mem_notifier(), PHYP HCALL returns H_PARAMETER. This failed the command, daxctl, to add pmemory as RAM. The solution is to not pre-map TCEs for pmemory. Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com> Tested-by: Donet Tom <donettom@linux.ibm.com> Reviewed-by: Donet Tom <donettom@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250130183854.92258-1-gbatra@linux.ibm.com (cherry picked from commit 6aa989a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
… 64-bits jira LE-4159 Rebuild_History Non-Buildable kernel-5.14.0-570.42.2.el9_6 commit-author Gaurav Batra <gbatra@linux.ibm.com> commit 67dfc11 Starting with PAPR level 2.13, platform supports placing PHB in limited address mode. Devices that support DMA masks less that 64-bit but greater than 32-bits are placed in limited address mode. In this mode, the starting DMA address returned by the DDW is 4GB. When the device driver calls dma_supported, with mask less then 64-bit, the PowerPC IOMMU driver places PHB in the Limited Addressing Mode before creating DDW. Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250108164814.73250-1-gbatra@linux.ibm.com (cherry picked from commit 67dfc11) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…x_cpu_timer_del() jira LE-4159 cve CVE-2025-38352 Rebuild_History Non-Buildable kernel-5.14.0-570.42.2.el9_6 commit-author Oleg Nesterov <oleg@redhat.com> commit f90fff1 If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail. Add the tsk->exit_state check into run_posix_cpu_timers() to fix this. This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case. Cc: stable@vger.kernel.org Reported-by: Benoît Sevens <bsevens@google.com> Fixes: 0bdd2ed ("sched: run_posix_cpu_timers: Don't check ->exit_state, use lock_task_sighand()") Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit f90fff1) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v5.14~1..kernel-mainline: 324124 Number of commits in rpm: 9 Number of commits matched with upstream: 7 (77.78%) Number of commits in upstream but not in rpm: 324117 Number of commits NOT found in upstream: 2 (22.22%) Rebuilding Kernel on Branch rocky9_6_rebuild_kernel-5.14.0-570.42.2.el9_6 for kernel-5.14.0-570.42.2.el9_6 Clean Cherry Picks: 7 (100.00%) Empty Cherry Picks: 0 (0.00%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-5.14.0-570.42.2.el9_6/rebuild.details.txt Includes: * git commit header above * Empty Commits with upstream SHA * RPM ChangeLog Entries that could not be matched Individual Empty Commit failures contained in the same containing directory. The git message for empty commits will have the path for the failed commit. File names are the first 8 characters of the upstream SHA
PlaidCat
requested review from
kerneltoast,
bmastbergen,
thefossguy-ciq and
shreeya-patel98
shreeya-patel98
approved these changes
Sep 18, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the attempt at a re-builder built on Cron and some internal tools, but the same process is as follows as previous rebuilds
src.rpm5.14.0-570git cherry-pickrpmbuild -bpfrom corresponding src.rpm.Rebuild Splat Inspection
kernel-5.14.0-570.41.1.el9_6
kernel-5.14.0-570.42.2.el9_6
Build
KselfTest