February 2026 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] interference: Fix uninitialized ifs_clock compiling issue
by Pu Lehui 02 Feb '26

02 Feb '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/7429 -------------------------------- When compiling with clang, it will occur the warning: 623 | if (__mutex_trylock(lock)) { | ^~~~~~~~~~~~~~~~~~~~~ kernel/locking/mutex.c:725:24: note: uninitialized use occurs here 725 | cgroup_ifs_leave_lock(ifs_clock, IFS_MUTEX); | ^~~~~~~~~ kernel/locking/mutex.c:623:2: note: remove the 'if' if its condition is always false 623 | if (__mutex_trylock(lock)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ 624 | if (ww_ctx) | ~~~~~~~~~~~ 625 | __ww_mutex_check_waiters(lock, ww_ctx); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 626 | 627 | goto skip_wait; | ~~~~~~~~~~~~~~~ 628 | } | ~ kernel/locking/mutex.c:576:15: note: initialize the variable 'ifs_clock' to silence this warning 576 | u64 ifs_clock; | ^ | = 0 2 warnings generated. Let's fix it by zero initialize ifs_clock. Fixes: a1ad9b2ed459 ("interference: Add mutex interference track support") Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- include/linux/cgroup.h | 3 +++ kernel/locking/mutex.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h index 05a9cef2edac..d4f69e89b3fb 100644 --- a/include/linux/cgroup.h +++ b/include/linux/cgroup.h @@ -1000,6 +1000,9 @@ static inline void cgroup_ifs_leave_lock(u64 clock, enum ifs_types t) if (!cgroup_ifs_enabled()) return; + if (unlikely(!clock)) + return; + ifs = current_ifs(); if (ifs) { ifsc = this_cpu_ptr(ifs->pcpu); diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c index 1003afe8dd74..038c6fb9d71d 100644 --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -573,7 +573,7 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas { struct mutex_waiter waiter; struct ww_mutex *ww; - u64 ifs_clock; + u64 ifs_clock = 0; int ret; if (!use_ww_ctx) -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] usb: typec: altmodes/displayport: fix pin_assignment_show
by Yin Tirui 02 Feb '26

02 Feb '26

From: Badhri Jagan Sridharan <badhri(a)google.com> stable inclusion from stable-v4.19.284 commit 0e61a7432fcd4bca06f05b7f1c7d7cb461880fe2 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13216 CVE: CVE-2023-54186 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit d8f28269dd4bf9b55c3fb376ae31512730a96fce upstream. This patch fixes negative indexing of buf array in pin_assignment_show when get_current_pin_assignments returns 0 i.e. no compatible pin assignments are found. BUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c ... Call trace: dump_backtrace+0x110/0x204 dump_stack_lvl+0x84/0xbc print_report+0x358/0x974 kasan_report+0x9c/0xfc __do_kernel_fault+0xd4/0x2d4 do_bad_area+0x48/0x168 do_tag_check_fault+0x24/0x38 do_mem_abort+0x6c/0x14c el1_abort+0x44/0x68 el1h_64_sync_handler+0x64/0xa4 el1h_64_sync+0x78/0x7c pin_assignment_show+0x26c/0x33c dev_attr_show+0x50/0xc0 Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode") Cc: stable(a)vger.kernel.org Signed-off-by: Badhri Jagan Sridharan <badhri(a)google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/20230508214443.893436-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yin Tirui <yintirui(a)huawei.com> --- drivers/usb/typec/altmodes/displayport.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c index 90bb0baed624..3be3a1942b5f 100644 --- a/drivers/usb/typec/altmodes/displayport.c +++ b/drivers/usb/typec/altmodes/displayport.c @@ -495,6 +495,10 @@ static ssize_t pin_assignment_show(struct device *dev, mutex_unlock(&dp->lock); + /* get_current_pin_assignments can return 0 when no matching pin assignments are found */ + if (len == 0) + len++; + buf[len - 1] = '\n'; return len; } -- 2.43.0

2 1

[PATCH OLK-6.6] rcu: Protect ->defer_qs_iw_pending from data race
by Jiacheng Yu 02 Feb '26

02 Feb '26

From: "Paul E. McKenney" <paulmck(a)kernel.org> stable inclusion from stable-v6.6.103 commit b55947b725f190396f475d5d0c59aa855a4d8895 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/8987 CVE: CVE-2025-39749 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 90c09d57caeca94e6f3f87c49e96a91edd40cbfd ] On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest. In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally. The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat: ------------------------------------------------------------------------ BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0 ------------------------------------------------------------------------ The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field. This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path. Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org> Reviewed-by: Frederic Weisbecker <frederic(a)kernel.org> Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- kernel/rcu/tree_plugin.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h index 94b715139f52..de727f2568bf 100644 --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -612,10 +612,13 @@ notrace void rcu_preempt_deferred_qs(struct task_struct *t) */ static void rcu_preempt_deferred_qs_handler(struct irq_work *iwp) { + unsigned long flags; struct rcu_data *rdp; rdp = container_of(iwp, struct rcu_data, defer_qs_iw); + local_irq_save(flags); rdp->defer_qs_iw_pending = false; + local_irq_restore(flags); } /* -- 2.43.0

2 1