Repository navigation
[rocky8_10] History Rebuild through kernel-4.18.0-553.176.1.el8_10 - #1722
Merged
Merged
Conversation
jira KERNEL-1773 cve CVE-2026-52935 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Wyatt Feng <bronzed_45_vested@icloud.com> commit c381039 espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state. Fixes: e27cca9 ("xfrm: add espintcp (RFC 8229)") Cc: stable@kernel.org Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit c381039) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 cve CVE-2026-74588 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Baul Lee <baul.lee@xbow.com> commit 9f2cf06 __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport: if (chunk->tsn_gap_acked) { list_move_tail(&chunk->transmitted_list, &transport->transmitted); continue; } The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. sctp_assoc_rm_peer() scrubs peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on neither. The pointer is not followed while tsn_gap_acked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches tchunk->transport->flight_size -= sctp_data_size(tchunk); inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the removal and the SACKs come from the association peer. Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its list_move_tail() only after sctp_packet_append_chunk() returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the chunk by then. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> Fixes: 1da177e ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee <baul.lee@xbow.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260729160028.54546-1-baul.lee@xbow.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 9f2cf06) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 cve CVE-2026-89479 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Hyunwoo Kim <imv4bel@gmail.com> commit 47e15a8 sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone. Fixes: 1da177e ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/an-YYtoqw1QpTXUL@v4bel Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 47e15a8) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 cve CVE-2026-74752 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> commit 3dbb44d 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-4.18.0-553.176.1.el8_10/3dbb44d8.failed When cookie authentication is disabled, COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays. A forged RANDOM length can cause out-of-bounds reads during key-vector construction. A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain. Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association. Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids. Fixes: bbd0d59 ("[SCTP]: Implement the receive and verification of AUTH chunk") Fixes: 1f48564 ("[SCTP]: Implement SCTP-AUTH internals") Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260804200042.2412009-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 3dbb44d) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # include/net/sctp/auth.h
…rnet state jira KERNEL-1773 cve CVE-2026-93288 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Florian Westphal <fw@strlen.de> commit 33d1469 sashiko reports: "nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock()." Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data. Link: https://sashiko.dev/#/patchset/20260731151806.849724-1-pablo%40netfilter.org Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 33d1469) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Maoyi Xie <maoyixie.tju@gmail.com> commit 7e2a4f7 xfrm_send_migrate() in net/xfrm/xfrm_user.c and pfkey_send_migrate() in net/key/af_key.c both hardcode &init_net for the multicast that announces a successful XFRM_MSG_MIGRATE / SADB_X_MIGRATE. XFRM_MSG_MIGRATE arrives on a per-netns NETLINK_XFRM socket, and the rest of the xfrm/af_key netlink path was made netns-aware in 2008. The other 14 multicast paths in xfrm_user.c route their event using xs_net(x), xp_net(xp) or sock_net(skb->sk); only the migrate path was missed. Two consequences of the init_net hardcoding: 1. The notification (selector, old/new endpoint addresses, and the km_address) is delivered to listeners on init_net's XFRMNLGRP_MIGRATE / pfkey BROADCAST_ALL groups rather than on the issuing netns. An IKE daemon running in init_net therefore receives migration notifications originating from any other netns on the host. 2. An IKE daemon running inside a non-init netns and subscribed to its own XFRMNLGRP_MIGRATE / pfkey groups never receives the notification of its own migration. IKEv2 MOBIKE / address-update handling inside a netns is silently broken. Thread struct net through km_migrate() and the xfrm_mgr.migrate function pointer, drop the &init_net override in xfrm_send_migrate() and pfkey_send_migrate(), and pass the caller's net (already in scope in xfrm_migrate() via sock_net(skb->sk)) all the way down. struct xfrm_mgr is in-tree only and not exported as a stable API, so the function-pointer signature change is internal. pfkey_broadcast() is already netns-aware via net_generic(net, pfkey_net_id) since the pernet conversion. The five other pfkey_broadcast() callers in af_key.c already pass xs_net(x), sock_net(sk) or a per-netns net, so this only removes the &init_net outlier. Fixes: 5c79de6 ("[XFRM]: User interface for handling XFRM_MSG_MIGRATE") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit 7e2a4f7) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author David Ahern <dahern@nvidia.com> commit 742b04d Leo Lin reported OOB write issue in esp component: xfrm_state_mtu() returns u32 but performs its arithmetic in unsigned modulo-2^32 space using an attacker-influenced "header_len + authsize + net_adj" subtracted from a small "mtu" argument. A nobody user can install an IPv4 ESP tunnel SA with a large authentication key (XFRMA_ALG_AUTH_TRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc), configure a small interface MTU (68 bytes), and set XFRMA_TFCPAD to a large value. When a single UDP datagram is then sent through the tunnel, xfrm_state_mtu() underflows to a near-2^32 value, and esp_output() consumes it as a signed int via: padto = min(x->tfcpad, xfrm_state_mtu(x, mtu_cached)) esp.tfclen = padto - skb->len (assigned to int) esp.tfclen ends up negative (e.g. -207). It is sign-extended to size_t when passed to memset() inside esp_output_fill_trailer(), producing a ~16 EB write of zeroes at skb_tail_pointer(skb). KASAN logs it as "Write of size 18446744073709551537 at addr ffff888...". Check for underflow and return 1. This causes the sendmsg attempt to fail with ENETUNREACH. Fixes: c5c2523 ("[XFRM]: Optimize MTU calculation") Reported-by: Leo Lin <leo@depthfirst.com> Assisted-by: Codex:26.506.31004 Signed-off-by: David Ahern <dahern@nvidia.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit 742b04d) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Sabrina Dubroca <sd@queasysnail.net> commit deb232e ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed. Cc: stable@vger.kernel.org Fixes: e27cca9 ("xfrm: add espintcp (RFC 8229)") Reported-by: zdi-disclosures@trendmicro.com Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Breno Leitao <leitao@debian.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit deb232e) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…e parser jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Sabrina Dubroca <sd@queasysnail.net> commit 0984ebc The comment above strp_done() claims that if strp is stopped, strp_recv will no longer be called. That's only true if the caller has a mechanism (eg locking) to guarantee that strp_recv() calls that started before strp_stop() have completed by the time we call strp_done(). This adds a dummy lock_sock/release_sock pair to guarantee that any in-flight strp_recv() (which runs under either bh_lock_sock or lock_sock, depending if it's called from ->sk_data_ready or strp_work) has completed. Only espintcp can be affected by this race condition, but this patch makes sure no future user of strp can have the bug. This could crash on strp->sk ("general mode" of strp), but this mode has been here for 9 years and has never been used. It'll be gone soon, no point worrying about it. Switch the stopped/paused/etc bits to u8's to avoid races between strp_stop() and strp_pause/unpause(). A reproducer has been published and turns the possible UAF into an exploit [1]. Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Link: https://lore.kernel.org/all/aZLn2Faeg1FB7XOf@v4bel/ Link: https://lore.kernel.org/all/aZgpkyTDU3aXe_V0@v4bel/ Link: https://github.com/m0x41nos/RustyTux [1] Fixes: e27cca9 ("xfrm: add espintcp (RFC 8229)") Cc: stable@vger.kernel.org Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Hyunwoo Kim <imv4bel@gmail.com> Link: https://patch.msgid.link/425d9d926709b542ed5331110c19fee4aee1f28d.1791206940.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 0984ebc) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Bob Peterson <rpeterso@redhat.com> commit 9b62042 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-4.18.0-553.176.1.el8_10/9b620429.failed Before this patch, function gfs2_dinode_dealloc would abort if it got a bad return code from gfs2_rindex_update(). The problem is that it left the dinode in the unlinked (not free) state, which meant subsequent fsck would clean it up and flag an error. That meant some of our QE tests would fail. The sole purpose of gfs2_rindex_update(), in this code path, is to read in any newer rgrps added by gfs2_grow. But since this is a delete operation it won't actually use any of those new rgrps. It can really only twiddle the bits from "Unlinked" to "Free" in an existing rgrp. Therefore the error should not prevent the transition from unlinked to free. This patch makes gfs2_dinode_dealloc ignore the bad return code and proceed with freeing the dinode so the QE tests will not be tripped up. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 9b62042) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/super.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 015af1a 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-4.18.0-553.176.1.el8_10/015af1af.failed Mark the gfs2_withdrawn(), gfs2_withdrawing(), and gfs2_withdraw_in_prog() inline functions as likely to return %false. This allows to get rid of likely() and unlikely() annotations at the call sites of those functions. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 015af1a) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/file.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 6e42240 Since commit 601ef0d ("gfs2: Force withdraw to replay journals and wait for it to finish"), gfs2_withdraw() always returns -1, so turn it into a straight void function. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit 6e42240) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 9334c73 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-4.18.0-553.176.1.el8_10/9334c73f.failed Add a 'clean' argument to ->lm_unmount() that indicates whether the filesystem is clean or needs recovery. Set clean to true for normal unmounts, and to false for withdraws. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 9334c73) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/ops_fstype.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit f66af88 [ 81.372851][ T5532] CPU: 1 PID: 5532 Comm: syz-executor.0 Not tainted 6.2.0-rc1-syzkaller-dirty #0 [ 81.382080][ T5532] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 [ 81.392343][ T5532] Call Trace: [ 81.395654][ T5532] <TASK> [ 81.398603][ T5532] dump_stack_lvl+0x1b1/0x290 [ 81.418421][ T5532] gfs2_assert_warn_i+0x19a/0x2e0 [ 81.423480][ T5532] gfs2_quota_cleanup+0x4c6/0x6b0 [ 81.428611][ T5532] gfs2_make_fs_ro+0x517/0x610 [ 81.457802][ T5532] gfs2_withdraw+0x609/0x1540 [ 81.481452][ T5532] gfs2_inode_refresh+0xb2d/0xf60 [ 81.506658][ T5532] gfs2_instantiate+0x15e/0x220 [ 81.511504][ T5532] gfs2_glock_wait+0x1d9/0x2a0 [ 81.516352][ T5532] do_sync+0x485/0xc80 [ 81.554943][ T5532] gfs2_quota_sync+0x3da/0x8b0 [ 81.559738][ T5532] gfs2_sync_fs+0x49/0xb0 [ 81.564063][ T5532] sync_filesystem+0xe8/0x220 [ 81.568740][ T5532] generic_shutdown_super+0x6b/0x310 [ 81.574112][ T5532] kill_block_super+0x79/0xd0 [ 81.578779][ T5532] deactivate_locked_super+0xa7/0xf0 [ 81.584064][ T5532] cleanup_mnt+0x494/0x520 [ 81.593753][ T5532] task_work_run+0x243/0x300 [ 81.608837][ T5532] exit_to_user_mode_loop+0x124/0x150 [ 81.614232][ T5532] exit_to_user_mode_prepare+0xb2/0x140 [ 81.619820][ T5532] syscall_exit_to_user_mode+0x26/0x60 [ 81.625287][ T5532] do_syscall_64+0x49/0xb0 [ 81.629710][ T5532] entry_SYSCALL_64_after_hwframe+0x63/0xcd In this backtrace, gfs2_quota_sync() takes quota data references and then calls do_sync(). Function do_sync() encounters filesystem corruption and withdraws the filesystem, which (among other things) calls gfs2_quota_cleanup(). Function gfs2_quota_cleanup() wrongly assumes that nobody is holding any quota data references anymore, and destroys all quota data objects. When gfs2_quota_sync() then resumes and dereferences the quota data objects it is holding, those objects are no longer there. Function gfs2_quota_cleanup() deals with resource deallocation and can easily be delayed until gfs2_put_super() in the case of a filesystem withdraw. In fact, most of the other work gfs2_make_fs_ro() does is unnecessary during a withdraw as well, so change signal_our_withdraw() to skip gfs2_make_fs_ro() and perform the necessary steps directly instead. Thanks to Edward Adam Davis <eadavis@sina.com> for the initial patches. Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f@google.com Reported-by: syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit f66af88) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit fe4f794 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-4.18.0-553.176.1.el8_10/fe4f7940.failed The kernel threads are currently stopped and destroyed synchronously by gfs2_make_fs_ro() and gfs2_put_super(), and asynchronously by signal_our_withdraw(), with no synchronization, so the synchronous and asynchronous contexts can race with each other. First, when creating the kernel threads, take an extra task struct reference so that the task struct won't go away immediately when they terminate. This allows those kthreads to terminate immediately when they're done rather than hanging around as zombies until they are reaped by kthread_stop(). When kthread_stop() is called on a terminated kthread, it will return immediately. Second, in signal_our_withdraw(), once the SDF_JOURNAL_LIVE flag has been cleared, wake up the logd and quotad wait queues instead of stopping the logd and quotad kthreads. The kthreads are then expected to terminate automatically within short time, but if they cannot, they will not block the withdraw. For example, if a user process and one of the kthread decide to withdraw at the same time, only one of them will perform the actual withdraw and the other will wait for it to be done. If the kthread ends up being the one to wait, the withdrawing user process won't be able to stop it. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit fe4f794) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/super.h
jira KERNEL-1773 cve CVE-2023-52760 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Juntong Deng <juntong.deng@outlook.com> commit bdcb8aa 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-4.18.0-553.176.1.el8_10/bdcb8aa4.failed In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again. Reported-by: syzbot+29c47e9e51895928698c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=29c47e9e51895928698c Signed-off-by: Juntong Deng <juntong.deng@outlook.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit bdcb8aa) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/super.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 9c4a3de 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-4.18.0-553.176.1.el8_10/9c4a3de6.failed So far, withdraws are carried out in the context of the calling task. When another task tries to withdraw while a withdraw is already underway, that task blocks as well. Change that to carry out withdraws asynchronously in workqueue context and don't block the task triggering the withdraw anymore. Fixes: syzbot+6b156e132970e550194c@syzkaller.appspotmail.com Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 9c4a3de) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/super.c # fs/gfs2/util.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andrew Price <anprice@redhat.com> commit 0a828c3 bio->bi_status is an index into the blk_errors array, not an errno. Its __bitwise tag is cast away here, resulting in a sparse warning: fs/gfs2/lops.c:207:22: warning: cast from restricted blk_status_t We could either add __force to the cast and continue logging bi_status in the error message, or we could look up the errno in the array and log that. As sdp->sd_log_error is used as an errno in all other cases, look up the errno here for consistency. Signed-off-by: Andrew Price <anprice@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 0a828c3) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 0cdc6f4 In gfs2_fill_super(), when mounting a gfs2 filesystem is interrupted, kthread_create() can return -EINTR. When that happens, we roll back what has already been done and abort the mount. Since commit 62dd0f9 ("gfs2: Flag a withdraw if init_threads() fails), we are calling gfs2_withdraw_delayed() in gfs2_fill_super(); first via gfs2_make_fs_rw(), then directly. But gfs2_withdraw_delayed() only marks the filesystem as withdrawing and relies on a caller further up the stack to do the actual withdraw, which doesn't exist in the gfs2_fill_super() case. Because the filesystem is marked as withdrawing / withdrawn, function gfs2_lm_unmount() doesn't release the dlm lockspace, so when we try to mount that filesystem again, we get: gfs2: fsid=gohan:gohan0: Trying to join cluster "lock_dlm", "gohan:gohan0" gfs2: fsid=gohan:gohan0: dlm_new_lockspace error -17 Since commit b77b4a4 ("gfs2: Rework freeze / thaw logic"), the deadlock this gfs2_withdraw_delayed() call was supposed to work around cannot occur anymore because freeze_go_callback() won't take the sb->s_umount semaphore unconditionally anymore, so we can get rid of the gfs2_withdraw_delayed() in gfs2_fill_super() entirely. Reported-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Cc: stable@vger.kernel.org # v6.5+ (cherry picked from commit 0cdc6f4) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit e0f1f02 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-4.18.0-553.176.1.el8_10/e0f1f021.failed Lift the check for the SDF_WITHDRAWING flag out of gfs2_ail1_empty() and into its callers. This is needed so that gfs2_flush_revokes() can drop the sd_log_lock spinlock before triggering a withdraw if necessary. Instead of checking for the SDF_WITHDRAWING flag, use gfs2_withdrawing(). Also, the low-level code triggering the delayed withdraw reports when there is a problem, so there is no need to report that again. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit e0f1f02) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/log.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 8daf6c2 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-4.18.0-553.176.1.el8_10/8daf6c2b.failed Now that gfs2_withdraw() is asynchronous, is can be called in any context and there is no more need for gfs2_withdraw_delayed() or for turning delayed withdraws into actual withdraws. Remove the now-obsolete code. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 8daf6c2) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/glock.c # fs/gfs2/glops.c # fs/gfs2/log.c # fs/gfs2/util.h
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit e345b87 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-4.18.0-553.176.1.el8_10/e345b87b.failed Functions gfs2_freeze_super() and gfs2_thaw_super() are using the SDF_FROZEN flag to indicate when the filesystem is frozen, synchronized by sd_freeze_mutex. However, this doesn't prevent writes from happening between the point of calling thaw_super() and the point where the SDF_FROZEN flag is cleared, so the following assert can trigger in log_write_header(): gfs2_assert_withdraw(sdp, !test_bit(SDF_FROZEN, &sdp->sd_flags)); Fix that by checking for sb->s_writers.frozen != SB_FREEZE_COMPLETE in log_write_header() instead. To make sure that the filesystem-specific part of freezing happens before sb->s_writers.frozen is set to SB_FREEZE_COMPLETE, move that code from gfs2_freeze_locally() into gfs2_freeze_fs() and hook that up to the .freeze_fs operation. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit e345b87) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/log.c # fs/gfs2/super.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit b6900ce The DLM_LKF_QUECVT flag needs to be set for "upward" lock conversions to ensure fairness, but setting it for "downward" lock conversions will lead to a failure. The flag is currently set based on the GLF_BLOCKING flag and it's not immediately obvious why this is correct. Simplify things by figuring out if a lock conversion is "upward" by looking at the before and after locking modes instead of relying on the GLF_BLOCKING flag. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit b6900ce) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 6e417b3 When gdlm_ast() is called with a non-zero status code, this means that the requested operation did not succeed and the current lock state didn't change. Turn that into a non-zero LM_OUT_* status code (with ret & ~LM_OUT_ST_MASK != 0) instead of pretending that dlm returned the current lock state. That way, we can easily change finish_xmote() to only update gl->gl_state when the state has actually changed. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit 6e417b3) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit fd70ab7 The gl_req field and GLF_BLOCKING flag are only relevant to gdlm_lock(), its callback gdlm_ast(), and their helpers, so set and clear them inside lock_dlm.c. Also, the LM_FLAG_ANY flag is relevant to gdlm_lock(), but do_xmote() doesn't pass that flag down to gdlm_lock() as it should. Fix that by passing down all the flags. In addition, document the effect of the LM_FLAG_ANY flag on locks held in EX mode locally. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit fd70ab7) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 2b813a7 Commit 6802e34 ("[GFS2] Clean up the glock core") stopped passing the LM_FLAG_ANY flag down to gdlm_lock() (then gfs2_lm_lock()). Since then, gfs2 effectively hasn't been using dlm's DLM_LKF_ALTCW / DLM_LKF_ALTPR flags, but the code still suggests that it does. Recent testing shows that those flags don't even work reliably anymore, so instead of fixing code that hasn't been used since 2008, remove it. In addition, clean up how the flags are passed to [gd]lm_lock(). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit 2b813a7) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 0c23e24 The logic in add_to_queue() for determining whether a LM_FLAG_TRY or LM_FLAG_TRY_1CB holder should be queued does not make any sense: we are interested in wether or not the new operation will block behind an existing or future holder in the queue, but the current code checks for ongoing locking or ->go_inval() operations, which has little to do with that. Replace that code with something more sensible, remove the incorrect add_to_queue() function annotations, remove the similarly misguided do_error(gl, 0) call in do_xmote(), and add a missing comment to the same call in do_promote(). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit 0c23e24) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Colin Ian King <colin.i.king@gmail.com> commit aa94ad9 There is an extraneous space before a newline in a fs_err message. Remove it Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit aa94ad9) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 9b54770 In do_xmote(), remove the duplicate check for the ->go_sync and ->go_inval glock operations. They are either both defined, or none of them are. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit 9b54770) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 6df373b In gfs2_logd(), switch from an open-coded wait loop to wait_event_interruptible_timeout(). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 6df373b) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 0e10da6 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-4.18.0-553.176.1.el8_10/0e10da69.failed During a withdraw, we don't want to write out any more data than we have to, so in do_xmote(), skip the ->go_sync() glock operation. We still want to keep calling ->go_inval() to discard any cached data or metadata, whether clean or dirty. We do still allow glocks to transition into state LM_ST_UNLOCKED. This has the desired side effect of calling ->go_inval() and invalidating the glock caches. Function gfs2_withdraw_glocks() is already used for dequeuing any left-over waiters. We still want that to happen, but additionally, we want all glocks to be unlocked. Finally, we change function do_promote() to refuse any further promotions. This commit cleans up the leftovers of commit 8693419 ("gfs2: Clear flags when withdraw prevents xmote"). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 0e10da6) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/glock.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit bbbf152 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-4.18.0-553.176.1.el8_10/bbbf1529.failed Currently, when a gfs2 filesystem is withdrawn, an "offline" uevent is triggered that invokes gfs2-util's gfs2_withdraw_helper script. The purpose of this script is to deactivate the filesystem's block device so that it can be withdrawn immediately, even before all the filesystem's caches have been discarded. The script provided by gfs2-utils never did anything useful, and there was no way for it to report back its status to the kernel. To fix that, extend the gfs2_withdraw_helper mechanism so that the script can report one of the following results by writing the corresponding value into "/sys$DEVPATH/lock_module/withdraw": 0 - The shared block device has been marked inactive. Future write operations will fail. 1 - The shared block device may still be active and carry out write operations. If the "offline" uevent isn't reacted upon within the timeout configured in /sys$DEVPATH/tune/withdraw_helper_timeout (default 5 seconds), the event handler is assumed to have failed. In addition, add an additional "errors=deactivate" mount option. With these changes, if fatal errors are detected on a gfs2 filesystem and the filesystem is mounted with the "errors=panic" option, the kernel will panic immediately. Otherwise, an attempt will be made to deactivate the underlying block device. If successful, the kernel will release all cluster-wide locks immediately so that the rest of the cluster can continue. If unsuccessful, the kernel will either panic ("errors=deactivate"), or it will purge all filesystem I/O before releasing all cluster-wide locks ("errors=withdraw"). Note that the gfs2_withdraw_helper script still needs to be fixed to take advantage of these improvements. It could be changed to use a mechanism like LVM Persistent Reservations. "dmsetup suspend" is not a suitable mechanism as it infinitely postpones I/O operations, which may prevent withdraw from completing. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit bbbf152) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/util.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 3a88edc 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-4.18.0-553.176.1.el8_10/3a88edc1.failed We can now withdraw while the log is locked. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 3a88edc) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/trans.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 5a7a964 This minor cleanup to gfs2_freeze_super() and gfs2_thaw_super() prepares for the following refcounting fix. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 5a7a964) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 4e58543 It turns out that the .freeze_super and .thaw_super operations require the filesystem to manage the superblock refcount itself. We are using the freeze_super() and thaw_super() helpers to mostly take care of that for us, but this means that the superblock may no longer be around by when thaw_super() returns, and gfs2_thaw_super() will then access freed memory. Take an extra superblock reference in gfs2_thaw_super() to fix that. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 4e58543) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit fcd6308 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-4.18.0-553.176.1.el8_10/fcd63086.failed Function gfs2_freeze_unlock() is always called with &sdp->sd_freeze_gh as its argument, so clean up the code by passing in sdp instead. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit fcd6308) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/ops_fstype.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 16c3197 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-4.18.0-553.176.1.el8_10/16c31979.failed Previously, when a withdraw occurred, we would wait for another node to recover our journal. This also meant that frozen filesystem needed to be thawed because otherwise, other nodes wouldn't be able to recover the filesystem. With the reversal of commit 601ef0d ("gfs2: Force withdraw to replay journals and wait for it to finish"), we are no longer waiting for journal recovery during a withdraw, so we no longer need to thaw frozen filesystems, either. This also fixes a potential deadlock reported by lockdep when running xfstest generic/108. In addition, there is nothing left in do_withdraw() that would require taking sd_freeze_mutex, so don't bother taking that lock there anymore. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 16c3197) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/super.c # fs/gfs2/util.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 8334890 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-4.18.0-553.176.1.el8_10/83348905.failed Change do_withdraw() to clear the SDF_JOURNAL_LIVE flag under the log flush lock. In addition, change __gfs2_trans_begin() to check if the filesystem is already known to be withdrawn using gfs2_withdrawn(). Then, once we are holding the log flush lock, check if the SDF_JOURNAL_LIVE flag is still set. This second check ensures that the filesystem will remain live until the transaction is submitted. With these changes, it is no longer useful to clear SDF_JOURNAL_LIVE in gfs2_end_log_write() after calling gfs2_withdraw(). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 8334890) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/lops.c # fs/gfs2/util.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 5c0dc37 Rename the "gfs_recovery" workqueue to "gfs2_recovery", and gfs_recovery_wq to gfs2_recovery_wq. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 5c0dc37) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit b74cd55 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-4.18.0-553.176.1.el8_10/b74cd55a.failed First, function gfs2_ail_flush_reqd checks the SDF_FORCE_AIL_FLUSH flag to determine if an AIL flush should be forced in low-memory situations. However, it also immediately clears the flag, and when called repeatedly as in function gfs2_logd, the flag will be lost. Fix that by pulling the SDF_FORCE_AIL_FLUSH flag check out of gfs2_ail_flush_reqd. Second, function gfs2_writepages sets the SDF_FORCE_AIL_FLUSH flag whether or not enough pages were written. If enough pages could be written, flushing the AIL is unnecessary, though. Third, gfs2_writepages doesn't wake up logd after setting the SDF_FORCE_AIL_FLUSH flag, so it can take a long time for logd to react. It would be preferable to wake up logd, but that hurts the performance of some workloads and we don't quite understand why so far, so don't wake up logd so far. Fixes: b066a4e ("gfs2: forcibly flush ail to relieve memory pressure") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit b74cd55) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/log.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 7288185 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-4.18.0-553.176.1.el8_10/7288185c.failed It turns out that for some workloads, the fix in commit b74cd55 ("gfs2: low-memory forced flush fixes") causes the number of forced log flushes to increase to a degree that the overall filesystem performance drops significantly. Address that by forcing a log flush only when gfs2_writepages cannot make any progress rather than when it cannot make "enough" progress. Fixes: b74cd55 ("gfs2: low-memory forced flush fixes") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 7288185) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/aops.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Kevin Hao <haokexin@gmail.com> commit edd1327 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-4.18.0-553.176.1.el8_10/edd13270.failed A freezable kernel thread can enter frozen state during freezing by either calling try_to_freeze() or using wait_event_freezable() and its variants. So for the following snippet of code in a kernel thread loop: try_to_freeze(); wait_event_interruptible_timeout(); We can change it to a simple wait_event_freezable_timeout() and then eliminate a function call. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit edd1327) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/log.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit dff1fb6 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-4.18.0-553.176.1.el8_10/dff1fb6d.failed Commit e4a8b54 ("gfs2: Switch to wait_event in gfs2_quotad") broke cyclic statfs syncing, so the numbers reported by "df" could easily get completely out of sync with reality. Fix this by reverting part of commit e4a8b54 for now. A follow-up commit will clean this code up later. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit dff1fb6) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/quota.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Alexander Aring <aahringo@redhat.com> commit ff22e5d 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-4.18.0-553.176.1.el8_10/ff22e5da.failed Currently, gfs2 always sets the DLM_LKF_VALBLK flag to enable lvb handling even when sb_lvbptr is NULL. This currently causes no problems because DLM ignores the DLM_LKF_VALBLK flag when sb_lvbptr is NULL, but it does violate the DLM API. Fix that by only setting DLM_LKF_VALBLK when sb_lvbptr is not NULL. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit ff22e5d) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/lock_dlm.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 47faf93 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-4.18.0-553.176.1.el8_10/47faf937.failed Provide a better description of why the GLF_DEMOTE_IN_PROGRESS flag cannot be set. Function do_xmote() may block, so make sure it isn't called when nonblock is true. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit 47faf93) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/glock.c
jira KERNEL-1773 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit e7ffc0a As a minor clean-up to commit 1fc05c8 ("gfs2: cancel timed-out glock requests"), when a demote request is in progress in finish_xmote(), there is no point in waking up the glock holder at the head of the queue because the reply from dlm cannot be on behalf of that glock holder. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Reviewed-by: Andrew Price <anprice@redhat.com> (cherry picked from commit e7ffc0a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 cve CVE-2026-53196 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Adrian Korwel <adriank20047@gmail.com> commit 183c107 get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). Fixes: 1da177e ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Adrian Korwel <adriank20047@gmail.com> [ johan: amend commit message; also check for short descriptors ] Signed-off-by: Johan Hovold <johan@kernel.org> (cherry picked from commit 183c107) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 cve CVE-2026-53195 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Adrian Korwel <adriank20047@gmail.com> commit 0fd2b00 build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space. Fixes: 1da177e ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Adrian Korwel <adriank20047@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> (cherry picked from commit 0fd2b00) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1773 cve CVE-2026-93817 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Peter Zijlstra <peterz@infradead.org> commit e62d419 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-4.18.0-553.176.1.el8_10/e62d4192.failed Lee Jia Jie reported that since event::addr_filter_ranges is used under RCU, it should be RCU freed. Reported-by: Lee Jia Jie <jiajie.lee@starlabs.sg> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> (cherry picked from commit e62d419) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # kernel/events/core.c
jira KERNEL-1773 cve CVE-2026-98320 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit e75a9fa nf_ct_put() releases the ct->ext area inmediately, the rcu typesafe semantics also allow to refer to the wrong conntrack from the flowtable datapath. Hold reference on ct until flow is released after rcu grace period. Add rcu_barrier() on module exit path, to ensure pending flow entries are release before module goes away. Fixes: 0ff90b6 ("netfilter: nf_flow_offload: fix use-after-free and a resource leak") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit e75a9fa) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…mall jira KERNEL-1773 cve CVE-2026-89631 Rebuild_History Non-Buildable kernel-4.18.0-553.176.1.el8_10 commit-author Bryam Vargas <hexlabsecurity@proton.me> commit 65deb18 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-4.18.0-553.176.1.el8_10/65deb183.failed CIFSTCon() bounds its strnlen() over the byte area with the server's ByteCount minus two, which for ByteCount 0 or 1 goes negative as an int and converts to a huge size_t. The later subtraction wraps the __u16 bytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of up to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the slab object, and the bytes reach userspace through tcon->nativeFileSystem in /proc/fs/cifs/DebugData. Reject a byte area too small for what the parser consumes. Two bytes is the least it can consume, and no conformant response carries fewer. The new trace point is the 129th smb_eio_trace entry, which __mode(byte) cannot represent, so the attribute goes with it. Fixes: cc20c03 ("cifs: convert CIFSTCon to use new unicode helper functions") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Reviewed-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Paulo Alcantara <pc@manguebit.org> (cherry picked from commit 65deb18) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/cifs/cifssmb.c # fs/smb/client/trace.h
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v4.18~1..kernel-mainline: 661515 Number of commits in rpm: 87 Number of commits matched with upstream: 79 (90.80%) Number of commits in upstream but not in rpm: 661436 Number of commits NOT found in upstream: 8 (9.20%) Rebuilding Kernel on Branch rocky8_10_rebuild_kernel-4.18.0-553.176.1.el8_10 for kernel-4.18.0-553.176.1.el8_10 Clean Cherry Picks: 37 (46.84%) Empty Cherry Picks: 41 (51.90%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-4.18.0-553.176.1.el8_10/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
3 participants
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:4.18.0-553)git cherry-pickrpmbuild -bpfor the correspondingsrc.rpmJIRA Tickets
Rebuild Splat Inspection
kernel-4.18.0-553.176.1.el8_10
BUILD
KSelfTests