Conversation
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit fa58cc8 When a direct I/O write is performed, iomap_dio_rw() invalidates the part of the page cache which the write is going to before carrying out the write. In the odd case, the direct I/O write will be reading from the same page it is writing to. gfs2 carries out writes with page faults disabled, so it should have been obvious that this page invalidation can cause iomap_dio_rw() to never make any progress. Currently, gfs2 will end up in an endless retry loop in gfs2_file_direct_write() instead, though. Break this endless loop by limiting the number of retries and falling back to buffered I/O after that. Also simplify should_fault_in_pages() sightly and add a comment to make the above case easier to understand. Reported-by: Jan Kara <jack@suse.cz> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit fa58cc8) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit e411d74 In gfs2_fiemap(), we are calling iomap_fiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault. Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary. Fixes xfstest generic/742. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit e411d74) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 8d56716 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.47.1.el9_8/8d567162.failed If the GLF_INSTANTIATE_NEEDED flag isn't set, gfs2_instantiate() is a no-op. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 8d56716) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/super.c
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Bob Peterson <rpeterso@redhat.com> commit f9da18c This patch changes function evict_unlinked_inode so it does not call gfs2_inode_remember_delete until it gets a good return code from gfs2_dinode_dealloc. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit f9da18c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 2ff7cf7 As Neil Brown describes in detail in the link referenced below, new inodes must be unlocked before they can be instantiated. An even better fix is to use d_instantiate_new(), which combines d_instantiate() and unlock_new_inode(). Fixes: 3d36e57 ("gfs2: gfs2_create_inode rework") Reported-by: syzbot+0ea5108a1f5fb4fcc2d8@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-fsdevel/177153754005.8396.8777398743501764194@noble.neil.brown.name/ Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 2ff7cf7) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 0ac82bc We are no longer using LM_FLAG_TRY or LM_FLAG_TRY_1CB during inode evict, so ret cannot be GLR_TRYFAILED here. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 0ac82bc) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit e2de651 In evict_linked_inode(), the truncate_inode_pages() calls are carried out inside a transaction. This code was added to what was then function gfs2_delete_inode() in commit 16615be ("[GFS2] Clean up journaled data writing"). These transactions are only used for creating revokes for the jdata buffers in the journal, so don't create such transactions when we know that the address space doesn't contain any jdata buffers for this inode and truncate the metadata address space outside of the transaction. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit e2de651) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 2b34a9e Add gl helper variables in evict_unlinked_inode() and evict_linked_inode(). This patch isn't very interesting by itself, but it makes the next patch more readable. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 2b34a9e) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit bd67f17 When gfs2_evict_inode() is called on an inode with unwritten data in the page cache, the page cache needs to be written before it can be truncated. This doesn't always happen. Fix that by changing gfs2_evict_inode() to always either call evict_linked_inode() or evict_unlinked_inode(). Inside evict_unlinked_inode(), first check if the inode is dirty. If it is, make sure the inode glock is held and write back the data and metadata. If it isn't, skip those steps. Also, make sure that gfs2_evict_inode() calls gfs2_evict_inode() and evict_unlinked_inode() only if ip->i_gl is not NULL; this avoids unnecessary complications there. Fixes xfstest generic/211. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit bd67f17) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-31692 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Kuniyuki Iwashima <kuniyu@amazon.com> commit 28690e5 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.47.1.el9_8/28690e53.failed In ops->newlink(), veth, vxcan, and netkit call rtnl_link_get_net() with a net pointer, which is the first argument of ->newlink(). rtnl_link_get_net() could return another netns based on IFLA_NET_NS_PID and IFLA_NET_NS_FD in the peer device's attributes. We want to get it and fill rtnl_nets->nets[] in advance in rtnl_newlink() for per-netns RTNL. All of the three get the peer netns in the same way: 1. Call rtnl_nla_parse_ifinfomsg() 2. Call ops->validate() (vxcan doesn't have) 3. Call rtnl_link_get_net_tb() Let's add a new field peer_type to struct rtnl_link_ops and prefetch netns in the peer ifla to add it to rtnl_nets in rtnl_newlink(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20241108004823.29419-6-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 28690e5) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/core/rtnetlink.c
jira KERNEL-1590 cve CVE-2026-31692 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Kuniyuki Iwashima <kuniyu@amazon.com> commit 0eb87b0 For per-netns RTNL, we need to prefetch the peer device's netns. Let's set rtnl_link_ops.peer_type and accordingly remove duplicated validation in ->newlink(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20241108004823.29419-7-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 0eb87b0) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-31692 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Kuniyuki Iwashima <kuniyu@amazon.com> commit 6b84e55 For per-netns RTNL, we need to prefetch the peer device's netns. Let's set rtnl_link_ops.peer_type and accordingly remove duplicated validation in ->newlink(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20241108004823.29419-8-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 6b84e55) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-31692 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Cong Wang <cong.wang@bytedance.com> commit 4832756 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.47.1.el9_8/48327566.failed Currently rtnl_link_get_net_ifla() gets called twice when we create peer devices, once in rtnl_add_peer_net() and once in each ->newlink() implementation. This looks safer, however, it leads to a classic Time-of-Check to Time-of-Use (TOCTOU) bug since IFLA_NET_NS_PID is very dynamic. And because of the lack of checking error pointer of the second call, it also leads to a kernel crash as reported by syzbot. Fix this by getting rid of the second call, which already becomes redudant after Kuniyuki's work. We have to propagate the result of the first rtnl_link_get_net_ifla() down to each ->newlink(). Reported-by: syzbot+21ba4d5adff0b6a7cfc6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=21ba4d5adff0b6a7cfc6 Fixes: 0eb87b0 ("veth: Set VETH_INFO_PEER to veth_link_ops.peer_type.") Fixes: 6b84e55 ("vxcan: Set VXCAN_INFO_PEER to vxcan_link_ops.peer_type.") Fixes: fefd5d0 ("netkit: Set IFLA_NETKIT_PEER_INFO to netkit_link_ops.peer_type.") Cc: Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: Cong Wang <cong.wang@bytedance.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20241129212519.825567-1-xiyou.wangcong@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 4832756) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # drivers/net/netkit.c # net/core/rtnetlink.c
jira KERNEL-1590 cve CVE-2026-31692 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Kuniyuki Iwashima <kuniyu@amazon.com> commit 954a2b4 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.47.1.el9_8/954a2b40.failed Xiao Liang reported that the cited commit changed netns handling in newlink() of netkit, veth, and vxcan. Before the patch, if we don't find a netns attribute in the peer device attributes, we tried to find another netns attribute in the outer netlink attributes by passing it to rtnl_link_get_net(). Let's restore the original behaviour. Fixes: 4832756 ("rtnetlink: fix double call of rtnl_link_get_net_ifla()") Reported-by: Xiao Liang <shaw.leon@gmail.com> Closes: https://lore.kernel.org/netdev/CABAhCORBVVU8P6AHcEkENMj+gD2d3ce9t=A_o48E0yOQp8_wUQ@mail.gmail.com/#t Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Tested-by: Xiao Liang <shaw.leon@gmail.com> Link: https://patch.msgid.link/20241216110432.51488-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 954a2b4) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/core/rtnetlink.c
jira KERNEL-1590 cve CVE-2026-31692 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Nikolaos Gkarlis <nickgarlis@gmail.com> commit 7b735ef 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.47.1.el9_8/7b735ef8.failed rtnl_newlink() lacks a CAP_NET_ADMIN capability check on the peer network namespace when creating paired devices (veth, vxcan, netkit). This allows an unprivileged user with a user namespace to create interfaces in arbitrary network namespaces, including init_net. Add a netlink_ns_capable() check for CAP_NET_ADMIN in the peer namespace before allowing device creation to proceed. Fixes: 81adee4 ("net: Support specifying the network namespace upon device creation.") Signed-off-by: Nikolaos Gkarlis <nickgarlis@gmail.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260402181432.4126920-1-nickgarlis@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 7b735ef) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/core/rtnetlink.c
jira KERNEL-1590 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Crystal Wood <crwood@redhat.com> commit 3138df6 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.47.1.el9_8/3138df6f.failed Comparing to exactly 1 will fail if more than one ring buffer event was seen since the last call to timerlat_bpf_wait(), which can happen in some race scenarios. Signed-off-by: Crystal Wood <crwood@redhat.com> Link: https://lore.kernel.org/r/20251112152529.956778-5-crwood@redhat.com Signed-off-by: Tomas Glozar <tglozar@redhat.com> (cherry picked from commit 3138df6) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # tools/tracing/rtla/src/timerlat_top.c
jira KERNEL-1590 cve CVE-2026-53091 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Fengyuan Gong <gfengyuan@google.com> commit a41851b Refine qdisc_pkt_len_init to include headers up through the inner transport header when computing header size for encapsulations. Also refine net/sched/sch_cake.c borrowed from qdisc_pkt_len_init(). Signed-off-by: Fengyuan Gong <gfengyuan@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://patch.msgid.link/20250702160741.1204919-1-gfengyuan@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit a41851b) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-53091 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Eric Dumazet <edumazet@google.com> commit b2a38f6 Add a new u16 field, next to pkt_len : pkt_segs This will cache shinfo->gso_segs to speed up qdisc deqeue(). Move slave_dev_queue_mapping at the end of qdisc_skb_cb, and move three bits from tc_skb_cb : - post_ct - post_ct_snat - post_ct_dnat Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20251121083256.674562-2-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit b2a38f6) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-53091 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Eric Dumazet <edumazet@google.com> commit be1b70a Qdisc use shinfo->gso_segs for their pkts stats in bstats_update(), but this field needs to be initialized for SKB_GSO_DODGY users. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20251121083256.674562-3-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit be1b70a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…it() jira KERNEL-1590 cve CVE-2026-53091 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Eric Dumazet <edumazet@google.com> commit 874c192 qdisc_pkt_len_init() is currently initalizing qdisc_skb_cb(skb)->pkt_len. Add qdisc_skb_cb(skb)->pkt_segs initialization and rename this function to qdisc_pkt_len_segs_init(). Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20251121083256.674562-4-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 874c192) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-53091 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Eric Dumazet <edumazet@google.com> commit 30e02ec Reduce indentation level by returning early if the transport header was not set. Add an unlikely() clause as this is not the common case. No functional change. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260403221540.3297753-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 30e02ec) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-53091 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Eric Dumazet <edumazet@google.com> commit 7fb4c19 Most ndo_start_xmit() methods expects headers of gso packets to be already in skb->head. net/core/tso.c users are particularly at risk, because tso_build_hdr() does a memcpy(hdr, skb->data, hdr_len); qdisc_pkt_len_segs_init() already does a dissection of gso packets. Use pskb_may_pull() instead of skb_header_pointer() to make sure drivers do not have to reimplement this. Some malicious packets could be fed, detect them so that we can drop them sooner with a new SKB_DROP_REASON_SKB_BAD_GSO drop_reason. Fixes: e876f20 ("net: Add a software TSO helper API") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260403221540.3297753-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 7fb4c19) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-53091 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Cosmin Ratiu <cratiu@nvidia.com> commit fa90a31 On VXLAN over IPsec egress, xfrm{4,6}_transport_output() blindly overwrite inner_transport_header (== the inner TCP header saved in VXLAN iptunnel_handle_offloads() -> skb_reset_inner_headers()) with the current transport_header (== the VXLAN outer UDP header set by udp_tunnel_xmit_skb()). This was a latent bug, harmless until commit [1] added a doff validation check in qdisc_pkt_len_segs_init() for encapsulated GSO packets. With the wrong inner_transport_header set by xfrm, qdisc_pkt_len_segs_init() interprets inner_transport_header as a TCP header, reads doff=0 from the upper byte of the VNI and drops the packet with DROP_REASON_SKB_BAD_GSO. Besides the use in GSO to determine the header size of segmented packets, inner_transport_header might be used by drivers to set up inner checksum offloading by pointing the HW to the inner transport header. A quick browse through available drivers shows that mlx5 uses skb->csum_start specifically for this scenario, while others either don't support VXLAN over IPsec crypto offload (ixgbe) or the HW is capable of parsing the packets itself (nfp, Chelsio). But in all cases, it is more correct to let the inner_transport_header point to the innermost header instead of overwriting it in xfrm. So fix this by guarding all four inner header save sites in xfrm_output.c (xfrm{4,6}_transport_output, xfrm{4,6}_tunnel_encap_add) with a check for skb->inner_protocol. When inner_protocol is set, a tunnel layer (VXLAN, Geneve, GRE, etc.) has already saved the correct inner header offsets and they must not be overwritten. When inner_protocol is zero, no prior tunnel encapsulation exists and xfrm must save the inner headers itself. The tunnel mode checks are only added for completion, since they aren't strictly required, as xfrm_output() forces software GSO in tunnel mode before encap. This makes the previously added test pass: # ./tools/testing/selftests/drivers/net/hw/ipsec_vxlan.py TAP version 13 1..4 ok 1 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v4_inner_v4 ok 2 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v4_inner_v6 ok 3 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v6_inner_v4 ok 4 ipsec_vxlan.test_vxlan_ipsec_crypto_offload.outer_v6_inner_v6 # Totals: pass:4 fail:0 xfail:0 xpass:0 skip:0 error:0 [1] commit 7fb4c19 ("net: pull headers in qdisc_pkt_len_segs_init()") Fixes: f1bd7d6 ("xfrm: Add encapsulation header offsets while SKB is not encrypted") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit fa90a31) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-52918 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Jiexun Wang <wangjiexun2025@gmail.com> commit e83f5e2 bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket. Fixes: 1da177e ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Jann Horn <jannh@google.com> Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com> Reviewed-by: Jann Horn <jannh@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> (cherry picked from commit e83f5e2) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-53256 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Zhang Cen <rollkingzzc@gmail.com> commit 43c441e rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release(). Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: Zhang Cen <rollkingzzc@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> (cherry picked from commit 43c441e) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-53254 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author SeungJu Cheon <suunj1331@gmail.com> commit 23882b8 The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1. Fixes: 1da177e ("Linux-2.6.12-rc2") Suggested-by: Muhammad Bilal <meatuni001@gmail.com> Signed-off-by: SeungJu Cheon <suunj1331@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> (cherry picked from commit 23882b8) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-63945 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Muhammad Bilal <meatuni001@gmail.com> commit 4b5f8e6 iso_sock_close() calls iso_sock_clear_timer() before acquiring lock_sock(sk). iso_sock_clear_timer() reads iso_pi(sk)->conn twice without the socket lock held: if (!iso_pi(sk)->conn) return; cancel_delayed_work(&iso_pi(sk)->conn->timeout_work); Concurrently, iso_conn_del() executes under lock_sock(sk) and calls iso_chan_del(), which sets iso_pi(sk)->conn to NULL and may result in the final reference to the connection being dropped: CPU0 CPU1 ---- ---- iso_sock_clear_timer() if (conn != NULL) ... lock_sock(sk) iso_chan_del() iso_pi(sk)->conn = NULL cancel_delayed_work(conn) /* NULL deref or UAF */ iso_pi(sk)->conn is not stable across the unlock window, causing a NULL pointer dereference or use-after-free. Serialize iso_sock_clear_timer() with the socket lock by moving it inside lock_sock()/release_sock(), matching the pattern used in iso_conn_del() and all other call sites. Fixes: ccf74f2 ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal <meatuni001@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> (cherry picked from commit 4b5f8e6) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-53053 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Vasant Hegde <vasant.hegde@amd.com> commit faad224 Currently clone_alias() assumes first argument (pdev) is always the original device pointer. This function is called by pci_for_each_dma_alias() which based on topology decides to send original or alias device details in first argument. This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device. Fix this by passing the original pdev as the opaque data argument to both the direct clone_alias() call and pci_for_each_dma_alias(). Inside clone_alias(), retrieve the original device from data and compute devid from it. Fixes: 3332364 ("iommu/amd: Support multiple PCI DMA aliases in device table") Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> (cherry picked from commit faad224) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
… pairing response jira KERNEL-1590 cve CVE-2026-43334 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Oleh Konko <security@1seal.org> commit d05111b smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned. Fixes: 2b64d15 ("Bluetooth: Add MITM mechanism to LE-SMP") Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Signed-off-by: Oleh Konko <security@1seal.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> (cherry picked from commit d05111b) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1590 cve CVE-2026-64113 Rebuild_History Non-Buildable kernel-5.14.0-687.47.1.el9_8 commit-author Michael Bommarito <michael.bommarito@gmail.com> commit 5d49b56 ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor: dev_kfree_skb_irq(skb); continue; The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context. The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here. I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags): BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90) QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible. Fixes: bad1723 ("ixgbevf: Change receive model to use double buffered page based receives") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-8-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 5d49b56) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…nish" (6/6) jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit dcc42d5 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.49.1.el9_8/dcc42d55.failed The current withdraw code duplicates the journal recovery code gfs2 already has for dealing with node failures, and it does so poorly. That code was added because when releasing a lockspace, we didn't have a way to indicate that the lockspace needs recovery. We now do have this feature, so the current withdraw code can be removed almost entirely. This is one of several steps towards that. Reverts parts of commit 601ef0d ("gfs2: Force withdraw to replay journals and wait for it to finish"). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit dcc42d5) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/util.c
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 6bb7c1b 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.49.1.el9_8/6bb7c1bf.failed The current withdraw code duplicates the journal recovery code gfs2 already has for dealing with node failures, and it does so poorly. That code was added because when releasing a lockspace, we didn't have a way to indicate that the lockspace needs recovery. We now do have this feature, so the current withdraw code can be removed almost entirely. This is one of several steps towards that. Reverts commit 865cc3e ("gfs2: fix a deadlock on withdraw-during-mount"). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 6bb7c1b) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/glock.c
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 41ad1f7 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.49.1.el9_8/41ad1f7c.failed The current withdraw code duplicates the journal recovery code gfs2 already has for dealing with node failures, and it does so poorly. That code was added because when releasing a lockspace, we didn't have a way to indicate that the lockspace needs recovery. We now do have this feature, so the current withdraw code can be removed almost entirely. This is one of several steps towards that. Reverts the rest of d93ae38 ("gfs2: Check for log write errors before telling dlm to unlock"). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 41ad1f7) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/glock.c
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit af572ef 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.49.1.el9_8/af572efe.failed The current withdraw code duplicates the journal recovery code gfs2 already has for dealing with node failures, and it does so poorly. That code was added because when releasing a lockspace, we didn't have a way to indicate that the lockspace needs recovery. We now do have this feature, so the current withdraw code can be removed almost entirely. This is one of several steps towards that. Reverts commit a72d240 ("gfs2: Allow some glocks to be used during withdraw"). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit af572ef) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/glock.c # fs/gfs2/glops.c
…o_inval" jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 655531c 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.49.1.el9_8/655531c9.failed The current withdraw code duplicates the journal recovery code gfs2 already has for dealing with node failures, and it does so poorly. That code was added because when releasing a lockspace, we didn't have a way to indicate that the lockspace needs recovery. We now do have this feature, so the current withdraw code can be removed almost entirely. This is one of several steps towards that. Reverts commit 33dbd1e ("gfs2: fix infinite loop when checking ail item count before go_inval"). Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 655531c) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/glock.c
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 473678c Rename function gfs2_gl_dq_holders() to gfs2_withdraw_glocks(). This function will soon be used for more than just dequeuing holders. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 473678c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 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-5.14.0-687.49.1.el9_8/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-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 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-5.14.0-687.49.1.el9_8/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-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 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-5.14.0-687.49.1.el9_8/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-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 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-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 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-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit fcd6308 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>
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 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-5.14.0-687.49.1.el9_8/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/util.c
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 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-5.14.0-687.49.1.el9_8/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-1613 cve CVE-2026-68159 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andy Shevchenko <andriy.shevchenko@linux.intel.com> commit 04d8712 In a few cases the code compares 32-bit value to a SIZE_MAX derived constant which is much higher than that value on 64-bit platforms, Clang, in particular, is not happy about this net/ceph/osdmap.c:1441:10: error: result of comparison of constant 4611686018427387891 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 1441 | if (len > (SIZE_MAX - sizeof(*pg)) / sizeof(u32)) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/ceph/osdmap.c:1624:10: error: result of comparison of constant 2305843009213693945 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 1624 | if (len > (SIZE_MAX - sizeof(*pg)) / (2 * sizeof(u32))) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by casting to size_t. Note, that possible replacement of SIZE_MAX by U32_MAX may lead to the behaviour changes on the corner cases. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> (cherry picked from commit 04d8712) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit f75efef The logic for determining when to demote a glock in glock_work_func(), introduced in commit 7cf8dcd ("GFS2: Automatically adjust glock min hold time"), doesn't make sense: inode glocks have a minimum hold time that delays demotion, while all other glocks are expected to be demoted immediately. Instead of demoting non-inode glocks immediately, glock_work_func() schedules glock work for them to be demoted, however. Get rid of that unnecessary indirection. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit f75efef) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 4117efd In gfs2_glock_cb(), we only need to calculate the glock hold time for inode glocks; the value is unused otherwise. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 4117efd) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1613 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 0ec49e7 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.49.1.el9_8/0ec49e7e.failed Introduce glock_type(), glock_number(), and glock_sbd() helpers for accessing a glock's type, number, and super block pointer more easily. Created with Coccinelle using the following semantic patch: @@ struct gfs2_glock *gl; @@ - gl->gl_name.ln_type + glock_type(gl) @@ struct gfs2_glock *gl; @@ - gl->gl_name.ln_number + glock_number(gl) @@ struct gfs2_glock *gl; @@ - gl->gl_name.ln_sbd + glock_sbd(gl) glock_sbd() is a macro because it is used with const as well as non-const struct gfs2_glock * arguments. Instances in macro definitions, particularly in tracepoint definitions, replaced by hand. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 0ec49e7) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/gfs2/glock.c # fs/gfs2/glops.c # fs/gfs2/meta_io.c
jira KERNEL-1613 cve CVE-2026-23172 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Kery Qi <qikeyu2017@gmail.com> commit f0813bc When receiving data in the DPMAIF RX path, the t7xx_dpmaif_set_frag_to_skb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow in skb_shinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior. This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c ("mt76: fix array overflow on receiving too many fragments for a packet"). The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects. Fix this by adding a bounds check before calling skb_add_rx_frag() to ensure nr_frags does not exceed MAX_SKB_FRAGS. The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown. Fixes: d642b01 ("net: wwan: t7xx: Add data path interface") Signed-off-by: Kery Qi <qikeyu2017@gmail.com> Link: https://patch.msgid.link/20260122170401.1986-2-qikeyu2017@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit f0813bc) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1613 cve CVE-2026-64176 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Johannes Berg <johannes.berg@intel.com> commit fb84b5c On old devices such as 7265D, rates are still encoded in version 1 format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.) While introducing v3 rates, I changed the driver from internally handling v1 rates and converting to v2, to internally handling v3 and converting to v1 or v2 according to the firmware. I accordingly changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer have different values for different APIs. This was correct. However, I later reverted this part of the change, because it was reported that I had broken beacon rates, causing a FW assert/crash. This caused TX_CMD rates to be set incorrectly, potentially causing a warning when reported back from the device as having been used. Fix this (hopefully correctly now) by handling beacon rates in the TX_CMD that's embedded in the beacon template command separately. Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate index, not PLCP value, fixing the real TX_CMD. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260515151351.7407e293dff7.I4ea1a17f8fe99c933d3f3e30d077cf4246125c3e@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> (cherry picked from commit fb84b5c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1613 cve CVE-2026-64175 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Sheroz Juraev <goodmartiandev@gmail.com> commit 2becb38 When iwlwifi firmware crashes (e.g., NMI_INTERRUPT_UNKNOWN on Intel BE201/Wi-Fi 7), iwl_mld_nic_error() sets mld->fw_status.in_hw_restart to true. However, iwl_mld_tx_from_txq() does not check this flag before dequeuing frames from mac80211 and pushing them to the transport layer. Since the firmware is dead, iwl_trans_tx() returns -EIO for each frame, which then gets freed immediately. Under high-throughput conditions (e.g., Tailscale UDP traffic or active SSH sessions), this creates a tight dequeue-send-fail-free loop that wastes CPU cycles and generates rapid skb allocation churn, leading to memory pressure from slab fragmentation. The RX path already has this guard (iwl_mld_rx_mpdu checks in_hw_restart at rx.c:1906), and so does the TXQ allocation worker (iwl_mld_add_txqs_wk at tx.c:156). Add the same guard to iwl_mld_tx_from_txq() to stop all TX during firmware restart. Frames left in mac80211's TXQs are naturally drained after restart completes, when queue reallocation triggers iwl_mld_tx_from_txq() via iwl_mld_add_txq_list(), or when new upper-layer traffic invokes wake_tx_queue. Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on kernel 6.19.5 where the firmware crashes approximately every 10-15 minutes under Tailscale traffic. Fixes: d1e879e ("wifi: iwlwifi: add iwlmld sub-driver") Cc: stable@vger.kernel.org Signed-off-by: Sheroz Juraev <goodmartiandev@gmail.com> Link: https://patch.msgid.link/20260315081221.2678478-1-goodmartiandev@gmail.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> (cherry picked from commit 2becb38) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1613 cve CVE-2026-72298 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Michael Bommarito <michael.bommarito@gmail.com> commit 2005486 qrtr_endpoint_post() validates an incoming packet with if (!size || len != ALIGN(size, 4) + hdrlen) goto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c ("net: qrtr: fix OOB Read in qrtr_endpoint_post"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN. Fixes: ad9d24c ("net: qrtr: fix OOB Read in qrtr_endpoint_post") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260611125455.2352279-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 2005486) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1613 cve CVE-2026-64174 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author John Walker <johnwalker0@gmail.com> commit 7666dbb cfg80211_merge_profile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls cfg80211_get_profile_continuation(ie, ielen, mbssid_elem, sub_elem) but never advances mbssid_elem or sub_elem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same next_mbssid; and the same next_sub bytes are memcpy()'d into merged_ie at a growing offset until the buffer fills. Advance both mbssid_elem and sub_elem to the just-consumed continuation so the next call to cfg80211_get_profile_continuation() searches for a further continuation beyond it (or returns NULL when none exists). A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211_merge_profile (up to as much as 2ms per beacon received), which could theoretically be abused in some way. Cc: stable@vger.kernel.org Fixes: fe806e4 ("cfg80211: support profile split between elements") Signed-off-by: John Walker <johnwalker0@gmail.com> Link: https://patch.msgid.link/20260507230720.64783-1-johnwalker0@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 7666dbb) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…diotap jira KERNEL-1613 cve CVE-2026-63869 Rebuild_History Non-Buildable kernel-5.14.0-687.49.1.el9_8 commit-author Deepanshu Kartikey <kartikey406@gmail.com> commit 6c0cf89 When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: info->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds. Reported-by: syzbot+8e0622f6d9446420271f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8e0622f6d9446420271f Fixes: ef246a1 ("wifi: mac80211: support antenna control in injection") Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260531011721.102941-1-kartikey406@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 6c0cf89) 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: 394115 Number of commits in rpm: 80 Number of commits matched with upstream: 59 (73.75%) Number of commits in upstream but not in rpm: 394056 Number of commits NOT found in upstream: 21 (26.25%) Rebuilding Kernel on Branch rocky9_8_rebuild_kernel-5.14.0-687.49.1.el9_8 for kernel-5.14.0-687.49.1.el9_8 Clean Cherry Picks: 40 (67.80%) Empty Cherry Picks: 19 (32.20%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-5.14.0-687.49.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
PlaidCat
changed the title
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
2 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:5.14.0-687)git cherry-pickrpmbuild -bpfor the correspondingsrc.rpmJIRA Tickets
Rebuild Splat Inspection
kernel-5.14.0-687.47.1.el9_8
BUILD
KSelfTests