[rocky9_8] History Rebuild through kernel-5.14.0-687.38.1.el9_8 - #1527
Open
PlaidCat wants to merge 10 commits into
Open
[rocky9_8] History Rebuild through kernel-5.14.0-687.38.1.el9_8#1527PlaidCat wants to merge 10 commits into
PlaidCat wants to merge 10 commits into
Conversation
… op cache jira KERNEL-1468 cve CVE-2025-54518 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Prathyushi Nangia <prathyushi.nangia@amd.com> commit c21b90f 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-687.38.1.el9_8/c21b90f7.failed Make sure resources are not improperly shared in the op cache and cause instruction corruption this way. Signed-off-by: Prathyushi Nangia <prathyushi.nangia@amd.com> Co-developed-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit c21b90f) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # arch/x86/kernel/cpu/amd.c # tools/arch/x86/include/asm/msr-index.h
jira KERNEL-1468 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Dragos Tatulea <dtatulea@nvidia.com> commit 894e036 mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 </TASK> Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max. Fixes: e16aea2 ("net/mlx5: Introduce access functions to modify/query vport mac lists") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260604135849.458060-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 894e036) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1468 cve CVE-2026-31530 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Alison Schofield <alison.schofield@intel.com> commit 19d2f0b cxl_detach_ep() is called during bottom-up removal when all CXL memory devices beneath a switch port have been removed. For each port in the hierarchy it locks both the port and its parent, removes the endpoint, and if the port is now empty, marks it dead and unregisters the port by calling delete_switch_port(). There are two places during this work where the parent_port may be used after freeing: First, a concurrent detach may have already processed a port by the time a second worker finds it via bus_find_device(). Without pinning parent_port, it may already be freed when we discover port->dead and attempt to unlock the parent_port. In a production kernel that's a silent memory corruption, with lock debug, it looks like this: []DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current()) []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310 []Call Trace: []mutex_unlock+0xd/0x20 []cxl_detach_ep+0x180/0x400 [cxl_core] []devm_action_release+0x10/0x20 []devres_release_all+0xa8/0xe0 []device_unbind_cleanup+0xd/0xa0 []really_probe+0x1a6/0x3e0 Second, delete_switch_port() releases three devm actions registered against parent_port. The last of those is unregister_port() and it calls device_unregister() on the child port, which can cascade. If parent_port is now also empty the device core may unregister and free it too. So by the time delete_switch_port() returns, parent_port may be free, and the subsequent device_unlock(&parent_port->dev) operates on freed memory. The kernel log looks same as above, with a different offset in cxl_detach_ep(). Both of these issues stem from the absence of a lifetime guarantee between a child port and its parent port. Establish a lifetime rule for ports: child ports hold a reference to their parent device until release. Take the reference when the port is allocated and drop it when released. This ensures the parent is valid for the full lifetime of the child and eliminates the use after free window in cxl_detach_ep(). This is easily reproduced with a reload of cxl_acpi in QEMU with CXL devices present. Fixes: 2345df5 ("cxl/memdev: Fix endpoint port removal") Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Li Ming <ming.li@zohomail.com> Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260226184439.1732841-1-alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 19d2f0b) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1468 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Holger Dengler <dengler@linux.ibm.com> commit b3d4ab2 Explicitly check the buffer length request structure provided by user-space and fail, if it exceeds the buffer size. Cc: stable@vger.kernel.org Fixes: 8fcc231 ("s390/pkey: Introduce pkey base with handler registry and handler modules") Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> (cherry picked from commit b3d4ab2) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1468 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Holger Dengler <dengler@linux.ibm.com> commit 1ac287e Explicitly check the length of the target buffer in the pkey_pckmo implementation of the key_to_protkey() handler function. The handler function fails, if the generated output data exceeds the length of the provided target buffer. Cc: stable@vger.kernel.org Fixes: 8fcc231 ("s390/pkey: Introduce pkey base with handler registry and handler modules") Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> (cherry picked from commit 1ac287e) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…abled jira KERNEL-1468 cve CVE-2026-64368 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Vlastimil Babka (SUSE) <vbabka@kernel.org> commit 648927c When init (zeroing) on allocation is requested, for kmalloc() we generally have to zero the full object size even if a smaller size is requested, in order to provide krealloc()'s __GFP_ZERO guarantees. But if we track the requested size, krealloc() uses that information to do the right thing, so we can zero only the requested size. With red zoning also enabled, any extra size became part of the red zone, so it must not be zeroed and thus we must zero only the requested size. However the current check is imprecise, and will trigger also when only SLAB_RED_ZONE is enabled without SLAB_STORE_USER (which enables tracking the requested size). This means enabling red zoning alone can compromise krealloc()'s __GFP_ZERO contract. Fix this by using slub_debug_orig_size() instead, which is the exact check for whether the requested size is tracked. We don't need to care if red zoning is also enabled or not. Also update and expand the comment accordingly. Fixes: 9ce6739 ("mm/slub: only zero requested size of buffer for kzalloc when debug enabled") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260610-slab_alloc_flags-v2-1-7190909db118@kernel.org Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Hao Li <hao.li@linux.dev> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> (cherry picked from commit 648927c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1468 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Paulo Alcantara <pc@manguebit.org> commit 4fc3a43 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-687.38.1.el9_8/4fc3a433.failed Use atomic_t for cifs_sb_info::mnt_cifs_flags as it's currently accessed locklessly and may be changed concurrently in mount/remount and reconnect paths. Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Reviewed-by: David Howells <dhowells@redhat.com> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com> (cherry picked from commit 4fc3a43) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/smb/client/cifs_unicode.h # fs/smb/client/cifsfs.c # fs/smb/client/dir.c # fs/smb/client/file.c # fs/smb/client/fs_context.h # fs/smb/client/inode.c # fs/smb/client/smb1ops.c
jira KERNEL-1468 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Arnd Bergmann <arnd@arndb.de> commit fae1133 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-687.38.1.el9_8/fae11330.failed The newly introduced variable is initialized in an #ifdef block but used outside of it, leading to undefined behavior when CONFIG_CIFS_ALLOW_INSECURE_LEGACY is disabled: fs/smb/client/dir.c:417:9: error: variable 'sbflags' is uninitialized when used here [-Werror,-Wuninitialized] 417 | if (sbflags & CIFS_MOUNT_DYNPERM) | ^~~~~~~ Move the initialization into the declaration, the same way as the other similar function do it. Fixes: 4fc3a43 ("smb: client: use atomic_t for mnt_cifs_flags") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Signed-off-by: Steve French <stfrench@microsoft.com> (cherry picked from commit fae1133) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/smb/client/dir.c
jira KERNEL-1468 Rebuild_History Non-Buildable kernel-5.14.0-687.38.1.el9_8 commit-author Paulo Alcantara <pc@manguebit.org> commit c4d3fc5 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-687.38.1.el9_8/c4d3fc58.failed When calling cifs_mount_get_tcon() with SMB1 UNIX mounts, @cifs_sb->mnt_cifs_flags needs to be read or updated only after calling reset_cifs_unix_caps(), otherwise it might end up with missing CIFS_MOUNT_POSIXACL and CIFS_MOUNT_POSIX_PATHS bits. This fixes the wrong dir separator used in paths caused by the missing CIFS_MOUNT_POSIX_PATHS bit in cifs_sb_info::mnt_cifs_flags. Reported-by: "Kris Karas (Bug Reporting)" <bugs-a21@moonlit-rail.com> Closes: https://lore.kernel.org/r/f758f4ff-4d54-4244-931d-38f469c3ff14@moonlit-rail.com Fixes: 4fc3a43 ("smb: client: use atomic_t for mnt_cifs_flags") Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Cc: David Howells <dhowells@redhat.com> Cc: linux-cifs@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com> (cherry picked from commit c4d3fc5) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/smb/client/connect.c # fs/smb/client/smb1ops.c
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v5.14~1..kernel-mainline: 394115 Number of commits in rpm: 17 Number of commits matched with upstream: 9 (52.94%) Number of commits in upstream but not in rpm: 394106 Number of commits NOT found in upstream: 8 (47.06%) Rebuilding Kernel on Branch rocky9_8_rebuild_kernel-5.14.0-687.38.1.el9_8 for kernel-5.14.0-687.38.1.el9_8 Clean Cherry Picks: 5 (55.56%) Empty Cherry Picks: 4 (44.44%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-5.14.0-687.38.1.el9_8/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
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
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 an automated kernel history rebuild using cron and internal tooling. It follows the same process used for previous history rebuilds:
src.rpmpackagessrc.rpm:5.14.0-687)git cherry-pickrpmbuild -bpfor the correspondingsrc.rpmJIRA Tickets
Rebuild Splat Inspection
kernel-5.14.0-687.38.1.el9_8
BUILD
KSelfTests