- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] PNP: fix name memory leak in pnp_alloc_dev()
by Jinjiang Tu 24 Sep '25

24 Sep '25

From: Yang Yingliang <yangyingliang(a)huawei.com> stable inclusion from stable-v4.19.270 commit bbcf772216aa237036cc3ae3158288d0a95aaf4d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICY4FE CVE: CVE-2022-50278 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 110d7b0325c55ff3620073ba4201845f59e22ebf ] After commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak. Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Hanjun Guo <guohanjun(a)huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/pnp/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pnp/core.c b/drivers/pnp/core.c index 3bf18d718975..131b925b820d 100644 --- a/drivers/pnp/core.c +++ b/drivers/pnp/core.c @@ -160,14 +160,14 @@ struct pnp_dev *pnp_alloc_dev(struct pnp_protocol *protocol, int id, dev->dev.coherent_dma_mask = dev->dma_mask; dev->dev.release = &pnp_release_device; - dev_set_name(&dev->dev, "%02x:%02x", dev->protocol->number, dev->number); - dev_id = pnp_add_id(dev, pnpid); if (!dev_id) { kfree(dev); return NULL; } + dev_set_name(&dev->dev, "%02x:%02x", dev->protocol->number, dev->number); + return dev; } -- 2.43.0

2 1

[PATCH OLK-6.6 0/2] Backport fs/pipe performance optimization patches
by Zheng Zengkai 24 Sep '25

24 Sep '25

Backport some fs/pipe performance optimization patches from mainline. Max Kellermann (2): fs/pipe: remove unnecessary spinlock from pipe_write() fs/pipe: use spinlock in pipe_read() only if there is a watch_queue fs/pipe.c | 52 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 32 insertions(+), 20 deletions(-) -- 2.20.1

2 3

[PATCH openEuler-1.0-LTS] Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times
by Wang Tao 24 Sep '25

24 Sep '25

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> stable inclusion from stable-v4.19.262 commit 671fee73e08ff415d36a7c16bdf238927df83884 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICYQPG CVE: CVE-2022-50419 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 448a496f760664d3e2e79466aa1787e6abc922b5 ] device_add shall not be called multiple times as stated in its documentation: 'Do not call this routine or device_register() more than once for any device structure' Syzkaller reports a bug as follows [1]: ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> __list_add include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] kobj_kset_join lib/kobject.c:164 [inline] kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214 kobject_add_varg lib/kobject.c:358 [inline] kobject_add+0x150/0x1c0 lib/kobject.c:410 device_add+0x368/0x1e90 drivers/base/core.c:3452 hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53 hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799 hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110 hci_event_func net/bluetooth/hci_event.c:7440 [inline] hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495 hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Link: https://syzkaller.appspot.com/bug?id=da3246e2d33afdb92d66bc166a0934c5b14640… Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Tested-by: Hawkins Jiawei <yin31149(a)gmail.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- net/bluetooth/hci_sysfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c index b69d88b88d2e..ccd2c377bf83 100644 --- a/net/bluetooth/hci_sysfs.c +++ b/net/bluetooth/hci_sysfs.c @@ -48,6 +48,9 @@ void hci_conn_add_sysfs(struct hci_conn *conn) BT_DBG("conn %p", conn); + if (device_is_registered(&conn->dev)) + return; + dev_set_name(&conn->dev, "%s:%d", hdev->name, conn->handle); if (device_add(&conn->dev) < 0) { -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] sched/core: Fix potential deadlock on rq lock
by Wang Tao 24 Sep '25

24 Sep '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICY8BJ ------------------ When CPU 1 enters the nohz_full state, and the kworker on CPU 0 executes the function sched_tick_remote, holding the lock on CPU1's rq and triggering the warning WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3). This leads to the process of printing the warning message, where the console_sem semaphore is held. At this point, the print task on the CPU1's rq cannot acquire the console_sem and joins the wait queue, entering the UNINTERRUPTIBLE state. It waits for the console_sem to be released and then wakes up. After the task on CPU 0 releases the console_sem, it wakes up the waiting console_sem task. In try_to_wake_up, it attempts to acquire the lock on CPU1's rq again, resulting in a deadlock. The triggering scenario is as follows: CPU0 CPU1 ---- ---- sched_tick_remote WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3) report_bug con_write printk console_unlock do_con_write console_lock down(&console_sem) list_add_tail(&waiter.list, &sem->wait_list); up(&console_sem) wake_up_q(&wake_q) try_to_wake_up __task_rq_lock _raw_spin_lock This patch fixes the issue by deffering all printk console printing during the lock holding period. Fixes: d84b31313ef8 ("sched/isolation: Offload residual 1Hz scheduler tick") Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- kernel/sched/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7515d8f77194..4149f554debd 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3148,6 +3148,7 @@ static void sched_tick_remote(struct work_struct *work) goto out_unlock; update_rq_clock(rq); + printk_deferred_enter(); delta = rq_clock_task(rq) - curr->se.exec_start; /* @@ -3155,6 +3156,7 @@ static void sched_tick_remote(struct work_struct *work) * amount of time. */ WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3); + printk_deferred_exit(); curr->sched_class->task_tick(rq, curr, 0); out_unlock: -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] sched/core: Fix potential deadlock on rq lock
by Wang Tao 24 Sep '25

24 Sep '25

Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICY8BJ ------------------ When CPU 1 enters the nohz_full state, and the kworker on CPU 0 executes the function sched_tick_remote, holding the lock on CPU1's rq and triggering the warning WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3). This leads to the process of printing the warning message, where the console_sem semaphore is held. At this point, the print task on the CPU1's rq cannot acquire the console_sem and joins the wait queue, entering the UNINTERRUPTIBLE state. It waits for the console_sem to be released and then wakes up. After the task on CPU 0 releases the console_sem, it wakes up the waiting console_sem task. In try_to_wake_up, it attempts to acquire the lock on CPU1's rq again, resulting in a deadlock. The triggering scenario is as follows: CPU0 CPU1 ---- ---- sched_tick_remote WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3) report_bug con_write printk console_unlock do_con_write console_lock down(&console_sem) list_add_tail(&waiter.list, &sem->wait_list); up(&console_sem) wake_up_q(&wake_q) try_to_wake_up __task_rq_lock _raw_spin_lock This patch fixes the issue by deffering all printk console printing during the lock holding period. Fixes: d84b31313ef8 ("sched/isolation: Offload residual 1Hz scheduler tick") Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- kernel/sched/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7515d8f77194..4149f554debd 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3148,6 +3148,7 @@ static void sched_tick_remote(struct work_struct *work) goto out_unlock; update_rq_clock(rq); + printk_deferred_enter(); delta = rq_clock_task(rq) - curr->se.exec_start; /* @@ -3155,6 +3156,7 @@ static void sched_tick_remote(struct work_struct *work) * amount of time. */ WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3); + printk_deferred_exit(); curr->sched_class->task_tick(rq, curr, 0); out_unlock: -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] ALSA: hda: Fix Oops by 9.1 surround channel names
by Wang Tao 24 Sep '25

24 Sep '25

From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v4.19.284 commit b5694aae4c2d9a288bafce7d38f122769e0428e6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICYQFY CVE: CVE-2023-53400 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 3b44ec8c5c44790a82f07e90db45643c762878c6 upstream. get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec. As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check. Reported-by: Olliver Schinagl <oliver(a)schinagl.nl> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/64d95eb0-dbdb-cff8-a8b1-988dc22b24cd@schinagl.nl Link: https://lore.kernel.org/r/20230516184412.24078-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- sound/pci/hda/hda_generic.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 2609161707a4..142570fb0ca3 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -1159,8 +1159,8 @@ static bool path_has_mixer(struct hda_codec *codec, int path_idx, int ctl_type) return path && path->ctls[ctl_type]; } -static const char * const channel_name[4] = { - "Front", "Surround", "CLFE", "Side" +static const char * const channel_name[] = { + "Front", "Surround", "CLFE", "Side", "Back", }; /* give some appropriate ctl name prefix for the given line out channel */ @@ -1186,7 +1186,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, /* multi-io channels */ if (ch >= cfg->line_outs) - return channel_name[ch]; + goto fixed_name; switch (cfg->line_out_type) { case AUTO_PIN_SPEAKER_OUT: @@ -1232,6 +1232,7 @@ static const char *get_line_out_pfx(struct hda_codec *codec, int ch, if (cfg->line_outs == 1 && !spec->multi_ios) return "Line Out"; + fixed_name: if (ch >= ARRAY_SIZE(channel_name)) { snd_BUG(); return "PCM"; -- 2.34.1

2 1

[PATCH OLK-5.10] VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF
by Zicheng Qu 24 Sep '25

24 Sep '25

From: George Kennedy <george.kennedy(a)oracle.com> stable inclusion from stable-v5.10.240 commit d4198f67e7556b1507f14f60d81a72660e5560e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICY4GZ CVE: CVE-2023-53259 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 1a726cb47fd204109c767409fa9ca15a96328f14 ] The call to get_user_pages_fast() in vmci_host_setup_notify() can return NULL context->notify_page causing a GPF. To avoid GPF check if context->notify_page == NULL and return error if so. general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307] CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0 Call Trace: <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: a1d88436d53a ("VMCI: Fix two UVA mapping bugs") Reported-by: syzkaller <syzkaller(a)googlegroups.com> Signed-off-by: George Kennedy <george.kennedy(a)oracle.com> Reviewed-by: Vishnu Dasa <vdasa(a)vmware.com> Link: https://lore.kernel.org/r/1669666705-24012-1-git-send-email-george.kennedy@… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Stable-dep-of: 1bd6406fb5f3 ("VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify") Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- drivers/misc/vmw_vmci/vmci_host.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/misc/vmw_vmci/vmci_host.c b/drivers/misc/vmw_vmci/vmci_host.c index 4a903770b8e1..cc6da9e5a542 100644 --- a/drivers/misc/vmw_vmci/vmci_host.c +++ b/drivers/misc/vmw_vmci/vmci_host.c @@ -248,6 +248,8 @@ static int vmci_host_setup_notify(struct vmci_ctx *context, context->notify_page = NULL; return VMCI_ERROR_GENERIC; } + if (context->notify_page == NULL) + return VMCI_ERROR_UNAVAILABLE; /* * Map the locked page and set up notify pointer. -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF
by Zicheng Qu 24 Sep '25

24 Sep '25

From: George Kennedy <george.kennedy(a)oracle.com> mainline inclusion from mainline-v6.3-rc1 commit 1a726cb47fd204109c767409fa9ca15a96328f14 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICY4GZ CVE: CVE-2023-53259 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The call to get_user_pages_fast() in vmci_host_setup_notify() can return NULL context->notify_page causing a GPF. To avoid GPF check if context->notify_page == NULL and return error if so. general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307] CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0 Call Trace: <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: a1d88436d53a ("VMCI: Fix two UVA mapping bugs") Reported-by: syzkaller <syzkaller(a)googlegroups.com> Signed-off-by: George Kennedy <george.kennedy(a)oracle.com> Reviewed-by: Vishnu Dasa <vdasa(a)vmware.com> Link: https://lore.kernel.org/r/1669666705-24012-1-git-send-email-george.kennedy@… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/misc/vmw_vmci/vmci_host.c [Conflict due to the 3rd parameter in get_user_pages_fast, ignore this context difference.] Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- drivers/misc/vmw_vmci/vmci_host.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/misc/vmw_vmci/vmci_host.c b/drivers/misc/vmw_vmci/vmci_host.c index cdd326cc9cb9..b4bf9c2ea35d 100644 --- a/drivers/misc/vmw_vmci/vmci_host.c +++ b/drivers/misc/vmw_vmci/vmci_host.c @@ -248,6 +248,8 @@ static int vmci_host_setup_notify(struct vmci_ctx *context, context->notify_page = NULL; return VMCI_ERROR_GENERIC; } + if (context->notify_page == NULL) + return VMCI_ERROR_UNAVAILABLE; /* * Map the locked page and set up notify pointer. -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] sched/fair: Don't balance task to its current running CPU
by Zicheng Qu 24 Sep '25

24 Sep '25

From: Yicong Yang <yangyicong(a)hisilicon.com> stable inclusion from stable-v4.19.291 commit a5286f4655ce2fa28f477c0b957ea7f323fe2fab category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICY4I1 CVE: CVE-2023-53215 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0dd37d6dd33a9c23351e6115ae8cdac7863bc7de ] We've run into the case that the balancer tries to balance a migration disabled task and trigger the warning in set_task_cpu() like below: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : set_task_cpu+0x188/0x240 lr : load_balance+0x5d0/0xc60 sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace: set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380 _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x6c/0x80 __do_softirq+0x128/0x3d8 ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0 cpu_startup_entry+0x30/0x3c secondary_start_kernel+0x14c/0x190 __secondary_switched+0xb0/0xb4 ---[ end trace 0000000000000000 ]--- Further investigation shows that the warning is superfluous, the migration disabled task is just going to be migrated to its current running CPU. This is because that on load balance if the dst_cpu is not allowed by the task, we'll re-select a new_dst_cpu as a candidate. If no task can be balanced to dst_cpu we'll try to balance the task to the new_dst_cpu instead. In this case when the migration disabled task is not on CPU it only allows to run on its current CPU, load balance will select its current CPU as new_dst_cpu and later triggers the warning above. The new_dst_cpu is chosen from the env->dst_grpmask. Currently it contains CPUs in sched_group_span() and if we have overlapped groups it's possible to run into this case. This patch makes env->dst_grpmask of group_balance_mask() which exclude any CPUs from the busiest group and solve the issue. For balancing in a domain with no overlapped groups the behaviour keeps same as before. Suggested-by: Vincent Guittot <vincent.guittot(a)linaro.org> Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Vincent Guittot <vincent.guittot(a)linaro.org> Link: https://lore.kernel.org/r/20230530082507.10444-1-yangyicong@huawei.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 87f905bfcf3e..b889e4910c26 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9911,7 +9911,7 @@ static int load_balance(int this_cpu, struct rq *this_rq, .sd = sd, .dst_cpu = this_cpu, .dst_rq = this_rq, - .dst_grpmask = sched_group_span(sd->groups), + .dst_grpmask = group_balance_mask(sd->groups), .idle = idle, .loop_break = sched_nr_migrate_break, .cpus = cpus, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] wifi: ath9k: verify the expected usb_endpoints are present
by Yao Kai 24 Sep '25

24 Sep '25

From: Fedor Pchelkin <pchelkin(a)ispras.ru> stable inclusion from stable-v4.19.325 commit d64436af0bc3c9e579be761d7684f228fb95f3bb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICY4B9 CVE: CVE-2022-50297 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 16ef02bad239f11f322df8425d302be62f0443ce ] The bug arises when a USB device claims to be an ATH9K but doesn't have the expected endpoints. (In this case there was an interrupt endpoint where the driver expected a bulk endpoint.) The kernel needs to be able to handle such devices without getting an internal error. usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Modules linked in: CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events request_firmware_work_func RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493 Call Trace: ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline] ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019 ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline] ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242 request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097 process_one_work+0x9af/0x1600 kernel/workqueue.c:2279 worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425 kthread+0x3b4/0x4a0 kernel/kthread.c:313 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Suggested-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://lore.kernel.org/r/20221008211532.74583-1-pchelkin@ispras.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yao Kai <yaokai34(a)huawei.com> --- drivers/net/wireless/ath/ath9k/hif_usb.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index fb649d85b8fc..d4bab8e9e2fa 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -1271,10 +1271,24 @@ static int send_eject_command(struct usb_interface *interface) static int ath9k_hif_usb_probe(struct usb_interface *interface, const struct usb_device_id *id) { + struct usb_endpoint_descriptor *bulk_in, *bulk_out, *int_in, *int_out; struct usb_device *udev = interface_to_usbdev(interface); + struct usb_host_interface *alt; struct hif_device_usb *hif_dev; int ret = 0; + /* Verify the expected endpoints are present */ + alt = interface->cur_altsetting; + if (usb_find_common_endpoints(alt, &bulk_in, &bulk_out, &int_in, &int_out) < 0 || + usb_endpoint_num(bulk_in) != USB_WLAN_RX_PIPE || + usb_endpoint_num(bulk_out) != USB_WLAN_TX_PIPE || + usb_endpoint_num(int_in) != USB_REG_IN_PIPE || + usb_endpoint_num(int_out) != USB_REG_OUT_PIPE) { + dev_err(&udev->dev, + "ath9k_htc: Device endpoint numbers are not the expected ones\n"); + return -ENODEV; + } + if (id->driver_info == STORAGE_DEVICE) return send_eject_command(interface); -- 2.43.0

2 1