[rocky9_8] History Rebuild through kernel-5.14.0-687.31.1.el9_8 - #1485
Open
PlaidCat wants to merge 22 commits into
Open
[rocky9_8] History Rebuild through kernel-5.14.0-687.31.1.el9_8#1485PlaidCat wants to merge 22 commits into
PlaidCat wants to merge 22 commits into
Conversation
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Olga Kornievskaia <okorniev@redhat.com> commit d042406 If we are trying to unlock the filesystem via an administrative interface and nfsd isn't running, it crashes the server. This happens currently because nfsd4_revoke_states() access state structures (eg., conf_id_hashtbl) that has been freed as a part of the server shutdown. [ 59.465072] Call trace: [ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P) [ 59.465830] write_unlock_fs+0x258/0x440 [nfsd] [ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd] [ 59.466780] vfs_write+0x1f0/0x938 [ 59.467088] ksys_write+0xfc/0x1f8 [ 59.467395] __arm64_sys_write+0x74/0xb8 [ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8 [ 59.468177] do_el0_svc+0x154/0x1d8 [ 59.468489] el0_svc+0x40/0xe0 [ 59.468767] el0t_64_sync_handler+0xa0/0xe8 [ 59.469138] el0t_64_sync+0x1ac/0x1b0 Ensure this can't happen by taking the nfsd_mutex and checking that the server is still up, and then holding the mutex across the call to nfsd4_revoke_states(). Reviewed-by: NeilBrown <neil@brown.name> Reviewed-by: Jeff Layton <jlayton@kernel.org> Fixes: 1ac3629 ("nfsd: prepare for supporting admin-revocation of state") Cc: stable@vger.kernel.org Signed-off-by: Olga Kornievskaia <okorniev@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> (cherry picked from commit d042406) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author NeilBrown <neil@brown.name> commit fb32199 The loop in nfsd4_revoke_states() stops one too early because the end value given is CLIENT_HASH_MASK where it should be CLIENT_HASH_SIZE. This means that an admin request to drop all locks for a filesystem will miss locks held by clients which hash to the maximum possible hash value. Fixes: 1ac3629 ("nfsd: prepare for supporting admin-revocation of state") Cc: stable@vger.kernel.org Signed-off-by: NeilBrown <neil@brown.name> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> (cherry picked from commit fb32199) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 cve CVE-2026-23002 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Shakeel Butt <shakeel.butt@linux.dev> commit 777a856 Prevent a "BUG: unable to handle kernel NULL pointer dereference in filemap_read_folio". For the sleepable context, convert freader to use __kernel_read() instead of direct page cache access via read_cache_folio(). This simplifies the faultable code path by using the standard kernel file reading interface which handles all the complexity of reading file data. At the moment we are not changing the code for non-sleepable context which uses filemap_get_folio() and only succeeds if the target folios are already in memory and up-to-date. The reason is to keep the patch simple and easier to backport to stable kernels. Syzbot repro does not crash the kernel anymore and the selftests run successfully. In the follow up we will make __kernel_read() with IOCB_NOWAIT work for non-sleepable contexts. In addition, I would like to replace the secretmem check with a more generic approach and will add fstest for the buildid code. Link: https://lkml.kernel.org/r/20251222205859.3968077-1-shakeel.butt@linux.dev Fixes: ad41251 ("lib/buildid: implement sleepable build_id_parse() API") Reported-by: syzbot+09b7d050e4806540153d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=09b7d050e4806540153d Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Jinchao Wang <wangjinchao600@gmail.com> Link: https://lkml.kernel.org/r/aUteBPWPYzVWIZFH@ndev Reviewed-by: Christian Brauner <brauner@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Daniel Borkman <daniel@iogearbox.net> Cc: "Darrick J. Wong" <djwong@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit 777a856) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Zhenzhong Duan <zhenzhong.duan@intel.com> commit a6dea58 Below oops triggers when kill QEMU process: Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: <TASK> do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The global static blocked domain is a dummy domain without corresponding dmar_domain structure, accessing beyond iommu_domain structure triggers oops easily. Fix it by return early in domain_remove_dev_pasid() like identity domain. Fixes: 7d0c9da ("iommu/vt-d: Add set_dev_pasid callback for dma domain") Cc: stable@vger.kernel.org Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260421031347.1408890-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> (cherry picked from commit a6dea58) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 cve CVE-2026-53281 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Zhenzhong Duan <zhenzhong.duan@intel.com> commit 79ea2fe Commit 60f030f ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") fixed a NULL pointer dereference in an unlikely situation partly. If dev_pasid is not found in the dev_pasids list, it remains NULL. However, the teardown operations are executed unconditionally, this lead to a NULL pointer dereference or refcount corruption. If the domain was never attached to this IOMMU, info will be NULL, which would cause an immediate dereference when checking --info->refcnt. Even if info is not NULL, decrementing the refcount without having removed a valid PASID might unbalance the count. This could lead to premature dropping of the refcount to 0, potentially causing a use-after-free for the remaining active devices sharing the domain. Fix it by returning early if dev_pasid is NULL, before executing the teardown operations. Issue found by AI review and suggested by Kevin Tian. https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com Fixes: 60f030f ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") Cc: stable@vger.kernel.org Suggested-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260422033538.95000-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> (cherry picked from commit 79ea2fe) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 cve CVE-2025-39797 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Aakash Kumar S <saakashkumar@marvell.com> commit 94f3980 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.31.1.el9_8/94f39804.failed The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses. This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops. According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol. Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable. Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto. Signed-off-by: Aakash Kumar S <saakashkumar@marvell.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit 94f3980) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/xfrm/xfrm_state.c
jira KERNEL-1399 cve CVE-2025-39797 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Sabrina Dubroca <sd@queasysnail.net> commit cd8ae32 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.31.1.el9_8/cd8ae32e.failed x->id.spi == 0 means "no SPI assigned", but since commit 94f3980 ("xfrm: Duplicate SPI Handling"), we now create states and add them to the byspi list with this value. __xfrm_state_delete doesn't remove those states from the byspi list, since they shouldn't be there, and this shows up as a UAF the next time we go through the byspi list. Reported-by: syzbot+a25ee9d20d31e483ba7b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a25ee9d20d31e483ba7b Fixes: 94f3980 ("xfrm: Duplicate SPI Handling") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit cd8ae32) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/xfrm/xfrm_state.c
…emap_resource() jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Cai Huoqing <caihuoqing@baidu.com> commit 79cc4d2 Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210907074230.2757-1-caihuoqing@baidu.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit 79cc4d2) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Curtis Klein <curtis.klein@hpe.com> commit cf6ea95 Some watchdog devices might conditionally support pretimeouts (e.g. if an interrupt is exposed for the device) but some watchdog drivers might still define the set_pretimeout operation (e.g. the mtk_wdt driver) and indicate support at runtime through the WDIOF_PRETIMEOUT flag. If the kernel is compiled with CONFIG_WATCHDOG_HRTIMER_PRETIMEOUT enabled, watchdog_set_pretimeout would run the driver specific set_pretimeout even if WDIOF_PRETIMEOUT is not set which might have unintended consequences. So this change checks that the device flags and only runs the driver operation if pretimeouts are supported. Signed-off-by: Curtis Klein <curtis.klein@hpe.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1624751265-24785-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit cf6ea95) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Mika Westerberg <mika.westerberg@linux.intel.com> commit 1ae3e78 The watchdog core can handle pinging of the watchdog before userspace opens the device. For this reason instead of stopping the timer, just mark it as running and let the watchdog core take care of it. Cc: Malin Jonsson <malin.jonsson@ericsson.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210921102900.61586-1-mika.westerberg@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit 1ae3e78) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Liu Xinpeng <liuxp11@chinatelecom.cn> commit 9ef9589 For power management, SET_NOIRQ_SYSTEM_SLEEP_PM_OPS defined for CONFIG_PM_SLEEP, will point ->suspend_noirq, ->freeze_noirq and ->poweroff_noirq to the same function. Vice versa happens for ->resume_noirq, ->thaw_noirq and ->restore_noirq. Signed-off-by: Liu Xinpeng <liuxp11@chinatelecom.cn> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1650967905-3199-1-git-send-email-liuxp11@chinatelecom.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit 9ef9589) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Mika Westerberg <mika.westerberg@linux.intel.com> commit ef9b7bf Daniel reported that the commit 1ae3e78 ("watchdog: iTCO_wdt: No need to stop the timer in probe") makes QEMU implementation of the iTCO watchdog not to trigger reboot anymore when NO_REBOOT flag is initially cleared using this option (in QEMU command line): -global ICH9-LPC.noreboot=false The problem with the commit is that it left the unconditional setting of NO_REBOOT that is not cleared anymore when the kernel keeps pinging the watchdog (as opposed to the previous code that called iTCO_wdt_stop() that cleared it). Fix this so that we only set NO_REBOOT if the watchdog was not initially running. Fixes: 1ae3e78 ("watchdog: iTCO_wdt: No need to stop the timer in probe") Reported-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20221028062750.45451-1-mika.westerberg@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit ef9b7bf) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Thomas Weißschuh <linux@weissschuh.net> commit 4ea6b98 Synchronize the reported information in dmesg and the watchdog APIs. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20221125221240.2818-1-linux@weissschuh.net Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit 4ea6b98) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Xing Tong Wu <xingtong.wu@siemens.com> commit 725b6a8 According to the WDAT spec that states about WATCHDOG_ACTION_SET_COUNTDOWN_PERIOD: "This action is required if WATCHDOG_ACTION_RESET does not explicitly write a new countdown value to a register during a reset." And that implies, WATCHDOG_ACTION_RESET may write a countdown value, thus may come with a WATCHDOG_INSTRUCTION_WRITE_COUNTDOWN, thus need the timeout value as parameter or would otherwise write 0. The watchdog for SIONCT6126 need a entry WATCHDOG_INSTRUCTION_WRITE_COUNTDOWN for WATCHDOG_ACTION_RESET action, I send this patch to support it. Signed-off-by: Xing Tong Wu <xingtong.wu@siemens.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20231007082125.4699-1-xingtong_wu@163.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit 725b6a8) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Chen Ni <nichen@iscas.ac.cn> commit 35ff0eb Replace a comma between expression statements by a semicolon. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Reviewed-by: Andy Shevchenko <andy@kernel.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20240902081051.3824822-1-nichen@iscas.ac.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit 35ff0eb) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Nam Cao <namcao@linutronix.de> commit d2254b0 hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/a5c62f2b5e1ea1cf4d32f37bc2d21a8eeab2f875.1738746821.git.namcao@linutronix.de (cherry picked from commit d2254b0) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Haotian Zhang <vulab@iscas.ac.cn> commit 25c0b47 wdat_wdt_probe() calls acpi_get_table() to obtain the WDAT ACPI table but never calls acpi_put_table() on any paths. This causes a permanent ACPI table memory leak. Add a single cleanup path which calls acpi_put_table() to ensure the ACPI table is always released. Fixes: 058dfc7 ("ACPI / watchdog: Add support for WDAT hardware watchdog") Suggested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit 25c0b47) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Curtis Klein <curtis.klein@hpe.com> commit c7b178d watchdog_hrtimer_pretimeout_stop needs the watchdog device to have a valid pointer to the watchdog core data to stop the pretimeout hrtimer. Therefore it needs to be called before the pointers are cleared in watchdog_cdev_unregister. Fixes: 7b7d2fd ("watchdog: Add hrtimer-based pretimeout feature") Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Curtis Klein <curtis.klein@hpe.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1624429583-5720-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> (cherry picked from commit c7b178d) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 cve CVE-2026-52973 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Davidlohr Bueso <dave@stgolabs.net> commit ee9dce4 Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie: BUG: KASAN: slab-use-after-free in futex_hash_put ... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at. Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM. Link: https://lore.kernel.org/all/CAL_bE8LsmCQ-FAtYDuwbJhOkt9p2wwYQwAbMh=PifC=VsiBM6A@mail.gmail.com/ [0] Fixes: d9b0532 ("futex: Move futex_hash_free() back to __mmput()") Reported-by: Yiming Qian <yimingqian591@gmail.com> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit ee9dce4) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 cve CVE-2026-64017 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Keith Busch <kbusch@kernel.org> commit dc278e9 When submitting a bio to blk-mq, if the task should sleep after peeking a cached request, but before it pops it, the plug flushes and calls blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a use-after-free bug. Fix this by popping the cached request before any possible blocking calls if it is suitable for use. Popping this request first holds a queue reference, so avoid any serialization races with queue freezes and can safely proceed with dispatching that request to the driver. This potentially increases a timing window from when a driver wants to freeze its queue to when requests stop being dispatched. That scenario is off the fast path though, and drivers need to appropriately handle requests during a freeze request anyway. The downside is the popped element needs to be individually freed when we performed a bio plug merge. The cached request would have had to be freed later anyway, but this patch does it inline with building the plug list instead of after flushing it. Fixes: b0077e2 ("blk-mq: make sure active queue usage is held for bio_integrity_prep()") Fixes: 7b4f36c ("block: ensure we hold a queue reference when using queue limits") Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260521190253.242065-1-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit dc278e9) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1399 cve CVE-2026-64017 Rebuild_History Non-Buildable kernel-5.14.0-687.31.1.el9_8 commit-author Keith Busch <kbusch@kernel.org> commit b051bb6 A previous commit removed an optimization out of caution for a scenario that turns out not to be real: all the "queue_exit" goto's are safe to reinsert the request into the cached_rq's plug list as they are either from a non-blocking path, or a successful merge that already holds the queue reference. This optimization is most needed for small sequential workloads that successfully merge into larger requests. Fixes: dc278e9 ("blk-mq: pop cached request if it is usable") Suggested-by: Ming Lei <tom.leiming@gmail.com> Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://patch.msgid.link/20260526153531.2365935-1-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk> (cherry picked from commit b051bb6) 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: 25 Number of commits matched with upstream: 21 (84.00%) Number of commits in upstream but not in rpm: 394094 Number of commits NOT found in upstream: 4 (16.00%) Rebuilding Kernel on Branch rocky9_8_rebuild_kernel-5.14.0-687.31.1.el9_8 for kernel-5.14.0-687.31.1.el9_8 Clean Cherry Picks: 19 (90.48%) Empty Cherry Picks: 2 (9.52%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-5.14.0-687.31.1.el9_8/rebuild.details.txt Includes: * git commit header above * Empty Commits with upstream SHA * RPM ChangeLog Entries that could not be matched Individual Empty Commit failures contained in the same containing directory. The git message for empty commits will have the path for the failed commit. File names are the first 8 characters of the upstream SHA
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.31.1.el9_8
BUILD
KSelfTests