[rocky10_2] History Rebuild through kernel-6.12.0-211.18.1.el10_2#1285
Open
PlaidCat wants to merge 40 commits into
Open
[rocky10_2] History Rebuild through kernel-6.12.0-211.18.1.el10_2#1285PlaidCat wants to merge 40 commits into
PlaidCat wants to merge 40 commits into
Conversation
jira KERNEL-1088 cve CVE-2026-23392 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit d73f4b5 Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks. Fixes: 3b49e2e ("netfilter: nf_tables: add flow table netlink frontend") Reported-by: Yiming Qian <yimingqian591@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de> (cherry picked from commit d73f4b5) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2024-56645 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Dmitry Antipov <dmantipov@yandex.ru> commit a8c6950 Since j1939_session_skb_queue() does an extra skb_get() for each new skb, do the same for the initial one in j1939_session_new() to avoid refcount underflow. Reported-by: syzbot+d4e8dc385d9258220c31@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d4e8dc385d9258220c31 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20241105094823.2403806-1-dmantipov@yandex.ru [mkl: clean up commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> (cherry picked from commit a8c6950) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2025-68183 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Coiby Xu <coxu@redhat.com> commit 88b4cbc Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include <stdio.h> #include <sys/xattr.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdlib.h> int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; } Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> (cherry picked from commit 88b4cbc) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-23455 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Jenny Guanni Qu <qguanni@gmail.com> commit f173d0f In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement. Fixes: 5e35941 ("[NETFILTER]: Add H.323 conntrack/NAT helper") Reported-by: Klaudia Kloc <klaudia@vidocsecurity.com> Reported-by: Dawid Moczadło <dawid@vidocsecurity.com> Tested-by: Jenny Guanni Qu <qguanni@gmail.com> Signed-off-by: Jenny Guanni Qu <qguanni@gmail.com> Signed-off-by: Florian Westphal <fw@strlen.de> (cherry picked from commit f173d0f) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Jacob Keller <jacob.e.keller@intel.com> commit 0e0c8f4 The mgag200_bmc_stop_scanout() function is called by the .atomic_disable() handler for the MGA G200 VGA BMC encoder. This function performs a few register writes to inform the BMC of an upcoming mode change, and then polls to wait until the BMC actually stops. The polling is implemented using a busy loop with udelay() and an iteration timeout of 300, resulting in the function blocking for 300 milliseconds. The function gets called ultimately by the output_poll_execute work thread for the DRM output change polling thread of the mgag200 driver: kworker/0:0-mm_ 3528 [000] 4555.315364: ffffffffaa0e25b3 delay_halt.part.0+0x33 ffffffffc03f6188 mgag200_bmc_stop_scanout+0x178 ffffffffc087ae7a disable_outputs+0x12a ffffffffc087c12a drm_atomic_helper_commit_tail+0x1a ffffffffc03fa7b6 mgag200_mode_config_helper_atomic_commit_tail+0x26 ffffffffc087c9c1 commit_tail+0x91 ffffffffc087d51b drm_atomic_helper_commit+0x11b ffffffffc0509694 drm_atomic_commit+0xa4 ffffffffc05105e8 drm_client_modeset_commit_atomic+0x1e8 ffffffffc0510ce6 drm_client_modeset_commit_locked+0x56 ffffffffc0510e24 drm_client_modeset_commit+0x24 ffffffffc088a743 __drm_fb_helper_restore_fbdev_mode_unlocked+0x93 ffffffffc088a683 drm_fb_helper_hotplug_event+0xe3 ffffffffc050f8aa drm_client_dev_hotplug+0x9a ffffffffc088555a output_poll_execute+0x29a ffffffffa9b35924 process_one_work+0x194 ffffffffa9b364ee worker_thread+0x2fe ffffffffa9b3ecad kthread+0xdd ffffffffa9a08549 ret_from_fork+0x29 On a server running ptp4l with the mgag200 driver loaded, we found that ptp4l would sometimes get blocked from execution because of this busy waiting loop. Every so often, approximately once every 20 minutes -- though with large variance -- the output_poll_execute() thread would detect some sort of change that required performing a hotplug event which results in attempting to stop the BMC scanout, resulting in a 300msec delay on one CPU. On this system, ptp4l was pinned to a single CPU. When the output_poll_execute() thread ran on that CPU, it blocked ptp4l from executing for its 300 millisecond duration. This resulted in PTP service disruptions such as failure to send a SYNC message on time, failure to handle ANNOUNCE messages on time, and clock check warnings from the application. All of this despite the application being configured with FIFO_RT and a higher priority than the background workqueue tasks. (However, note that the kernel did not use CONFIG_PREEMPT...) It is unclear if the event is due to a faulty VGA connection, another bug, or actual events causing a change in the connection. At least on the system under test it is not a one-time event and consistently causes disruption to the time sensitive applications. The function has some helpful comments explaining what steps it is attempting to take. In particular, step 3a and 3b are explained as such: 3a - The third step is to verify if there is an active scan. We are waiting on a 0 on remhsyncsts (<XSPAREREG<0>. 3b - This step occurs only if the remove is actually scanning. We are waiting for the end of the frame which is a 1 on remvsyncsts (<XSPAREREG<1>). The actual steps 3a and 3b are implemented as while loops with a non-sleeping udelay(). The first step iterates while the tmp value at position 0 is *not* set. That is, it keeps iterating as long as the bit is zero. If the bit is already 0 (because there is no active scan), it will iterate the entire 300 attempts which wastes 300 milliseconds in total. This is opposite of what the description claims. The step 3b logic only executes if we do not iterate over the entire 300 attempts in the first loop. If it does trigger, it is trying to check and wait for a 1 on the remvsyncsts. However, again the condition is actually inverted and it will loop as long as the bit is 1, stopping once it hits zero (rather than the explained attempt to wait until we see a 1). Worse, both loops are implemented using non-sleeping waits which spin instead of allowing the scheduler to run other processes. If the kernel is not configured to allow arbitrary preemption, it will waste valuable CPU time doing nothing. There does not appear to be any documentation for the BMC register interface, beyond what is in the comments here. It seems more probable that the comment here is correct and the implementation accidentally got inverted from the intended logic. Reading through other DRM driver implementations, it does not appear that the .atomic_enable or .atomic_disable handlers need to delay instead of sleep. For example, the ast_astdp_encoder_helper_atomic_disable() function calls ast_dp_set_phy_sleep() which uses msleep(). The "atomic" in the name is referring to the atomic modesetting support, which is the support to enable atomic configuration from userspace, and not to the "atomic context" of the kernel. There is no reason to use udelay() here if a sleep would be sufficient. Replace the while loops with a read_poll_timeout() based implementation that will sleep between iterations, and which stops polling once the condition is met (instead of looping as long as the condition is met). This aligns with the commented behavior and avoids blocking on the CPU while doing nothing. Note the RREG_DAC is implemented using a statement expression to allow working properly with the read_poll_timeout family of functions. The other RREG_<TYPE> macros ought to be cleaned up to have better semantics, and several places in the mgag200 driver could make use of RREG_DAC or similar RREG_* macros should likely be cleaned up for better semantics as well, but that task has been left as a future cleanup for a non-bugfix. Fixes: 414c453 ("mgag200: initial g200se driver (v2)") Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260202-jk-mgag200-fix-bad-udelay-v2-1-ce1e9665987d@intel.com (cherry picked from commit 0e0c8f4) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-31684 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Ruide Cao <caoruide123@gmail.com> commit c842743 tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path. Fixes: 2ecba2d ("net: sched: act_csum: Fix csum calc for tagged packets") Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Tested-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Ruide Cao <caoruide123@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/22df2fcb49f410203eafa5d97963dd36089f4ecf.1774892775.git.caoruide123@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit c842743) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-31685 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Zhengchuan Liang <zcliangcn@gmail.com> commit fdce0b3 `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`. Fixes: 1da177e ("Linux-2.6.12-rc2") Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Tested-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: Florian Westphal <fw@strlen.de> (cherry picked from commit fdce0b3) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Shyam Prasad N <sprasad@microsoft.com> commit a5a50f1 This code was recently changed from manually decrementing tcon ref to using cifs_put_tcon. But even before that change this tracing happened after decrementing the ref count, which is wrong. With cifs_put_tcon, tracing already happens inside it. So just removing the extra tracing here. Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com> (cherry picked from commit a5a50f1) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Shyam Prasad N <sprasad@microsoft.com> commit e3beefd When retrans mount option was introduced, the default value was set as 1. However, in the light of some bugs that this has exposed recently we should change it to 0 and retain the old behaviour before this option was introduced. Cc: <stable@vger.kernel.org> Reviewed-by: Bharath SM <bharathsm@microsoft.com> Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com> (cherry picked from commit e3beefd) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit 24e4336 Introduce zl3073x_dev_output_pin_freq_get() helper function to compute the output pin frequency based on synthesizer frequency, output divisor, and signal format. For N-div signal formats, the N-pin frequency is additionally divided by esync_n_period. Add zl3073x_out_is_ndiv() helper to check if an output is configured in N-div mode (2_NDIV or 2_NDIV_INV signal formats). Refactor zl3073x_dpll_output_pin_frequency_get() callback to use the new helper, reducing code duplication and enabling reuse of the frequency calculation logic in other contexts. This is a preparatory change for adding current frequency to the supported frequencies list in pin properties. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260205154350.3180465-2-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 24e4336) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit 85a9aaa Ensure the current pin frequency is always present in the list of supported frequencies reported to userspace. Previously, if the firmware node was missing or didn't include the current operating frequency in the supported-frequencies-hz property, the pin would report a frequency that wasn't in its supported list. Get the current frequency early in zl3073x_pin_props_get(): - For input pins: use zl3073x_dev_ref_freq_get() - For output pins: use zl3073x_dev_output_pin_freq_get() Place the current frequency at index 0 of the supported frequencies array, then append frequencies from the firmware node (if present), skipping any duplicate of the current frequency. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260205154350.3180465-3-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 85a9aaa) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit a047497 The frequency for an input reference is computed as: frequency = freq_base * freq_mult * freq_ratio_m / freq_ratio_n Before commit 5bc02b1 ("dpll: zl3073x: Cache all reference properties in zl3073x_ref"), zl3073x_dpll_input_pin_frequency_set() explicitly wrote 1 to both the REF_RATIO_M and REF_RATIO_N hardware registers whenever a new frequency was set. This ensured the FEC ratio was always reset to 1:1 alongside the new base/multiplier values. The refactoring in that commit introduced zl3073x_ref_freq_set() to update the cached ref state, but this helper only sets freq_base and freq_mult without resetting freq_ratio_m and freq_ratio_n to 1. Because zl3073x_ref_state_set() uses a compare-and-write strategy, unchanged ratio fields are never written to the hardware. If the device previously had non-unity FEC ratio values, they remain in effect after a frequency change, resulting in an incorrect computed frequency. Explicitly set freq_ratio_m and freq_ratio_n to 1 in zl3073x_ref_freq_set() to restore the original behavior. Fixes: 5bc02b1 ("dpll: zl3073x: Cache all reference properties in zl3073x_ref") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260216194007.680416-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit a047497) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
… IDs jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit 4cfe066 The REF_PHASE_OFFSET_COMP register is 48-bit wide on most zl3073x chip variants, but only 32-bit wide on chip IDs 0x0E30, 0x0E93..0x0E97 and 0x1F60. The driver unconditionally uses 48-bit read/write operations, which on 32-bit variants causes reading 2 bytes past the register boundary (corrupting the value) and writing 2 bytes into the adjacent register. Fix this by storing the chip ID in the device structure during probe and adding a helper to detect the affected variants. Use the correct register width for read/write operations and the matching sign extension bit (31 vs 47) when interpreting the phase compensation value. Fixes: 6287262 ("dpll: zl3073x: Add support to adjust phase") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260220155755.448185-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 4cfe066) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Felix Gu <ustc.gu@gmail.com> commit 676c7af The devm_add_action_or_reset() function already executes the cleanup action on failure before returning an error, so the explicit goto error and subsequent zl3073x_dev_dpll_fini() call causes double cleanup. Fixes: ebb1031 ("dpll: zl3073x: Refactor DPLL initialization") Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Felix Gu <ustc.gu@gmail.com> Link: https://patch.msgid.link/20260224-dpll-v2-1-d7786414a830@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 676c7af) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43006 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Qi Tang <tpluszz77@gmail.com> commit 111a12b validate_fixed_range() admits buf_addr at the exact end of the registered region when len is zero, because the check uses strict greater-than (buf_end > imu->ubuf + imu->len). io_import_fixed() then computes offset == imu->len, which causes the bvec skip logic to advance past the last bio_vec entry and read bv_offset from out-of-bounds slab memory. Return early from io_import_fixed() when len is zero. A zero-length import has no data to transfer and should not walk the bvec array at all. BUG: KASAN: slab-out-of-bounds in io_import_reg_buf+0x697/0x7f0 Read of size 4 at addr ffff888002bcc254 by task poc/103 Call Trace: io_import_reg_buf+0x697/0x7f0 io_write_fixed+0xd9/0x250 __io_issue_sqe+0xad/0x710 io_issue_sqe+0x7d/0x1100 io_submit_sqes+0x86a/0x23c0 __do_sys_io_uring_enter+0xa98/0x1590 Allocated by task 103: The buggy address is located 12 bytes to the right of allocated 584-byte region [ffff888002bcc000, ffff888002bcc248) Fixes: 8622b20 ("io_uring: add validate_fixed_range() for validate fixed buffer") Signed-off-by: Qi Tang <tpluszz77@gmail.com> Link: https://patch.msgid.link/20260329164936.240871-1-tpluszz77@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit 111a12b) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43027 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Qi Tang <tpluszz77@gmail.com> commit a242a9a nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0) Fixes: ac7b848 ("netfilter: expect: add and use nf_ct_expect_iterate helpers") Signed-off-by: Qi Tang <tpluszz77@gmail.com> Reviewed-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit a242a9a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43051 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Benoît Sevens <bsevens@google.com> commit 2f1763f The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received. Signed-off-by: Benoît Sevens <bsevens@google.com> Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by: Jiri Kosina <jkosina@suse.com> (cherry picked from commit 2f1763f) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43110 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Pengpeng Hou <pengpeng@iscas.ac.cn> commit 304950a brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260323074551.93530-1-pengpeng@iscas.ac.cn [add missing wifi prefix] Signed-off-by: Johannes Berg <johannes.berg@intel.com> (cherry picked from commit 304950a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43116 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Pablo Neira Ayuso <pablo@netfilter.org> commit bffcaad Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit bffcaad) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43190 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Florian Westphal <fw@strlen.de> commit 735ee85 Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload). Reported-by: sungzii <sungzii@pm.me> Signed-off-by: Florian Westphal <fw@strlen.de> (cherry picked from commit 735ee85) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author YiFei Zhu <zhuyifei@google.com> commit 1a86a1f I was debugging a NIC driver when I noticed that when I enable threaded busypoll, bpftrace hangs when starting up. dmesg showed: rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 10658 jiffies old. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 40793 jiffies old. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 131273 jiffies old. rcu_tasks_wait_gp: rcu_tasks grace period number 85 (since boot) is 402058 jiffies old. INFO: rcu_tasks detected stalls on tasks: 00000000769f52cd: .N nvcsw: 2/2 holdout: 1 idle_cpu: -1/64 task:napi/eth2-8265 state:R running task stack:0 pid:48300 tgid:48300 ppid:2 task_flags:0x208040 flags:0x00004000 Call Trace: <TASK> ? napi_threaded_poll_loop+0x27c/0x2c0 ? __pfx_napi_threaded_poll+0x10/0x10 ? napi_threaded_poll+0x26/0x80 ? kthread+0xfa/0x240 ? __pfx_kthread+0x10/0x10 ? ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ? ret_from_fork_asm+0x1a/0x30 </TASK> The cause is that in threaded busypoll, the main loop is in napi_threaded_poll rather than napi_threaded_poll_loop, where the latter rarely iterates more than once within its loop. For rcu_softirq_qs_periodic inside napi_threaded_poll_loop to report its qs state, the last_qs must be 100ms behind, and this can't happen because napi_threaded_poll_loop rarely iterates in threaded busypoll, and each time napi_threaded_poll_loop is called last_qs is reset to latest jiffies. This patch changes so that in threaded busypoll, last_qs is saved in the outer napi_threaded_poll, and whether busy_poll_last_qs is NULL indicates whether napi_threaded_poll_loop is called for busypoll. This way last_qs would not reset to latest jiffies on each invocation of napi_threaded_poll_loop. Fixes: c18d4b1 ("net: Extend NAPI threaded polling to allow kthread based busy polling") Cc: stable@vger.kernel.org Signed-off-by: YiFei Zhu <zhuyifei@google.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Link: https://patch.msgid.link/20260227221937.1060857-1-zhuyifei@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 1a86a1f) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Michal Swiatkowski <michal.swiatkowski@linux.intel.com> commit ee13aa1 On some high-core systems (like AMD EPYC Bergamo, Intel Clearwater Forest) loading ice driver with default values can lead to queue/irq exhaustion. It will result in no additional resources for SR-IOV. In most cases there is no performance reason for more than half num_cpus(). Limit the default value to it using generic netif_get_num_default_rss_queues(). Still, using ethtool the number of queues can be changed up to num_online_cpus(). It can be done by calling: $ethtool -L ethX combined $(nproc) This change affects only the default queue amount. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> (cherry picked from commit ee13aa1) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Michal Swiatkowski <michal.swiatkowski@linux.intel.com> commit c7fcd26 When allocating netdevice using alloc_etherdev_mqs() the maximum supported queues number should be passed. The vsi->alloc_txq/rxq is storing current number of queues, not the maximum ones. Use the same function for getting max Tx and Rx queues which is used during ethtool -l call to set maximum number of queues during netdev allocation. Reproduction steps: $ethtool -l $pf # says current 16, max 64 $ethtool -S $pf # fine $ethtool -L $pf combined 40 # crash [491187.472594] Call Trace: [491187.472829] <TASK> [491187.473067] netif_set_xps_queue+0x26/0x40 [491187.473305] ice_vsi_cfg_txq+0x265/0x3d0 [ice] [491187.473619] ice_vsi_cfg_lan_txqs+0x68/0xa0 [ice] [491187.473918] ice_vsi_cfg_lan+0x2b/0xa0 [ice] [491187.474202] ice_vsi_open+0x71/0x170 [ice] [491187.474484] ice_vsi_recfg_qs+0x17f/0x230 [ice] [491187.474759] ? dev_get_min_mp_channel_count+0xab/0xd0 [491187.474987] ice_set_channels+0x185/0x3d0 [ice] [491187.475278] ethnl_set_channels+0x26f/0x340 Fixes: ee13aa1 ("ice: use netif_get_num_default_rss_queues()") Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> (cherry picked from commit c7fcd26) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Christian Brauner <brauner@kernel.org> commit cfd86ef 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-6.12.0-211.18.1.el10_2/cfd86ef7.failed This allows the VFS to not trip over anonymous inodes and we can add asserts based on the mode into the vfs. When we report it to userspace we can simply hide the mode to avoid regressions. I've audited all direct callers of alloc_anon_inode() and only secretmen overrides i_mode and i_op inode operations but it already uses a regular file. Link: https://lore.kernel.org/20250407-work-anon_inode-v1-1-53a44c20d44e@kernel.org Fixes: af153bb ("vfs: catch invalid modes in may_open()") Reviewed-by: Jeff Layton <jlayton@kernel.org> Cc: stable@vger.kernel.org # all LTS kernels Reported-by: syzbot+5d8e79d323a13aa0b248@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67ed3fb3.050a0220.14623d.0009.GAE@google.com Signed-off-by: Christian Brauner <brauner@kernel.org> (cherry picked from commit cfd86ef) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/anon_inodes.c # fs/internal.h
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Christian Brauner <brauner@kernel.org> commit 37e62da So far pidfs did use it's own version. Just use the generic version. We use our own wrappers because we're going to be implementing our own retrieval properties soon. Link: https://lore.kernel.org/20250407-work-anon_inode-v1-2-53a44c20d44e@kernel.org Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org> (cherry picked from commit 37e62da) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Christian Brauner <brauner@kernel.org> commit 22bdf3d 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-6.12.0-211.18.1.el10_2/22bdf3d6.failed It is currently possible to change the mode and owner of the single anonymous inode in the kernel: int main(int argc, char *argv[]) { int ret, sfd; sigset_t mask; struct signalfd_siginfo fdsi; sigemptyset(&mask); sigaddset(&mask, SIGINT); sigaddset(&mask, SIGQUIT); ret = sigprocmask(SIG_BLOCK, &mask, NULL); if (ret < 0) _exit(1); sfd = signalfd(-1, &mask, 0); if (sfd < 0) _exit(2); ret = fchown(sfd, 5555, 5555); if (ret < 0) _exit(3); ret = fchmod(sfd, 0777); if (ret < 0) _exit(3); _exit(4); } This is a bug. It's not really a meaningful one because anonymous inodes don't really figure into path lookup and they cannot be reopened via /proc/<pid>/fd/<nr> and can't be used for lookup itself. So they can only ever serve as direct references. But it is still completely bogus to allow the mode and ownership or any of the properties of the anonymous inode to be changed. Block this! Link: https://lore.kernel.org/20250407-work-anon_inode-v1-3-53a44c20d44e@kernel.org Reviewed-by: Jeff Layton <jlayton@kernel.org> Cc: stable@vger.kernel.org # all LTS kernels Signed-off-by: Christian Brauner <brauner@kernel.org> (cherry picked from commit 22bdf3d) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/anon_inodes.c # fs/internal.h
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Christian Brauner <brauner@kernel.org> commit c83b902 So far pidfs did use it's own version. Just use the generic version. We use our own wrappers because we're going to be implementing properties soon. Link: https://lore.kernel.org/20250407-work-anon_inode-v1-4-53a44c20d44e@kernel.org Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org> (cherry picked from commit c83b902) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Christian Brauner <brauner@kernel.org> commit 1ed9528 It isn't possible to execute anonymous inodes because they cannot be opened in any way after they have been created. This includes execution: execveat(fd_anon_inode, "", NULL, NULL, AT_EMPTY_PATH) Anonymous inodes have inode->f_op set to no_open_fops which sets no_open() which returns ENXIO. That means any call to do_dentry_open() which is the endpoint of the do_open_execat() will fail. There's no chance to execute an anonymous inode. Unless a given subsystem overrides it ofc. However, we should still harden this and raise SB_I_NODEV and SB_I_NOEXEC on the superblock itself so that no one gets any creative ideas. Link: https://lore.kernel.org/20250407-work-anon_inode-v1-5-53a44c20d44e@kernel.org Reviewed-by: Jeff Layton <jlayton@kernel.org> Cc: stable@vger.kernel.org # all LTS kernels Signed-off-by: Christian Brauner <brauner@kernel.org> (cherry picked from commit 1ed9528) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Christian Brauner <brauner@kernel.org> commit 19bbfe7 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-6.12.0-211.18.1.el10_2/19bbfe7b.failed This makes it easy to detect proper anonymous inodes and to ensure that we can detect them in codepaths such as readahead(). Readahead on anonymous inodes didn't work because they didn't have a proper mode. Now that they have we need to retain EINVAL being returned otherwise LTP will fail. We also need to ensure that ioctls aren't simply fired like they are for regular files so things like inotify inodes continue to correctly call their own ioctl handlers as in [1]. Reported-by: Xilin Wu <sophon@radxa.com> Link: https://lore.kernel.org/3A9139D5CD543962+89831381-31b9-4392-87ec-a84a5b3507d8@radxa.com [1] Link: https://lore.kernel.org/7a1a7076-ff6b-4cb0-94e7-7218a0a44028@sirena.org.uk Signed-off-by: Christian Brauner <brauner@kernel.org> (cherry picked from commit 19bbfe7) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # mm/readahead.c
jira KERNEL-1088 cve CVE-2026-23375 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Deepanshu Kartikey <kartikey406@gmail.com> commit dd085fe file_thp_enabled() incorrectly allows THP for files on anonymous inodes (e.g. guest_memfd and secretmem). These files are created via alloc_file_pseudo(), which does not call get_write_access() and leaves inode->i_writecount at 0. Combined with S_ISREG(inode->i_mode) being true, they appear as read-only regular files when CONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP collapse. Anonymous inodes can never pass the inode_is_open_for_write() check since their i_writecount is never incremented through the normal VFS open path. The right thing to do is to exclude them from THP eligibility altogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real filesystem files (e.g. shared libraries), not for pseudo-filesystem inodes. For guest_memfd, this allows khugepaged and MADV_COLLAPSE to create large folios in the page cache via the collapse path, but the guest_memfd fault handler does not support large folios. This triggers WARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping(). For secretmem, collapse_file() tries to copy page contents through the direct map, but secretmem pages are removed from the direct map. This can result in a kernel crash: BUG: unable to handle page fault for address: ffff88810284d000 RIP: 0010:memcpy_orig+0x16/0x130 Call Trace: collapse_file hpage_collapse_scan_file madvise_collapse Secretmem is not affected by the crash on upstream as the memory failure recovery handles the failed copy gracefully, but it still triggers confusing false memory failure reports: Memory failure: 0x106d96f: recovery action for clean unevictable LRU page: Recovered Check IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all anonymous inode files. Link: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44 Link: https://lore.kernel.org/linux-mm/CAEvNRgHegcz3ro35ixkDw39ES8=U6rs6S7iP0gkR9enr7HoGtA@mail.gmail.com Link: https://lkml.kernel.org/r/20260214001535.435626-1-kartikey406@gmail.com Fixes: 7fbb5e1 ("mm: remove VM_EXEC requirement for THP eligibility") Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com> Reported-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=33a04338019ac7e43a44 Tested-by: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com Tested-by: Lance Yang <lance.yang@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Barry Song <baohua@kernel.org> Reviewed-by: Ackerley Tng <ackerleytng@google.com> Tested-by: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Dev Jain <dev.jain@arm.com> Cc: Fangrui Song <i@maskray.me> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Yang Shi <shy828301@gmail.com> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit dd085fe) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43205 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Junrui Luo <moonafterrain@outlook.com> commit ed48a84 The driver allocates arrays for ports, FDBs, and filter blocks using kcalloc() with ethsw->sw_attr.num_ifs as the element count. When the device reports zero interfaces (either due to hardware configuration or firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10) instead of NULL. Later in dpaa2_switch_probe(), the NAPI initialization unconditionally accesses ethsw->ports[0]->netdev, which attempts to dereference ZERO_SIZE_PTR (address 0x10), resulting in a kernel panic. Add a check to ensure num_ifs is greater than zero after retrieving device attributes. This prevents the zero-sized allocations and subsequent invalid pointer dereference. Reported-by: Yuhao Jiang <danisjiang@gmail.com> Reported-by: Junrui Luo <moonafterrain@outlook.com> Fixes: 0b1b713 ("staging: dpaa2-switch: handle Rx path on control interface") Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/SYBPR01MB7881BEABA8DA896947962470AF91A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit ed48a84) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43205 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Junrui Luo <moonafterrain@outlook.com> commit 8a5752c The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ... Fixes: 539dda3 ("staging: dpaa2-switch: properly setup switching domains") Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://patch.msgid.link/SYBPR01MB78812B47B7F0470B617C408AAF74A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 8a5752c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43303 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> commit ac1ea21 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-6.12.0-211.18.1.el10_2/ac1ea219.failed Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use. Link: https://lkml.kernel.org/r/20260207173615.146159-1-mikhail.v.gavrilov@gmail.com Fixes: 3b8000a ("mm/vmalloc: huge vmalloc backing pages should be split rather than compound") Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Suggested-by: Zi Yan <ziy@nvidia.com> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Cc: Brendan Jackman <jackmanb@google.com> Cc: Chris Li <chrisl@kernel.org> Cc: Hugh Dickins <hughd@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <ryncsn@gmail.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit ac1ea21) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # mm/page_alloc.c
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Mikulas Patocka <mpatocka@redhat.com> commit 09a65ad There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in "device mapper: space map common: unable to decrement block" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: 3241b1d ("dm: add persistent data library") Cc: stable@vger.kernel.org (cherry picked from commit 09a65ad) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Herbert Xu <herbert@gondor.apana.org.au> commit 2aeec9a Softirqs must be disabled when calling the finalization fucntion on a request. Reported-by: Guangwu Zhang <guazhang@redhat.com> Fixes: 0880bb3 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 2aeec9a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43020 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Keenan Dong <keenanat2000@gmail.com> commit b8dbe96 Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state. Fixes: 346af67 ("Bluetooth: Add MGMT handlers for dealing with SMP LTK's") Reported-by: Keenan Dong <keenanat2000@gmail.com> Signed-off-by: Keenan Dong <keenanat2000@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> (cherry picked from commit b8dbe96) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43023 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Cen Zhang <zzzccc427@gmail.com> commit 8a5b013 sco_sock_connect() checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter sco_connect(), leading to use-after-free. The buggy scenario involves three participants and was confirmed with additional logging instrumentation: Thread A (connect): HCI disconnect: Thread B (connect): sco_sock_connect(sk) sco_sock_connect(sk) sk_state==BT_OPEN sk_state==BT_OPEN (pass, no lock) (pass, no lock) sco_connect(sk): sco_connect(sk): hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock(sk) sco_chan_add: conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del: lock_sock(sk) sco_chan_del: sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock (unblocked) hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock(sk) sco_chan_add: sk->conn=conn2 sk_state= BT_CONNECT // zombie sk! release_sock hci_dev_unlock Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers double sock_put() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when sco_conn_del() cleared the association. Fix this by: - Moving lock_sock() before the sk_state/sk_type checks in sco_sock_connect() to serialize concurrent connect attempts - Fixing the sk_type != SOCK_SEQPACKET check to actually return the error instead of just assigning it - Adding a state re-check in sco_connect() after lock_sock() to catch state changes during the window between the locks - Adding sco_pi(sk)->conn check in sco_chan_add() to prevent double-attach of a socket to multiple connections - Adding hci_conn_drop() on sco_chan_add failure to prevent HCI connection leaks Fixes: 9a8ec9e ("Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm") Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> (cherry picked from commit 8a5b013) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43158 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Darrick J. Wong <djwong@kernel.org> commit 6f13c1d Back in commit 2a2b593 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time. Cc: <stable@vger.kernel.org> # v2.6.12 Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> (cherry picked from commit 6f13c1d) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1088 cve CVE-2026-43158 Rebuild_History Non-Buildable kernel-6.12.0-211.18.1.el10_2 commit-author Darrick J. Wong <djwong@kernel.org> commit 3eefc0c xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b593 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0. Cc: <stable@vger.kernel.org> # v2.6.12 Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> (cherry picked from commit 3eefc0c) 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 v6.12~1..kernel-mainline: 123983 Number of commits in rpm: 85 Number of commits matched with upstream: 80 (94.12%) Number of commits in upstream but not in rpm: 123903 Number of commits NOT found in upstream: 5 (5.88%) Rebuilding Kernel on Branch rocky10_2_rebuild_kernel-6.12.0-211.18.1.el10_2 for kernel-6.12.0-211.18.1.el10_2 Clean Cherry Picks: 35 (43.75%) Empty Cherry Picks: 4 (5.00%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-6.12.0-211.18.1.el10_2/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
Collaborator
We found 80 commits that matched upstream, but we only ended up with 39 (35 clean, 4 empty). Usually when those don't apply, don't we end up with .failed files in the ciq directory? Just want to make sure we didn't miss something here. |
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:6.12.0-211)git cherry-pickrpmbuild -bpfor the correspondingsrc.rpmJIRA Tickets
Rebuild Splat Inspection
kernel-6.12.0-211.18.1.el10_2
BUILD
KSelfTests