[rocky9_6] History Rebuild through kernel-5.14.0-570.60.1.el9_6 #673
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-4649 cve CVE-2025-39702 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author Eric Biggers <[email protected]> commit a458b29 To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: bf355b8 ("ipv6: sr: add core files for SR HMAC support") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Reviewed-by: Andrea Mayer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit a458b29) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-4649 cve CVE-2022-50367 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author Dongliang Mu <[email protected]> commit 2e488f1 In alloc_inode, inode_init_always() could return -ENOMEM if security_inode_alloc() fails, which causes inode->i_private uninitialized. Then nilfs_is_metadata_file_inode() returns true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(), which frees the uninitialized inode->i_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes) Link: https://lkml.kernel.org/r/CAFcO6XOcf1Jj2SeGt=jJV59wmhESeSKpfR0omdFRq+J9nD1vfQ@mail.gmail.com Reported-by: butt3rflyh4ck <[email protected]> Reported-by: Hao Sun <[email protected]> Reported-by: Jiacheng Xu <[email protected]> Reviewed-by: Christian Brauner (Microsoft) <[email protected]> Signed-off-by: Dongliang Mu <[email protected]> Cc: Al Viro <[email protected]> Cc: [email protected] Signed-off-by: Al Viro <[email protected]> (cherry picked from commit 2e488f1) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-4649 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author Benjamin Coddington <[email protected]> commit 8b3ac9f 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.60.1.el9_6/8b3ac9fa.failed While investigating some reports of memory-constrained NUMA machines failing to mount v3 and v4.0 nfs mounts, we found that svc_init_buffer() was not attempting to retry allocations from the bulk page allocator. Typically, this results in a single page allocation being returned and the mount attempt fails with -ENOMEM. A retry would have allowed the mount to succeed. Additionally, it seems that the bulk allocation in svc_init_buffer() is redundant because svc_alloc_arg() will perform the required allocation and does the correct thing to retry the allocations. The call to allocate memory in svc_alloc_arg() drops the preferred node argument, but I expect we'll still allocate on the preferred node because the allocation call happens within the svc thread context, which chooses the node with memory closest to the current thread's execution. This patch cleans out the bulk allocation in svc_init_buffer() to allow svc_alloc_arg() to handle the allocation/retry logic for rq_pages. Signed-off-by: Benjamin Coddington <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Fixes: ed603bc ("sunrpc: Replace the rq_pages array with dynamically-allocated memory") Signed-off-by: Chuck Lever <[email protected]> (cherry picked from commit 8b3ac9f) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # net/sunrpc/svc.c
jira LE-4649 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author Benjamin Coddington <[email protected]> commit 77be29b The NFS client's list of delegations can grow quite large (well beyond the delegation watermark) if the server is revoking or there are repeated events that expire state. Once this happens, the revoked delegations can cause a performance problem for subsequent walks of the servers->delegations list when the client tries to test and free state. If we can determine that the FREE_STATEID operation has completed without error, we can prune the delegation from the list. Since the NFS client combines TEST_STATEID with FREE_STATEID in its minor version operations, there isn't an easy way to communicate success of FREE_STATEID. Rather than re-arrange quite a number of calling paths to break out the separate procedures, let's signal the success of FREE_STATEID by setting the stateid's type. Set NFS4_FREED_STATEID_TYPE for stateids that have been successfully discarded from the server, and use that type to signal that the delegation can be cleaned up. Signed-off-by: Benjamin Coddington <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> (cherry picked from commit 77be29b) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-4649 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author James Morse <[email protected]> commit 7da540e 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.60.1.el9_6/7da540e2.failed The sys_reg_descs array holds function pointers and reset value for managing the user-space and guest view of system registers. These are mostly created by a set of macro's as only some combinations of behaviour are needed. If a register needs special treatment, its sys_reg_descs entry is open-coded. This is true of some id registers where the value provided by user-space is validated by some helpers. Before adding another one of these, add a helper that covers the existing special cases. 'ID_FILTERED' expects helpers to set the user-space value, and retrieve the modified reset value. Like ID_WRITABLE() this uses id_visibility(), which should have no functional change for the registers converted to use ID_FILTERED(). read_sanitised_id_aa64dfr0_el1() and read_sanitised_id_aa64pfr0_el1() have been refactored to be called from kvm_read_sanitised_id_reg(), to try be consistent with ID_WRITABLE(). Signed-off-by: James Morse <[email protected]> Signed-off-by: Joey Gouly <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Tested-by: Shameer Kolothum <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]> (cherry picked from commit 7da540e) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # arch/arm64/kvm/sys_regs.c
jira LE-4649 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author James Morse <[email protected]> commit 6685f5d 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.60.1.el9_6/6685f5d5.failed commit 011e5f5 ("arm64/cpufeature: Add remaining feature bits in ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to guests, but didn't add trap handling. A previous patch supplied the missing trap handling. Existing VMs that have the MPAM field of ID_AA64PFR0_EL1 set need to be migratable, but there is little point enabling the MPAM CPU interface on new VMs until there is something a guest can do with it. Clear the MPAM field from the guest's ID_AA64PFR0_EL1 and on hardware that supports MPAM, politely ignore the VMMs attempts to set this bit. Guests exposed to this bug have the sanitised value of the MPAM field, so only the correct value needs to be ignored. This means the field can continue to be used to block migration to incompatible hardware (between MPAM=1 and MPAM=5), and the VMM can't rely on the field being ignored. Signed-off-by: James Morse <[email protected]> Co-developed-by: Joey Gouly <[email protected]> Signed-off-by: Joey Gouly <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Tested-by: Shameer Kolothum <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]> (cherry picked from commit 6685f5d) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # arch/arm64/kvm/sys_regs.c
jira LE-4649 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author Michael Liang <[email protected]> commit 77e40bb This patch addresses a data corruption issue observed in nvme-tcp during testing. In an NVMe native multipath setup, when an I/O timeout occurs, all inflight I/Os are canceled almost immediately after the kernel socket is shut down. These canceled I/Os are reported as host path errors, triggering a failover that succeeds on a different path. However, at this point, the original I/O may still be outstanding in the host's network transmission path (e.g., the NIC’s TX queue). From the user-space app's perspective, the buffer associated with the I/O is considered completed since they're acked on the different path and may be reused for new I/O requests. Because nvme-tcp enables zero-copy by default in the transmission path, this can lead to corrupted data being sent to the original target, ultimately causing data corruption. We can reproduce this data corruption by injecting delay on one path and triggering i/o timeout. To prevent this issue, this change ensures that all inflight transmissions are fully completed from host's perspective before returning from queue stop. To handle concurrent I/O timeout from multiple namespaces under the same controller, always wait in queue stop regardless of queue's state. This aligns with the behavior of queue stopping in other NVMe fabric transports. Fixes: 3f2304f ("nvme-tcp: add NVMe over TCP host driver") Signed-off-by: Michael Liang <[email protected]> Reviewed-by: Mohamed Khalfella <[email protected]> Reviewed-by: Randy Jennings <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> (cherry picked from commit 77e40bb) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-4649 cve CVE-2023-53494 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author Herbert Xu <[email protected]> commit 51c0825 As it is xts only handles the special return value of EINPROGRESS, which means that in all other cases it will free data related to the request. However, as the caller of xts may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free. Fixes: 8083b1b ("crypto: xts - add support for ciphertext stealing") Signed-off-by: Herbert Xu <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit 51c0825) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-4649 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author Dave Marquardt <[email protected]> commit 2c91e23 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.60.1.el9_6/2c91e231.failed Reset the adapter through new function ibmveth_reset, called in WARN_ON situations. Removed conflicting and unneeded forward declaration. Signed-off-by: Dave Marquardt <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> (cherry picked from commit 2c91e23) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # drivers/net/ethernet/ibm/ibmveth.h
jira LE-4649 Rebuild_History Non-Buildable kernel-5.14.0-570.60.1.el9_6 commit-author Mingming Cao <[email protected]> commit 2094200 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.60.1.el9_6/2094200b.failed This patch enables batched RX buffer replenishment in ibmveth by using the new firmware-supported h_add_logical_lan_buffers() hcall to submit up to 8 RX buffers in a single call, instead of repeatedly calling the single-buffer h_add_logical_lan_buffer() hcall. During the probe, with the patch, the driver queries ILLAN attributes to detect IBMVETH_ILLAN_RX_MULTI_BUFF_SUPPORT bit. If the attribute is present, rx_buffers_per_hcall is set to 8, enabling batched replenishment. Otherwise, it defaults to 1, preserving the original upstream behavior with no change in code flow for unsupported systems. The core rx replenish logic remains the same. But when batching is enabled, the driver aggregates up to 8 fully prepared descriptors into a single h_add_logical_lan_buffers() hypercall. If any allocation or DMA mapping fails while preparing a batch, only the successfully prepared buffers are submitted, and the remaining are deferred for the next replenish cycle. If at runtime the firmware stops accepting the batched hcall—e,g, after a Live Partition Migration (LPM) to a host that does not support h_add_logical_lan_buffers(), the hypercall returns H_FUNCTION. In that case, the driver transparently disables batching, resets rx_buffers_per_hcall to 1, and falls back to the single-buffer hcall in next future replenishments to take care of these and future buffers. Test were done on systems with firmware that both supports and does not support the new h_add_logical_lan_buffers hcall. On supported firmware, this reduces hypercall overhead significantly over multiple buffers. SAR measurements showed about a 15% improvement in packet processing rate under moderate RX load, with heavier traffic seeing gains more than 30% Signed-off-by: Mingming Cao <[email protected]> Reviewed-by: Brian King <[email protected]> Reviewed-by: Haren Myneni <[email protected]> Reviewed-by: Dave Marquardt <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> (cherry picked from commit 2094200) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # drivers/net/ethernet/ibm/ibmveth.c # drivers/net/ethernet/ibm/ibmveth.h
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: 12 Number of commits matched with upstream: 10 (83.33%) Number of commits in upstream but not in rpm: 324114 Number of commits NOT found in upstream: 2 (16.67%) Rebuilding Kernel on Branch rocky9_6_rebuild_kernel-5.14.0-570.60.1.el9_6 for kernel-5.14.0-570.60.1.el9_6 Clean Cherry Picks: 5 (50.00%) Empty Cherry Picks: 5 (50.00%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-5.14.0-570.60.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
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.60.1.el9_6
Automation results
Build
KSelfTests