- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] x86/fpu: Ensure XFD state on signal delivery
by Zhang Kunbo 22 Dec '25

22 Dec '25

From: "Chang S. Bae" <chang.seok.bae(a)intel.com> stable inclusion from stable-v6.6.117 commit 1811c610653c0cd21cc9add14595b7cffaeca511 category: bugfix bugzilla: https://gitcode.com/src-openeuler/kernel/issues/11604 CVE: CVE-2025-68171 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9 upstream. Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Reviewed-by: Chao Gao <chao.gao(a)intel.com> Tested-by: Chao Gao <chao.gao(a)intel.com> Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kernel/fpu/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index e0aa2dfb89d1..1885c45fa6eb 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -809,6 +809,9 @@ void fpu__clear_user_states(struct fpu *fpu) !fpregs_state_valid(fpu, smp_processor_id())) os_xrstor_supervisor(fpu->fpstate); + /* Ensure XFD state is in sync before reloading XSTATE */ + xfd_update_state(fpu->fpstate); + /* Reset user states in registers. */ restore_fpregs_from_init_fpstate(XFEATURE_MASK_USER_RESTORE); -- 2.34.1

2 1

[PATCH OLK-6.6] timers: Fix NULL function pointer race in timer_shutdown_sync()
by Jinjie Ruan 22 Dec '25

22 Dec '25

From: Yipeng Zou <zouyipeng(a)huawei.com> stable inclusion from stable-v6.6.118 commit 6665fbd7730b26d770c232b20d1b907e6a67a914 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11566 CVE: CVE-2025-68214 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 20739af07383e6eb1ec59dcd70b72ebfa9ac362c upstream. There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- kernel/time/timer.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 63a8ce7177dd..4a2aeaa85af3 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1413,10 +1413,11 @@ static int __try_to_del_timer_sync(struct timer_list *timer, bool shutdown) base = lock_timer_base(timer, &flags); - if (base->running_timer != timer) + if (base->running_timer != timer) { ret = detach_if_pending(timer, base, true); - if (shutdown) - timer->function = NULL; + if (shutdown) + timer->function = NULL; + } raw_spin_unlock_irqrestore(&base->lock, flags); -- 2.34.1

2 1

[PATCH OLK-6.6] x86/fpu: Ensure XFD state on signal delivery
by Zhang Kunbo 22 Dec '25

22 Dec '25

From: "Chang S. Bae" <chang.seok.bae(a)intel.com> stable inclusion from stable-v6.6.117 commit 1811c610653c0cd21cc9add14595b7cffaeca511 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEWO CVE: CVE-2025-68171 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9 upstream. Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Reviewed-by: Chao Gao <chao.gao(a)intel.com> Tested-by: Chao Gao <chao.gao(a)intel.com> Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kernel/fpu/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index 9a31f3db713c..1f0871be9d53 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -865,6 +865,9 @@ void fpu__clear_user_states(struct fpu *fpu) !fpregs_state_valid(fpu, smp_processor_id())) os_xrstor_supervisor(fpu->fpstate); + /* Ensure XFD state is in sync before reloading XSTATE */ + xfd_update_state(fpu->fpstate); + /* Reset user states in registers. */ restore_fpregs_from_init_fpstate(XFEATURE_MASK_USER_RESTORE); -- 2.34.1

2 1

[openeuler:OLK-5.10 3415/3415] drivers/irqchip/irq-gic-v3-its.c:504:6: warning: no previous prototype for 'build_devid_pools'
by kernel test robot 22 Dec '25

22 Dec '25

Hi Jia, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1588d318a9e388d05b6cf5e2a63134c8beb6a355 commit: af552f9d957def499065ed6e194bcd5f0c75dbc5 [3415/3415] irqchip/gic-v3-its: Move build_devid_pools from its to acpi iort init config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20251222/202512220941.znSG62CM-lkp@…) compiler: aarch64-linux-gcc (GCC) 15.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251222/202512220941.znSG62CM-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512220941.znSG62CM-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/irqchip/irq-gic-v3-its.c:504:6: warning: no previous prototype for 'build_devid_pools' [-Wmissing-prototypes] 504 | void build_devid_pools(void) | ^~~~~~~~~~~~~~~~~ vim +/build_devid_pools +504 drivers/irqchip/irq-gic-v3-its.c 500 501 /* 502 * Currently we only build *one* devid pool. 503 */ > 504 void build_devid_pools(void) 505 { 506 struct its_node *its; 507 508 its = list_first_entry(&its_nodes, struct its_node, entry); 509 if (readl_relaxed(its->base + GITS_IIDR) != 0x00051736) 510 return; 511 512 if (!probe_devid_pool_one()) 513 rsv_devid_pool_cap = true; 514 515 if (rsv_devid_pool_cap) 516 pr_info("ITS: reserved device id pools enabled\n"); 517 } 518 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] ftrace: Fix softlockup in ftrace_module_enable
by Tengda Wu 22 Dec '25

22 Dec '25

From: Vladimir Riabchun <ferr.lambarginio(a)gmail.com> stable inclusion from stable-v6.6.119 commit e81e6d6d99b16dae11adbeda5c996317942a940c category: bugfix bugzilla: http://gitcode.com/src-openeuler/kernel/issues/11609 CVE: CVE-2025-68173 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4099b98203d6b33d990586542fa5beee408032a3 ] A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()"). Fix it the same way by adding cond_resched() in ftrace_module_enable. Link: https://lore.kernel.org/aMQD9_lxYmphT-up@vova-pc Signed-off-by: Vladimir Riabchun <ferr.lambarginio(a)gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/ftrace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 15785a729a0c..398992597685 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6873,6 +6873,8 @@ void ftrace_module_enable(struct module *mod) if (!within_module(rec->ip, mod)) break; + cond_resched(); + /* Weak functions should still be ignored */ if (!test_for_valid_rec(rec)) { /* Clear all other flags. Should not be enabled anyway */ -- 2.34.1

2 1

[PATCH OLK-6.6] erofs: avoid infinite loops due to corrupted subpage compact indexes
by Zizhi Wo 22 Dec '25

22 Dec '25

From: Gao Xiang <hsiangkao(a)linux.alibaba.com> stable inclusion from stable-v6.17.6 commit 8675447a8794983f2b7e694b378112772c17635e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11522 CVE: CVE-2025-68251 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e13d315ae077bb7c3c6027cc292401bc0f4ec683 ] Robert reported an infinite loop observed by two crafted images. The root cause is that `clusterofs` can be larger than `lclustersize` for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515 Move the corresponding check for full compress indexes to `z_erofs_load_lcluster_from_disk()` to also cover subpage compact compress indexes. It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX` check, since it should be placed right after `z_erofs_load_{compact,full}_lcluster()`. Fixes: 8d2517aaeea3 ("erofs: fix up compacted indexes for block size < 4096") Fixes: 1a5223c182fd ("erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()") Reported-by: Robert Morris <rtm(a)csail.mit.edu> Closes: https://lore.kernel.org/r/35167.1760645886@localhost Reviewed-by: Hongbo Li <lihongbo22(a)huawei.com> Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/erofs/zmap.c [1. z_erofs_load_full_lcluster() function conflicts due to commit: d69189428d50 ("erofs: clean up z_erofs_load_full_lcluster()"); 2. z_erofs_load_lcluster_from_disk() function conflicts due to commit: 1a5223c182fd ("erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()"); 3. "z_lclusterbits" -> "z_logical_clusterbits" due to commit: efb2aef569b3 ("erofs: add encoded extent on-disk definition"); Both are not affect this patch.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/erofs/zmap.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/fs/erofs/zmap.c b/fs/erofs/zmap.c index 76566c2cbf63..0603ccd00b3c 100644 --- a/fs/erofs/zmap.c +++ b/fs/erofs/zmap.c @@ -67,10 +67,6 @@ static int z_erofs_load_full_lcluster(struct z_erofs_maprecorder *m, if (advise & Z_EROFS_LI_PARTIAL_REF) m->partialref = true; m->clusterofs = le16_to_cpu(di->di_clusterofs); - if (m->clusterofs >= 1 << vi->z_logical_clusterbits) { - DBG_BUGON(1); - return -EFSCORRUPTED; - } m->pblk = le32_to_cpu(di->di_u.blkaddr); break; default: @@ -276,14 +272,25 @@ static int z_erofs_load_compact_lcluster(struct z_erofs_maprecorder *m, static int z_erofs_load_lcluster_from_disk(struct z_erofs_maprecorder *m, unsigned int lcn, bool lookahead) { - switch (EROFS_I(m->inode)->datalayout) { - case EROFS_INODE_COMPRESSED_FULL: - return z_erofs_load_full_lcluster(m, lcn); - case EROFS_INODE_COMPRESSED_COMPACT: - return z_erofs_load_compact_lcluster(m, lcn, lookahead); - default: - return -EINVAL; + struct erofs_inode *vi = EROFS_I(m->inode); + int err; + + if (vi->datalayout == EROFS_INODE_COMPRESSED_COMPACT) { + err = z_erofs_load_compact_lcluster(m, lcn, lookahead); + } else { + DBG_BUGON(vi->datalayout != EROFS_INODE_COMPRESSED_FULL); + err = z_erofs_load_full_lcluster(m, lcn); } + if (err) + return err; + + if (m->type != Z_EROFS_LCLUSTER_TYPE_NONHEAD && + m->clusterofs >= (1 << vi->z_logical_clusterbits)) { + DBG_BUGON(1); + return -EFSCORRUPTED; + } + + return 0; } static int z_erofs_extent_lookback(struct z_erofs_maprecorder *m, -- 2.39.2

2 1

[PATCH OLK-5.10] x86/fpu: Ensure XFD state on signal delivery
by Zhang Kunbo 22 Dec '25

22 Dec '25

From: "Chang S. Bae" <chang.seok.bae(a)intel.com> stable inclusion from stable-v6.6.117 commit 1811c610653c0cd21cc9add14595b7cffaeca511 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEWO CVE: CVE-2025-68171 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9 upstream. Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Reviewed-by: Chao Gao <chao.gao(a)intel.com> Tested-by: Chao Gao <chao.gao(a)intel.com> Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kernel/fpu/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index e0aa2dfb89d1..1885c45fa6eb 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -809,6 +809,9 @@ void fpu__clear_user_states(struct fpu *fpu) !fpregs_state_valid(fpu, smp_processor_id())) os_xrstor_supervisor(fpu->fpstate); + /* Ensure XFD state is in sync before reloading XSTATE */ + xfd_update_state(fpu->fpstate); + /* Reset user states in registers. */ restore_fpregs_from_init_fpstate(XFEATURE_MASK_USER_RESTORE); -- 2.34.1

2 1

[PATCH OLK-6.6] erofs: avoid infinite loops due to corrupted subpage compact indexes
by Zizhi Wo 22 Dec '25

22 Dec '25

From: Gao Xiang <hsiangkao(a)linux.alibaba.com> stable inclusion from stable-v6.17.6 commit 8675447a8794983f2b7e694b378112772c17635e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDF3Q CVE: CVE-2025-68251 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e13d315ae077bb7c3c6027cc292401bc0f4ec683 ] Robert reported an infinite loop observed by two crafted images. The root cause is that `clusterofs` can be larger than `lclustersize` for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.: blocksize = lclustersize = 512 lcn = 6 clusterofs = 515 Move the corresponding check for full compress indexes to `z_erofs_load_lcluster_from_disk()` to also cover subpage compact compress indexes. It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX` check, since it should be placed right after `z_erofs_load_{compact,full}_lcluster()`. Fixes: 8d2517aaeea3 ("erofs: fix up compacted indexes for block size < 4096") Fixes: 1a5223c182fd ("erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()") Reported-by: Robert Morris <rtm(a)csail.mit.edu> Closes: https://lore.kernel.org/r/35167.1760645886@localhost Reviewed-by: Hongbo Li <lihongbo22(a)huawei.com> Signed-off-by: Gao Xiang <hsiangkao(a)linux.alibaba.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/erofs/zmap.c [1. z_erofs_load_full_lcluster() function conflicts due to commit: d69189428d50 ("erofs: clean up z_erofs_load_full_lcluster()"); 2. z_erofs_load_lcluster_from_disk() function conflicts due to commit: 1a5223c182fd ("erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()"); 3. "z_lclusterbits" -> "z_logical_clusterbits" due to commit: efb2aef569b3 ("erofs: add encoded extent on-disk definition"); Both are not affect this patch.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/erofs/zmap.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/fs/erofs/zmap.c b/fs/erofs/zmap.c index 76566c2cbf63..0603ccd00b3c 100644 --- a/fs/erofs/zmap.c +++ b/fs/erofs/zmap.c @@ -67,10 +67,6 @@ static int z_erofs_load_full_lcluster(struct z_erofs_maprecorder *m, if (advise & Z_EROFS_LI_PARTIAL_REF) m->partialref = true; m->clusterofs = le16_to_cpu(di->di_clusterofs); - if (m->clusterofs >= 1 << vi->z_logical_clusterbits) { - DBG_BUGON(1); - return -EFSCORRUPTED; - } m->pblk = le32_to_cpu(di->di_u.blkaddr); break; default: @@ -276,14 +272,25 @@ static int z_erofs_load_compact_lcluster(struct z_erofs_maprecorder *m, static int z_erofs_load_lcluster_from_disk(struct z_erofs_maprecorder *m, unsigned int lcn, bool lookahead) { - switch (EROFS_I(m->inode)->datalayout) { - case EROFS_INODE_COMPRESSED_FULL: - return z_erofs_load_full_lcluster(m, lcn); - case EROFS_INODE_COMPRESSED_COMPACT: - return z_erofs_load_compact_lcluster(m, lcn, lookahead); - default: - return -EINVAL; + struct erofs_inode *vi = EROFS_I(m->inode); + int err; + + if (vi->datalayout == EROFS_INODE_COMPRESSED_COMPACT) { + err = z_erofs_load_compact_lcluster(m, lcn, lookahead); + } else { + DBG_BUGON(vi->datalayout != EROFS_INODE_COMPRESSED_FULL); + err = z_erofs_load_full_lcluster(m, lcn); } + if (err) + return err; + + if (m->type != Z_EROFS_LCLUSTER_TYPE_NONHEAD && + m->clusterofs >= (1 << vi->z_logical_clusterbits)) { + DBG_BUGON(1); + return -EFSCORRUPTED; + } + + return 0; } static int z_erofs_extent_lookback(struct z_erofs_maprecorder *m, -- 2.39.2

2 1

[PATCH OLK-6.6] ftrace: Fix softlockup in ftrace_module_enable
by Tengda Wu 22 Dec '25

22 Dec '25

From: Vladimir Riabchun <ferr.lambarginio(a)gmail.com> stable inclusion from stable-v6.6.119 commit e81e6d6d99b16dae11adbeda5c996317942a940c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEWE CVE: CVE-2025-68173 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4099b98203d6b33d990586542fa5beee408032a3 ] A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()"). Fix it the same way by adding cond_resched() in ftrace_module_enable. Link: https://lore.kernel.org/aMQD9_lxYmphT-up@vova-pc Signed-off-by: Vladimir Riabchun <ferr.lambarginio(a)gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/ftrace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 15785a729a0c..398992597685 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6873,6 +6873,8 @@ void ftrace_module_enable(struct module *mod) if (!within_module(rec->ip, mod)) break; + cond_resched(); + /* Weak functions should still be ignored */ if (!test_for_valid_rec(rec)) { /* Clear all other flags. Should not be enabled anyway */ -- 2.34.1

2 1

[openeuler:OLK-5.10 3420/3420] drivers/cpufreq/intel_pstate.c:1473:6: sparse: sparse: symbol 'notify_hwp_interrupt' was not declared. Should it be static?
by kernel test robot 22 Dec '25

22 Dec '25

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1588d318a9e388d05b6cf5e2a63134c8beb6a355 commit: e217d5958ee378eb304fb0b4eb6fcb551e555842 [3420/3420] cpufreq: intel_pstate: Process HWP Guaranteed change notification config: x86_64-randconfig-123-20251218 (https://download.01.org/0day-ci/archive/20251222/202512220826.pYRgbdJv-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251222/202512220826.pYRgbdJv-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512220826.pYRgbdJv-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/cpufreq/intel_pstate.c:1473:6: sparse: sparse: symbol 'notify_hwp_interrupt' was not declared. Should it be static? vim +/notify_hwp_interrupt +1473 drivers/cpufreq/intel_pstate.c 1472 > 1473 void notify_hwp_interrupt(void) 1474 { 1475 unsigned int this_cpu = smp_processor_id(); 1476 struct cpudata *cpudata; 1477 unsigned long flags; 1478 u64 value; 1479 1480 if (!READ_ONCE(hwp_active) || !boot_cpu_has(X86_FEATURE_HWP_NOTIFY)) 1481 return; 1482 1483 rdmsrl_safe(MSR_HWP_STATUS, &value); 1484 if (!(value & 0x01)) 1485 return; 1486 1487 spin_lock_irqsave(&hwp_notify_lock, flags); 1488 1489 if (!cpumask_test_cpu(this_cpu, &hwp_intr_enable_mask)) 1490 goto ack_intr; 1491 1492 /* 1493 * Currently we never free all_cpu_data. And we can't reach here 1494 * without this allocated. But for safety for future changes, added 1495 * check. 1496 */ 1497 if (unlikely(!READ_ONCE(all_cpu_data))) 1498 goto ack_intr; 1499 1500 /* 1501 * The free is done during cleanup, when cpufreq registry is failed. 1502 * We wouldn't be here if it fails on init or switch status. But for 1503 * future changes, added check. 1504 */ 1505 cpudata = READ_ONCE(all_cpu_data[this_cpu]); 1506 if (unlikely(!cpudata)) 1507 goto ack_intr; 1508 1509 schedule_delayed_work(&cpudata->hwp_notify_work, msecs_to_jiffies(10)); 1510 1511 spin_unlock_irqrestore(&hwp_notify_lock, flags); 1512 1513 return; 1514 1515 ack_intr: 1516 wrmsrl_safe(MSR_HWP_STATUS, 0); 1517 spin_unlock_irqrestore(&hwp_notify_lock, flags); 1518 } 1519 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0