mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 17 participants
  • 18899 discussions
[PATCH openEuler-1.0-LTS] wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
by Zhengchao Shao 18 Apr '24

18 Apr '24
From: Zheng Wang <zyytlz.wz(a)163.com> stable inclusion from stable-v4.19.312 commit 202c503935042272e2f9e1bb549d5f69a8681169 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8DQ75 CVE: CVE-2023-47233 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0f7352557a35ab7888bc7831411ec8a3cbe20d78 ] This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. Fixes: e756af5b30b0 ("brcmfmac: add e-scan support.") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Cc: stable(a)vger.kernel.org [arend.vanspriel(a)broadcom.com: keep timer delete as is and cancel work just before free] Signed-off-by: Arend van Spriel <arend.vanspriel(a)broadcom.com> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://msgid.link/20240107072504.392713-1-arend.vanspriel@broadcom.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 4e1bd049dd06..8f2cc54836cc 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -690,8 +690,7 @@ s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info *cfg, scan_request = cfg->scan_request; cfg->scan_request = NULL; - if (timer_pending(&cfg->escan_timeout)) - del_timer_sync(&cfg->escan_timeout); + del_timer_sync(&cfg->escan_timeout); if (fw_abort) { /* Do a scan abort to stop the driver's scan engine */ @@ -7086,6 +7085,7 @@ void brcmf_cfg80211_detach(struct brcmf_cfg80211_info *cfg) wiphy_unregister(cfg->wiphy); kfree(cfg->ops); wl_deinit_priv(cfg); + cancel_work_sync(&cfg->escan_timeout_work); brcmf_free_wiphy(cfg->wiphy); kfree(cfg); } -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS] arp: Prevent overflow in arp_req_get().
by Dong Chenchen 18 Apr '24

18 Apr '24
From: Kuniyuki Iwashima <kuniyu(a)amazon.com> mainline inclusion from mainline-v6.8-rc6 commit a7d6027790acea24446ddd6632d394096c0f4667 category: bugfix bugzilla: 189771, https://gitee.com/src-openeuler/kernel/issues/I9E2MB CVE: CVE-2024-26733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller. [0]: memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK> Reported-by: syzkaller <syzkaller(a)googlegroups.com> Reported-by: Bjoern Doebel <doebel(a)amazon.de> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Link: https://lore.kernel.org/r/20240215230516.31330-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> Conflicts: net/ipv4/arp.c --- net/ipv4/arp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c index b18b2a3c54ad..fccf246e4263 100644 --- a/net/ipv4/arp.c +++ b/net/ipv4/arp.c @@ -1102,7 +1102,8 @@ static int arp_req_get(struct arpreq *r, struct net_device *dev) if (neigh) { if (!(neigh->nud_state & NUD_NOARP)) { read_lock_bh(&neigh->lock); - memcpy(r->arp_ha.sa_data, neigh->ha, dev->addr_len); + memcpy(r->arp_ha.sa_data, neigh->ha, + min(dev->addr_len, sizeof(r->arp_ha.sa_data))); r->arp_flags = arp_state_to_flags(neigh); read_unlock_bh(&neigh->lock); r->arp_ha.sa_family = dev->type; -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] net/mlx5: Update error handler for UCTX and UMEM
by Xiang Yang 18 Apr '24

18 Apr '24
From: Neta Ostrovsky <netao(a)nvidia.com> stable inclusion from stable-v5.15.5~134 commit a51a6da375d82aed5c8f83abd13e7d060421bd48 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNF8 CVE: CVE-2021-47212 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ba50cd9451f6c49cf0841c0a4a146ff6a2822699 ] In the fast unload flow, the device state is set to internal error, which indicates that the driver started the destroy process. In this case, when a destroy command is being executed, it should return MLX5_CMD_STAT_OK. Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK instead of EIO. This fixes a call trace in the umem release process - [ 2633.536695] Call Trace: [ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] [ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core] [ 2633.539641] disable_device+0x8c/0x130 [ib_core] [ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core] [ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core] [ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib] [ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary] [ 2633.544661] device_release_driver_internal+0x103/0x1f0 [ 2633.545679] bus_remove_device+0xf7/0x170 [ 2633.546640] device_del+0x181/0x410 [ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core] [ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core] [ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core] [ 2633.550864] remove_one+0x69/0xe0 [mlx5_core] [ 2633.551819] pci_device_remove+0x3b/0xc0 [ 2633.552731] device_release_driver_internal+0x103/0x1f0 [ 2633.553746] unbind_store+0xf6/0x130 [ 2633.554657] kernfs_fop_write+0x116/0x190 [ 2633.555567] vfs_write+0xa5/0x1a0 [ 2633.556407] ksys_write+0x4f/0xb0 [ 2633.557233] do_syscall_64+0x5b/0x1a0 [ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 2633.559018] RIP: 0033:0x7f9977132648 [ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 [ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648 [ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001 [ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740 [ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0 [ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c [ 2633.568725] ---[ end trace 10b4fe52945e544d ]--- conflicts: drivers/net/ethernet/mellanox/mlx5/core/cmd.c Fixes: 6a6fabbfa3e8 ("net/mlx5: Update pci error handler entries and command translation") Signed-off-by: Neta Ostrovsky <netao(a)nvidia.com> Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com> Signed-off-by: Saeed Mahameed <saeedm(a)nvidia.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c index 39c17e903915..bb1dba03de7c 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c @@ -338,6 +338,8 @@ static int mlx5_internal_err_ret_value(struct mlx5_core_dev *dev, u16 op, case MLX5_CMD_OP_DEALLOC_MEMIC: case MLX5_CMD_OP_PAGE_FAULT_RESUME: case MLX5_CMD_OP_QUERY_ESW_FUNCTIONS: + case MLX5_CMD_OP_DESTROY_UCTX: + case MLX5_CMD_OP_DESTROY_UMEM: return MLX5_CMD_STAT_OK; case MLX5_CMD_OP_QUERY_HCA_CAP: @@ -463,9 +465,7 @@ static int mlx5_internal_err_ret_value(struct mlx5_core_dev *dev, u16 op, case MLX5_CMD_OP_MODIFY_GENERAL_OBJECT: case MLX5_CMD_OP_QUERY_GENERAL_OBJECT: case MLX5_CMD_OP_CREATE_UCTX: - case MLX5_CMD_OP_DESTROY_UCTX: case MLX5_CMD_OP_CREATE_UMEM: - case MLX5_CMD_OP_DESTROY_UMEM: case MLX5_CMD_OP_ALLOC_MEMIC: case MLX5_CMD_OP_MODIFY_XRQ: case MLX5_CMD_OP_RELEASE_XRQ_ERROR: -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS 0/3] oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup
by Wupeng Ma 18 Apr '24

18 Apr '24
From: Ma Wupeng <mawupeng1(a)huawei.com> delay the OOM reaper to allow time for proper futex cleanup Ma Wupeng (1): mm: oom_kill: fix KABI broken by "oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup" Nico Pache (1): oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup Zheng Zucheng (1): sched: Allocate a new task_struct_resvd object for fork task include/linux/sched.h | 23 ++++++++++---- include/linux/sched/grid_qos.h | 2 +- init/init_task.c | 5 ++++ kernel/fork.c | 21 ++++++++++++- kernel/sched/grid/qos.c | 20 ++++++------- mm/oom_kill.c | 55 +++++++++++++++++++++++++--------- 6 files changed, 95 insertions(+), 31 deletions(-) -- 2.25.1
2 4
0 0
[PATCH OLK-6.6 v2] rseq: Add cmdline "sched_mm_cid" control mm_cid feature
by Zhang Qiao 18 Apr '24

18 Apr '24
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I9FACB -------------------------------- Signed-off-by: Zhang Qiao <zhangqiao22(a)huawei.com> --- include/linux/mm.h | 3 +++ include/linux/mm_types.h | 18 ++++++++++++++++++ kernel/sched/core.c | 32 ++++++++++++++++++++++++++++++++ kernel/sched/sched.h | 9 +++++++++ 4 files changed, 62 insertions(+) diff --git a/include/linux/mm.h b/include/linux/mm.h index 46c7b073824c..a2b8b9da8c64 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2333,6 +2333,9 @@ void sched_mm_cid_fork(struct task_struct *t); void sched_mm_cid_exit_signals(struct task_struct *t); static inline int task_mm_cid(struct task_struct *t) { + if (sched_mm_cid_enabled) + return raw_smp_processor_id(); + return t->mm_cid; } #else diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index aa17e8c500ce..d77c423ddcd2 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -1091,6 +1091,12 @@ static inline void vma_iter_init(struct vma_iterator *vmi, #ifdef CONFIG_SCHED_MM_CID +DECLARE_STATIC_KEY_FALSE(sched_mm_cid_enable); + +#ifndef sched_mm_cid_enabled +#define sched_mm_cid_enabled static_branch_unlikely(&sched_mm_cid_enable) +#endif + enum mm_cid_state { MM_CID_UNSET = -1U, /* Unset state has lazy_put flag set. */ MM_CID_LAZY_PUT = (1U << 31), @@ -1136,6 +1142,9 @@ static inline void mm_init_cid(struct mm_struct *mm) { int i; + if (sched_mm_cid_enabled) + return; + for_each_possible_cpu(i) { struct mm_cid *pcpu_cid = per_cpu_ptr(mm->pcpu_cid, i); @@ -1147,6 +1156,9 @@ static inline void mm_init_cid(struct mm_struct *mm) static inline int mm_alloc_cid(struct mm_struct *mm) { + if (sched_mm_cid_enabled) + return 0; + mm->pcpu_cid = alloc_percpu(struct mm_cid); if (!mm->pcpu_cid) return -ENOMEM; @@ -1156,12 +1168,18 @@ static inline int mm_alloc_cid(struct mm_struct *mm) static inline void mm_destroy_cid(struct mm_struct *mm) { + if (sched_mm_cid_enabled) + return; + free_percpu(mm->pcpu_cid); mm->pcpu_cid = NULL; } static inline unsigned int mm_cid_size(void) { + if (sched_mm_cid_enabled) + return 0; + return cpumask_size(); } #else /* CONFIG_SCHED_MM_CID */ diff --git a/kernel/sched/core.c b/kernel/sched/core.c index eff79d6e1e81..532231d062e8 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -12188,6 +12188,16 @@ void call_trace_sched_update_nr_running(struct rq *rq, int count) #ifdef CONFIG_SCHED_MM_CID +DEFINE_STATIC_KEY_FALSE(sched_mm_cid_enable); + +static int __init sched_mm_cid_setup(char *buf) +{ + static_branch_enable(&sched_mm_cid_enable); + + return 0; +} +early_param("sched_mm_cid", sched_mm_cid_setup); + /* * @cid_lock: Guarantee forward-progress of cid allocation. * @@ -12416,8 +12426,12 @@ void sched_mm_cid_migrate_to(struct rq *dst_rq, struct task_struct *t) lockdep_assert_rq_held(dst_rq); + if (sched_mm_cid_enabled) + return; + if (!mm) return; + src_cpu = t->migrate_from_cpu; if (src_cpu == -1) { t->last_mm_cid = -1; @@ -12614,6 +12628,9 @@ void init_sched_mm_cid(struct task_struct *t) struct mm_struct *mm = t->mm; int mm_users = 0; + if (sched_mm_cid_enabled) + return; + if (mm) { mm_users = atomic_read(&mm->mm_users); if (mm_users == 1) @@ -12628,6 +12645,9 @@ void task_tick_mm_cid(struct rq *rq, struct task_struct *curr) struct callback_head *work = &curr->cid_work; unsigned long now = jiffies; + if (sched_mm_cid_enabled) + return; + if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) || work->next != work) return; @@ -12642,6 +12662,9 @@ void sched_mm_cid_exit_signals(struct task_struct *t) struct rq_flags rf; struct rq *rq; + if (sched_mm_cid_enabled) + return; + if (!mm) return; @@ -12666,6 +12689,9 @@ void sched_mm_cid_before_execve(struct task_struct *t) struct rq_flags rf; struct rq *rq; + if (sched_mm_cid_enabled) + return; + if (!mm) return; @@ -12690,6 +12716,9 @@ void sched_mm_cid_after_execve(struct task_struct *t) struct rq_flags rf; struct rq *rq; + if (sched_mm_cid_enabled) + return; + if (!mm) return; @@ -12710,6 +12739,9 @@ void sched_mm_cid_after_execve(struct task_struct *t) void sched_mm_cid_fork(struct task_struct *t) { + if (sched_mm_cid_enabled) + return; + WARN_ON_ONCE(!t->mm || t->mm_cid != -1); t->mm_cid_active = 1; } diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index f643777adbe4..b39b7cf2583f 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -3479,6 +3479,12 @@ static inline void update_current_exec_runtime(struct task_struct *curr, #ifdef CONFIG_SCHED_MM_CID +DECLARE_STATIC_KEY_FALSE(sched_mm_cid_enable); + +#ifndef sched_mm_cid_enabled +#define sched_mm_cid_enabled static_branch_unlikely(&sched_mm_cid_enable) +#endif + #define SCHED_MM_CID_PERIOD_NS (100ULL * 1000000) /* 100ms */ #define MM_CID_SCAN_DELAY 100 /* 100ms */ @@ -3663,6 +3669,9 @@ static inline void switch_mm_cid(struct rq *rq, struct task_struct *prev, struct task_struct *next) { + if (sched_mm_cid_enabled) + return; + /* * Provide a memory barrier between rq->curr store and load of * {prev,next}->mm->pcpu_cid[cpu] on rq->curr->mm transition. -- 2.18.0.huawei.25
2 1
0 0
[PATCH openEuler-1.0-LTS] scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()
by Zheng Zucheng 18 Apr '24

18 Apr '24
From: James Smart <jsmart2021(a)gmail.com> stable inclusion from stable-v4.19.218 commit b291d147d0268e93ad866f8bc820ea14497abc9b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFI CVE: CVE-2021-47203 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 99154581b05c8fb22607afb7c3d66c1bace6aa5d ] When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation. Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption. Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure. Link: https://lore.kernel.org/r/20210910233159.115896-2-jsmart2021@gmail.com Co-developed-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: James Smart <jsmart2021(a)gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/scsi/lpfc/lpfc_sli.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index a801917d3c19..6c775a8bfb9e 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -19159,6 +19159,7 @@ lpfc_drain_txq(struct lpfc_hba *phba) fail_msg, piocbq->iotag, piocbq->sli4_xritag); list_add_tail(&piocbq->list, &completions); + fail_msg = NULL; } spin_unlock_irqrestore(&pring->ring_lock, iflags); } -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS] wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
by Zhengchao Shao 18 Apr '24

18 Apr '24
From: Zheng Wang <zyytlz.wz(a)163.com> stable inclusion from stable-v4.19.312 commit 202c503935042272e2f9e1bb549d5f69a8681169 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8DQ75 CVE: CVE-2023-47233 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0f7352557a35ab7888bc7831411ec8a3cbe20d78 ] This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. Fixes: e756af5b30b0 ("brcmfmac: add e-scan support.") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Cc: stable(a)vger.kernel.org [arend.vanspriel(a)broadcom.com: keep timer delete as is and cancel work just before free] Signed-off-by: Arend van Spriel <arend.vanspriel(a)broadcom.com> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://msgid.link/20240107072504.392713-1-arend.vanspriel@broadcom.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 4e1bd049dd06..71f70589aafc 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -690,8 +690,7 @@ s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info *cfg, scan_request = cfg->scan_request; cfg->scan_request = NULL; - if (timer_pending(&cfg->escan_timeout)) - del_timer_sync(&cfg->escan_timeout); + timer_delete_sync(&cfg->escan_timeout); if (fw_abort) { /* Do a scan abort to stop the driver's scan engine */ @@ -7086,6 +7085,7 @@ void brcmf_cfg80211_detach(struct brcmf_cfg80211_info *cfg) wiphy_unregister(cfg->wiphy); kfree(cfg->ops); wl_deinit_priv(cfg); + cancel_work_sync(&cfg->escan_timeout_work); brcmf_free_wiphy(cfg->wiphy); kfree(cfg); } -- 2.34.1
2 1
0 0
[PATCH OLK-5.10] wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
by Zhengchao Shao 18 Apr '24

18 Apr '24
From: Zheng Wang <zyytlz.wz(a)163.com> stable inclusion from stable-v5.10.215 commit bacb8c3ab86dcd760c15903fcee58169bc3026aa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8DQ75 CVE: CVE-2023-47233 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0f7352557a35ab7888bc7831411ec8a3cbe20d78 ] This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. Fixes: e756af5b30b0 ("brcmfmac: add e-scan support.") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Cc: stable(a)vger.kernel.org [arend.vanspriel(a)broadcom.com: keep timer delete as is and cancel work just before free] Signed-off-by: Arend van Spriel <arend.vanspriel(a)broadcom.com> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://msgid.link/20240107072504.392713-1-arend.vanspriel@broadcom.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index baf5f0afe802..fbb5e29530e3 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -790,8 +790,7 @@ s32 brcmf_notify_escan_complete(struct brcmf_cfg80211_info *cfg, scan_request = cfg->scan_request; cfg->scan_request = NULL; - if (timer_pending(&cfg->escan_timeout)) - del_timer_sync(&cfg->escan_timeout); + timer_delete_sync(&cfg->escan_timeout); if (fw_abort) { /* Do a scan abort to stop the driver's scan engine */ @@ -7674,6 +7673,7 @@ void brcmf_cfg80211_detach(struct brcmf_cfg80211_info *cfg) brcmf_btcoex_detach(cfg); wiphy_unregister(cfg->wiphy); wl_deinit_priv(cfg); + cancel_work_sync(&cfg->escan_timeout_work); brcmf_free_wiphy(cfg->wiphy); kfree(cfg); } -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS] usb: typec: tipd: Remove WARN_ON in tps6598x_block_read
by Ye Bin 18 Apr '24

18 Apr '24
From: Sven Peter <sven(a)svenpeter.dev> mainline inclusion from mainline-v5.16-rc1 commit b7a0a63f3fed57d413bb857de164ea9c3984bc4e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HOEF CVE: CVE-2021-47210 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Calling tps6598x_block_read with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled. Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Sven Peter <sven(a)svenpeter.dev> Link: https://lore.kernel.org/r/20210914140235.65955-3-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> conflicts: drivers/usb/typec/tps6598x.c Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/usb/typec/tps6598x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c index 987b8fcfb2aa..a4dd23a8f195 100644 --- a/drivers/usb/typec/tps6598x.c +++ b/drivers/usb/typec/tps6598x.c @@ -93,7 +93,7 @@ tps6598x_block_read(struct tps6598x *tps, u8 reg, void *val, size_t len) u8 data[TPS_MAX_LEN + 1]; int ret; - if (WARN_ON(len + 1 > sizeof(data))) + if (len + 1 > sizeof(data)) return -EINVAL; if (!tps->i2c_protocol) -- 2.31.1
2 1
0 0
[openeuler:OLK-6.6 7446/7460] shadow.c:undefined reference to `__memcpy_mc'
by kernel test robot 18 Apr '24

18 Apr '24
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 03d68844d934c811c7becd178e1297db3a65ad2b commit: b991780c836ceb9a479c6c6e385e914b487e353a [7446/7460] arm64: introduce copy_mc_to_kernel() implementation config: arm64-randconfig-003-20240418 (https://download.01.org/0day-ci/archive/20240418/202404181005.qXZ1fy0q-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240418/202404181005.qXZ1fy0q-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/202404181005.qXZ1fy0q-lkp@intel.com/ All errors (new ones prefixed by >>): aarch64-linux-ld: Unexpected GOT/PLT entries detected! aarch64-linux-ld: Unexpected run-time procedure linkages detected! aarch64-linux-ld: mm/kasan/shadow.o: in function `memcpy_mc': >> shadow.c:(.text+0x4f4): undefined reference to `__memcpy_mc' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 1142
  • 1143
  • 1144
  • 1145
  • 1146
  • 1147
  • 1148
  • ...
  • 1890
  • Older →

HyperKitty Powered by HyperKitty