- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1 0/3] fix CVE-2024-41007
by Zhengchao Shao 22 Jul '24

22 Jul '24

Fix CVE-2024-41007 Eric Dumazet (2): tcp: use signed arithmetic in tcp_rtx_probe0_timed_out() tcp: avoid too many retransmit packets Menglong Dong (1): net: tcp: fix unexcepted socket die when snd_wnd is 0 net/ipv4/tcp_timer.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) -- 2.34.1

2 4

[PATCH OLK-6.6] [Backport] fpga: bridge: add owner module and take its refcount
by Wupeng Ma 22 Jul '24

22 Jul '24

From: Marco Pagani <marpagan(a)redhat.com> stable inclusion from stable-v6.6.33 commit d7c4081c54a1d4068de9440957303a76f9e5c95b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA74DQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1da11f822042eb6ef4b6064dc048f157a7852529 ] The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge. Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions. Fixes: 21aeda950c5f ("fpga: add fpga bridge framework") Suggested-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Suggested-by: Xu Yilun <yilun.xu(a)intel.com> Reviewed-by: Russ Weight <russ.weight(a)linux.dev> Signed-off-by: Marco Pagani <marpagan(a)redhat.com> Acked-by: Xu Yilun <yilun.xu(a)intel.com> Link: https://lore.kernel.org/r/20240322171839.233864-1-marpagan@redhat.com Signed-off-by: Xu Yilun <yilun.xu(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> --- Documentation/driver-api/fpga/fpga-bridge.rst | 7 ++- drivers/fpga/fpga-bridge.c | 57 ++++++++++--------- include/linux/fpga/fpga-bridge.h | 10 +++- 3 files changed, 43 insertions(+), 31 deletions(-) diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index 604208534095..833f68fb0700 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -6,9 +6,12 @@ API to implement a new FPGA bridge * struct fpga_bridge - The FPGA Bridge structure * struct fpga_bridge_ops - Low level Bridge driver ops -* fpga_bridge_register() - Create and register a bridge +* __fpga_bridge_register() - Create and register a bridge * fpga_bridge_unregister() - Unregister a bridge +The helper macro ``fpga_bridge_register()`` automatically sets +the module that registers the FPGA bridge as the owner. + .. kernel-doc:: include/linux/fpga/fpga-bridge.h :functions: fpga_bridge @@ -16,7 +19,7 @@ API to implement a new FPGA bridge :functions: fpga_bridge_ops .. kernel-doc:: drivers/fpga/fpga-bridge.c - :functions: fpga_bridge_register + :functions: __fpga_bridge_register .. kernel-doc:: drivers/fpga/fpga-bridge.c :functions: fpga_bridge_unregister diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c index a024be2b84e2..83d35fbb8245 100644 --- a/drivers/fpga/fpga-bridge.c +++ b/drivers/fpga/fpga-bridge.c @@ -55,33 +55,26 @@ int fpga_bridge_disable(struct fpga_bridge *bridge) } EXPORT_SYMBOL_GPL(fpga_bridge_disable); -static struct fpga_bridge *__fpga_bridge_get(struct device *dev, +static struct fpga_bridge *__fpga_bridge_get(struct device *bridge_dev, struct fpga_image_info *info) { struct fpga_bridge *bridge; - int ret = -ENODEV; - bridge = to_fpga_bridge(dev); + bridge = to_fpga_bridge(bridge_dev); bridge->info = info; - if (!mutex_trylock(&bridge->mutex)) { - ret = -EBUSY; - goto err_dev; - } + if (!mutex_trylock(&bridge->mutex)) + return ERR_PTR(-EBUSY); - if (!try_module_get(dev->parent->driver->owner)) - goto err_ll_mod; + if (!try_module_get(bridge->br_ops_owner)) { + mutex_unlock(&bridge->mutex); + return ERR_PTR(-ENODEV); + } dev_dbg(&bridge->dev, "get\n"); return bridge; - -err_ll_mod: - mutex_unlock(&bridge->mutex); -err_dev: - put_device(dev); - return ERR_PTR(ret); } /** @@ -98,13 +91,18 @@ static struct fpga_bridge *__fpga_bridge_get(struct device *dev, struct fpga_bridge *of_fpga_bridge_get(struct device_node *np, struct fpga_image_info *info) { - struct device *dev; + struct fpga_bridge *bridge; + struct device *bridge_dev; - dev = class_find_device_by_of_node(&fpga_bridge_class, np); - if (!dev) + bridge_dev = class_find_device_by_of_node(&fpga_bridge_class, np); + if (!bridge_dev) return ERR_PTR(-ENODEV); - return __fpga_bridge_get(dev, info); + bridge = __fpga_bridge_get(bridge_dev, info); + if (IS_ERR(bridge)) + put_device(bridge_dev); + + return bridge; } EXPORT_SYMBOL_GPL(of_fpga_bridge_get); @@ -125,6 +123,7 @@ static int fpga_bridge_dev_match(struct device *dev, const void *data) struct fpga_bridge *fpga_bridge_get(struct device *dev, struct fpga_image_info *info) { + struct fpga_bridge *bridge; struct device *bridge_dev; bridge_dev = class_find_device(&fpga_bridge_class, NULL, dev, @@ -132,7 +131,11 @@ struct fpga_bridge *fpga_bridge_get(struct device *dev, if (!bridge_dev) return ERR_PTR(-ENODEV); - return __fpga_bridge_get(bridge_dev, info); + bridge = __fpga_bridge_get(bridge_dev, info); + if (IS_ERR(bridge)) + put_device(bridge_dev); + + return bridge; } EXPORT_SYMBOL_GPL(fpga_bridge_get); @@ -146,7 +149,7 @@ void fpga_bridge_put(struct fpga_bridge *bridge) dev_dbg(&bridge->dev, "put\n"); bridge->info = NULL; - module_put(bridge->dev.parent->driver->owner); + module_put(bridge->br_ops_owner); mutex_unlock(&bridge->mutex); put_device(&bridge->dev); } @@ -316,18 +319,19 @@ static struct attribute *fpga_bridge_attrs[] = { ATTRIBUTE_GROUPS(fpga_bridge); /** - * fpga_bridge_register - create and register an FPGA Bridge device + * __fpga_bridge_register - create and register an FPGA Bridge device * @parent: FPGA bridge device from pdev * @name: FPGA bridge name * @br_ops: pointer to structure of fpga bridge ops * @priv: FPGA bridge private data + * @owner: owner module containing the br_ops * * Return: struct fpga_bridge pointer or ERR_PTR() */ struct fpga_bridge * -fpga_bridge_register(struct device *parent, const char *name, - const struct fpga_bridge_ops *br_ops, - void *priv) +__fpga_bridge_register(struct device *parent, const char *name, + const struct fpga_bridge_ops *br_ops, + void *priv, struct module *owner) { struct fpga_bridge *bridge; int id, ret; @@ -357,6 +361,7 @@ fpga_bridge_register(struct device *parent, const char *name, bridge->name = name; bridge->br_ops = br_ops; + bridge->br_ops_owner = owner; bridge->priv = priv; bridge->dev.groups = br_ops->groups; @@ -386,7 +391,7 @@ fpga_bridge_register(struct device *parent, const char *name, return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(fpga_bridge_register); +EXPORT_SYMBOL_GPL(__fpga_bridge_register); /** * fpga_bridge_unregister - unregister an FPGA bridge diff --git a/include/linux/fpga/fpga-bridge.h b/include/linux/fpga/fpga-bridge.h index 223da48a6d18..94c4edd047e5 100644 --- a/include/linux/fpga/fpga-bridge.h +++ b/include/linux/fpga/fpga-bridge.h @@ -45,6 +45,7 @@ struct fpga_bridge_info { * @dev: FPGA bridge device * @mutex: enforces exclusive reference to bridge * @br_ops: pointer to struct of FPGA bridge ops + * @br_ops_owner: module containing the br_ops * @info: fpga image specific information * @node: FPGA bridge list node * @priv: low level driver private date @@ -54,6 +55,7 @@ struct fpga_bridge { struct device dev; struct mutex mutex; /* for exclusive reference to bridge */ const struct fpga_bridge_ops *br_ops; + struct module *br_ops_owner; struct fpga_image_info *info; struct list_head node; void *priv; @@ -79,10 +81,12 @@ int of_fpga_bridge_get_to_list(struct device_node *np, struct fpga_image_info *info, struct list_head *bridge_list); +#define fpga_bridge_register(parent, name, br_ops, priv) \ + __fpga_bridge_register(parent, name, br_ops, priv, THIS_MODULE) struct fpga_bridge * -fpga_bridge_register(struct device *parent, const char *name, - const struct fpga_bridge_ops *br_ops, - void *priv); +__fpga_bridge_register(struct device *parent, const char *name, + const struct fpga_bridge_ops *br_ops, void *priv, + struct module *owner); void fpga_bridge_unregister(struct fpga_bridge *br); #endif /* _LINUX_FPGA_BRIDGE_H */ -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] fix CVE-2024-41007
by Zhengchao Shao 22 Jul '24

22 Jul '24

Fix CVE-2024-41007 Eric Dumazet (2): tcp: use signed arithmetic in tcp_rtx_probe0_timed_out() tcp: avoid too many retransmit packets net/ipv4/tcp_timer.c | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/2] fix CVE-2024-41007
by Zhengchao Shao 22 Jul '24

22 Jul '24

Fix CVE-2024-41007. Eric Dumazet (2): tcp: use signed arithmetic in tcp_rtx_probe0_timed_out() tcp: avoid too many retransmit packets net/ipv4/tcp_timer.c | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1] ima: Fix use-after-free on a dentry's dname.name
by GONG, Ruiqi 22 Jul '24

22 Jul '24

From: Stefan Berger <stefanb(a)linux.ibm.com> mainline inclusion from mainline-v6.10-rc1 commit be84f32bb2c981ca670922e047cdde1488b233de category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0O1 CVE: CVE-2024-39494 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead. Link: https://lore.kernel.org/all/20240202182732.GE2087318@ZenIV/ Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Stefan Berger <stefanb(a)linux.ibm.com> Signed-off-by: Mimi Zohar <zohar(a)linux.ibm.com> Conflicts: security/integrity/ima/ima_api.c [Just context conflicts.] Signed-off-by: GONG, Ruiqi <gongruiqi1(a)huawei.com> --- security/integrity/ima/ima_api.c | 16 ++++++++++++---- security/integrity/ima/ima_template_lib.c | 17 ++++++++++++++--- 2 files changed, 26 insertions(+), 7 deletions(-) diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c index 6ecaf6834844..d383b47c2d5e 100644 --- a/security/integrity/ima/ima_api.c +++ b/security/integrity/ima/ima_api.c @@ -234,7 +234,7 @@ int ima_collect_measurement(struct integrity_iint_cache *iint, { const char *audit_cause = "failed"; struct inode *inode = file_inode(file); - const char *filename = file->f_path.dentry->d_name.name; + struct name_snapshot filename; int result = 0; int length; void *tmpbuf; @@ -293,9 +293,13 @@ int ima_collect_measurement(struct integrity_iint_cache *iint, if (file->f_flags & O_DIRECT) audit_cause = "failed(directio)"; + take_dentry_name_snapshot(&filename, file->f_path.dentry); + integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, - filename, "collect_data", audit_cause, - result, 0); + filename.name.name, "collect_data", + audit_cause, result, 0); + + release_dentry_name_snapshot(&filename); } return result; } @@ -416,6 +420,7 @@ void ima_audit_measurement(struct integrity_iint_cache *iint, */ const char *ima_d_path(const struct path *path, char **pathbuf, char *namebuf) { + struct name_snapshot filename; char *pathname = NULL; *pathbuf = __getname(); @@ -429,7 +434,10 @@ const char *ima_d_path(const struct path *path, char **pathbuf, char *namebuf) } if (!pathname) { - strlcpy(namebuf, path->dentry->d_name.name, NAME_MAX); + take_dentry_name_snapshot(&filename, path->dentry); + strscpy(namebuf, filename.name.name, NAME_MAX); + release_dentry_name_snapshot(&filename); + pathname = namebuf; } diff --git a/security/integrity/ima/ima_template_lib.c b/security/integrity/ima/ima_template_lib.c index 90040fac150b..d49eeb9c87c7 100644 --- a/security/integrity/ima/ima_template_lib.c +++ b/security/integrity/ima/ima_template_lib.c @@ -386,7 +386,10 @@ static int ima_eventname_init_common(struct ima_event_data *event_data, bool size_limit) { const char *cur_filename = NULL; + struct name_snapshot filename; u32 cur_filename_len = 0; + bool snapshot = false; + int ret; BUG_ON(event_data->filename == NULL && event_data->file == NULL); @@ -399,7 +402,10 @@ static int ima_eventname_init_common(struct ima_event_data *event_data, } if (event_data->file) { - cur_filename = event_data->file->f_path.dentry->d_name.name; + take_dentry_name_snapshot(&filename, + event_data->file->f_path.dentry); + snapshot = true; + cur_filename = filename.name.name; cur_filename_len = strlen(cur_filename); } else /* @@ -408,8 +414,13 @@ static int ima_eventname_init_common(struct ima_event_data *event_data, */ cur_filename_len = IMA_EVENT_NAME_LEN_MAX; out: - return ima_write_template_field_data(cur_filename, cur_filename_len, - DATA_FMT_STRING, field_data); + ret = ima_write_template_field_data(cur_filename, cur_filename_len, + DATA_FMT_STRING, field_data); + + if (snapshot) + release_dentry_name_snapshot(&filename); + + return ret; } /* -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] staging: gdm724x: fix use after free in gdm_lte_rx()
by Zheng Zucheng 21 Jul '24

21 Jul '24

From: Dan Carpenter <dan.carpenter(a)oracle.com> stable inclusion from stable-v5.10.106 commit 6d9700b445098dbbce0caff4b8cfca214cf1e757 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADGSJ CVE: CVE-2022-48851 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit fc7f750dc9d102c1ed7bbe4591f991e770c99033 upstream. The netif_rx_ni() function frees the skb so we can't dereference it to save the skb->len. Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver") Cc: stable <stable(a)vger.kernel.org> Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Link: https://lore.kernel.org/r/20220228074331.GA13685@kili Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/staging/gdm724x/gdm_lte.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/gdm724x/gdm_lte.c b/drivers/staging/gdm724x/gdm_lte.c index 3c2aab7a921e..fc64d3fed8b4 100644 --- a/drivers/staging/gdm724x/gdm_lte.c +++ b/drivers/staging/gdm724x/gdm_lte.c @@ -76,14 +76,15 @@ static void tx_complete(void *arg) static int gdm_lte_rx(struct sk_buff *skb, struct nic *nic, int nic_type) { - int ret; + int ret, len; + len = skb->len + ETH_HLEN; ret = netif_rx_ni(skb); if (ret == NET_RX_DROP) { nic->stats.rx_dropped++; } else { nic->stats.rx_packets++; - nic->stats.rx_bytes += skb->len + ETH_HLEN; + nic->stats.rx_bytes += len; } return 0; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 3e36513da2c9286f7809293f49e229bb822dec55
by kernel test robot 21 Jul '24

21 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 3e36513da2c9286f7809293f49e229bb822dec55 !10137 NFSD: Fix ia_size underflow elapsed time: 727m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240720 gcc-14.1.0 arm64 randconfig-002-20240720 gcc-14.1.0 arm64 randconfig-003-20240720 gcc-14.1.0 arm64 randconfig-004-20240720 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240720 clang-18 x86_64 buildonly-randconfig-002-20240720 gcc-13 x86_64 buildonly-randconfig-003-20240720 clang-18 x86_64 buildonly-randconfig-004-20240720 clang-18 x86_64 buildonly-randconfig-005-20240720 gcc-13 x86_64 buildonly-randconfig-006-20240720 gcc-13 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240720 clang-18 x86_64 randconfig-002-20240720 gcc-13 x86_64 randconfig-003-20240720 clang-18 x86_64 randconfig-004-20240720 clang-18 x86_64 randconfig-005-20240720 clang-18 x86_64 randconfig-006-20240720 gcc-13 x86_64 randconfig-011-20240720 gcc-13 x86_64 randconfig-012-20240720 clang-18 x86_64 randconfig-013-20240720 gcc-13 x86_64 randconfig-014-20240720 clang-18 x86_64 randconfig-015-20240720 gcc-13 x86_64 randconfig-016-20240720 gcc-13 x86_64 randconfig-071-20240720 clang-18 x86_64 randconfig-072-20240720 gcc-13 x86_64 randconfig-073-20240720 gcc-13 x86_64 randconfig-074-20240720 gcc-9 x86_64 randconfig-075-20240720 gcc-13 x86_64 randconfig-076-20240720 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6] BUILD REGRESSION 0cb6baf8db0ebcae5f155083f70760b040c66655
by kernel test robot 21 Jul '24

21 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: 0cb6baf8db0ebcae5f155083f70760b040c66655 !10219 CVE-2024-35931 Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag |-- arm64-randconfig-001-20240720 | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- loongarch-allmodconfig | `-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument |-- loongarch-randconfig-001-20240720 | `-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument |-- loongarch-randconfig-002-20240720 | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- x86_64-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_topology.c:warning:stack-frame-size-()-exceeds-limit-()-in-kfd_topology_add_device |-- x86_64-randconfig-072-20240720 | |-- arch-x86-kvm-svm-sev.c:error:lvalue-required-as-unary-operand | `-- arch-x86-kvm-svm-sev.c:error:struct-hygon_kvm_hooks_table-has-no-member-named-false `-- x86_64-randconfig-073-20240720 |-- arch-x86-kvm-svm-sev.c:error:lvalue-required-as-unary-operand `-- arch-x86-kvm-svm-sev.c:error:struct-hygon_kvm_hooks_table-has-no-member-named-false elapsed time: 721m configs tested: 38 configs skipped: 124 tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240720 gcc-14.1.0 arm64 randconfig-002-20240720 clang-17 arm64 randconfig-003-20240720 gcc-14.1.0 arm64 randconfig-004-20240720 clang-19 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch randconfig-001-20240720 gcc-14.1.0 loongarch randconfig-002-20240720 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240720 clang-18 x86_64 buildonly-randconfig-002-20240720 gcc-13 x86_64 buildonly-randconfig-003-20240720 clang-18 x86_64 buildonly-randconfig-004-20240720 clang-18 x86_64 buildonly-randconfig-005-20240720 gcc-13 x86_64 buildonly-randconfig-006-20240720 gcc-13 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240720 clang-18 x86_64 randconfig-002-20240720 gcc-13 x86_64 randconfig-003-20240720 clang-18 x86_64 randconfig-004-20240720 clang-18 x86_64 randconfig-005-20240720 clang-18 x86_64 randconfig-006-20240720 gcc-13 x86_64 randconfig-011-20240720 gcc-13 x86_64 randconfig-012-20240720 clang-18 x86_64 randconfig-013-20240720 gcc-13 x86_64 randconfig-014-20240720 clang-18 x86_64 randconfig-015-20240720 gcc-13 x86_64 randconfig-016-20240720 gcc-13 x86_64 randconfig-071-20240720 clang-18 x86_64 randconfig-072-20240720 gcc-13 x86_64 randconfig-073-20240720 gcc-13 x86_64 randconfig-074-20240720 gcc-9 x86_64 randconfig-075-20240720 gcc-13 x86_64 randconfig-076-20240720 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10] BUILD SUCCESS 3af93aaba7a41d14c705c3d5511e2b5313157be7
by kernel test robot 20 Jul '24

20 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 3af93aaba7a41d14c705c3d5511e2b5313157be7 !10135 ALSA: timer: Set lower bound of start tick time elapsed time: 726m configs tested: 34 configs skipped: 127 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240720 gcc-14.1.0 arm64 randconfig-002-20240720 clang-17 arm64 randconfig-003-20240720 gcc-14.1.0 arm64 randconfig-004-20240720 clang-19 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240720 clang-18 x86_64 buildonly-randconfig-002-20240720 gcc-13 x86_64 buildonly-randconfig-003-20240720 clang-18 x86_64 buildonly-randconfig-004-20240720 clang-18 x86_64 buildonly-randconfig-005-20240720 gcc-13 x86_64 buildonly-randconfig-006-20240720 gcc-13 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240720 clang-18 x86_64 randconfig-002-20240720 gcc-13 x86_64 randconfig-003-20240720 clang-18 x86_64 randconfig-004-20240720 clang-18 x86_64 randconfig-005-20240720 clang-18 x86_64 randconfig-006-20240720 gcc-13 x86_64 randconfig-011-20240720 gcc-13 x86_64 randconfig-012-20240720 clang-18 x86_64 randconfig-013-20240720 gcc-13 x86_64 randconfig-014-20240720 clang-18 x86_64 randconfig-015-20240720 gcc-13 x86_64 randconfig-016-20240720 gcc-13 x86_64 randconfig-071-20240720 clang-18 x86_64 randconfig-072-20240720 gcc-13 x86_64 randconfig-073-20240720 gcc-13 x86_64 randconfig-074-20240720 gcc-9 x86_64 randconfig-075-20240720 gcc-13 x86_64 randconfig-076-20240720 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] PCI/ROM: Fix PCI ROM header check bug
by liwei 20 Jul '24

20 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAEAGS -------------------------------- In UEFI Specification Version 2.8, describes that the PCIR data structure must start on a 4-byte boundary. Add checks to prevent vulnerabilities. Fixes: d7ad2254fa7c ("[IA64] SN: Correct ROM resource length for BIOS copy") Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/pci/rom.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index e18d3a4383ba..0fa6b3da63cc 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -98,6 +98,12 @@ static size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, } /* get the PCI data structure and check its "PCIR" signature */ pds = image + readw(image + 24); + /* The PCIR data structure must begin on a 4-byte boundary */ + if (!IS_ALIGNED((unsigned long)pds, 4)) { + pci_info(pdev, "Invalid PCI ROM header signature: PCIR %#06x\n", + readw(image + 24)); + break; + } if (readl(pds) != 0x52494350) { pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n", readl(pds)); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] MIPS: smp: fill in sibling and core maps earlier
by liwei 20 Jul '24

20 Jul '24

From: Alexander Lobakin <alobakin(a)pm.me> mainline inclusion from mainline-v5.17-rc7 commit f2703def339c793674010cc9f01bfe4980231808 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADGS6 CVE: CVE-2022-48845 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following: [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) [ 0.048183] ------------[ cut here ]------------ [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [ 0.048220] Modules linked in: [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000 [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... [ 0.048396] Call Trace: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] start_secondary+0xbc/0x280 [ 0.048539] [ 0.048543] ---[ end trace 0000000000000000 ]--- [ 0.048636] Synchronize counters for CPU 1: done. ...for each but CPU 0/boot. Basic debug printks right before the mentioned line say: [ 0.048170] CPU: 1, smt_mask: So smt_mask, which is sibling mask obviously, is empty when entering the function. This is critical, as sched_core_cpu_starting() calculates core-scheduling parameters only once per CPU start, and it's crucial to have all the parameters filled in at that moment (at least it uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on MIPS). A bit of debugging led me to that set_cpu_sibling_map() performing the actual map calculation, was being invocated after notify_cpu_start(), and exactly the latter function starts CPU HP callback round (sched_core_cpu_starting() is basically a CPU HP callback). While the flow is same on ARM64 (maps after the notifier, although before calling set_cpu_online()), x86 started calculating sibling maps earlier than starting the CPU HP callbacks in Linux 4.14 (see [0] for the reference). Neither me nor my brief tests couldn't find any potential caveats in calculating the maps right after performing delay calibration, but the WARN splat is now gone. The very same debug prints now yield exactly what I expected from them: [ 0.048433] CPU: 1, smt_mask: 0-1 [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=7… Signed-off-by: Alexander Lobakin <alobakin(a)pm.me> Reviewed-by: Philippe Mathieu-Daudé <f4bug(a)amsat.org> Signed-off-by: Thomas Bogendoerfer <tsbogend(a)alpha.franken.de> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/mips/kernel/smp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c index d84b9066b465..7206a6977be9 100644 --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -372,6 +372,9 @@ asmlinkage void start_secondary(void) cpu = smp_processor_id(); cpu_data[cpu].udelay_val = loops_per_jiffy; + set_cpu_sibling_map(cpu); + set_cpu_core_map(cpu); + cpumask_set_cpu(cpu, &cpu_coherent_mask); notify_cpu_starting(cpu); @@ -383,9 +386,6 @@ asmlinkage void start_secondary(void) /* The CPU is running and counters synchronised, now mark it online */ set_cpu_online(cpu, true); - set_cpu_sibling_map(cpu); - set_cpu_core_map(cpu); - calculate_cpu_foreign_map(); /* -- 2.25.1

2 1

[openeuler:OLK-6.6 10543/10853] arch/x86/kvm/svm/sev.c:2200:24: error: 'struct hygon_kvm_hooks_table' has no member named 'false'
by kernel test robot 20 Jul '24

20 Jul '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: b53be02fc76386cd434560ddfa8c5f5f908ced12 commit: 1c3b1095a26ed8bc1aa7ac3d4e8dd3e65964a74b [10543/10853] KVM: SVM: Add KVM_CSV_COMMAND_BATCH command for applying CSV RING_BUFFER mode config: x86_64-randconfig-072-20240720 (https://download.01.org/0day-ci/archive/20240720/202407201747.if3DROph-lkp@…) compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240720/202407201747.if3DROph-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/202407201747.if3DROph-lkp@intel.com/ All errors (new ones prefixed by >>): arch/x86/kvm/svm/sev.c:2198:6: warning: no previous prototype for 'sev_install_hooks' [-Wmissing-prototypes] 2198 | void sev_install_hooks(void) | ^~~~~~~~~~~~~~~~~ arch/x86/kvm/svm/sev.c: In function 'sev_install_hooks': >> arch/x86/kvm/svm/sev.c:2200:24: error: 'struct hygon_kvm_hooks_table' has no member named 'false' 2200 | hygon_kvm_hooks.sev_enabled = &sev_enabled; | ^ >> arch/x86/kvm/svm/sev.c:2200:39: error: lvalue required as unary '&' operand 2200 | hygon_kvm_hooks.sev_enabled = &sev_enabled; | ^ vim +2200 arch/x86/kvm/svm/sev.c 2195 2196 #ifdef CONFIG_HYGON_CSV 2197 /* Code to set all of the function and vaiable pointers */ > 2198 void sev_install_hooks(void) 2199 { > 2200 hygon_kvm_hooks.sev_enabled = &sev_enabled; 2201 hygon_kvm_hooks.sev_issue_cmd = sev_issue_cmd; 2202 hygon_kvm_hooks.get_num_contig_pages = get_num_contig_pages; 2203 hygon_kvm_hooks.sev_pin_memory = sev_pin_memory; 2204 hygon_kvm_hooks.sev_unpin_memory = sev_unpin_memory; 2205 2206 hygon_kvm_hooks.sev_hooks_installed = true; 2207 } 2208 #endif 2209 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] cxl/region: Fix memregion leaks in devm_cxl_add_region()
by Pu Lehui 20 Jul '24

20 Jul '24

From: Li Zhijian <lizhijian(a)fujitsu.com> stable inclusion from stable-v6.6.35 commit d8316838aa0686da63a8be4194b7a17b0103ae4a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD05U CVE: CVE-2024-40936 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 49ba7b515c4c0719b866d16f068e62d16a8a3dd1 ] Move the mode verification to __create_region() before allocating the memregion to avoid the memregion leaks. Fixes: 6e099264185d ("cxl/region: Add volatile region creation support") Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Link: https://lore.kernel.org/r/20240507053421.456439-1-lizhijian@fujitsu.com Signed-off-by: Dave Jiang <dave.jiang(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/cxl/core/region.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c index e2a82ee4ff0c..6f06255012f0 100644 --- a/drivers/cxl/core/region.c +++ b/drivers/cxl/core/region.c @@ -2186,15 +2186,6 @@ static struct cxl_region *devm_cxl_add_region(struct cxl_root_decoder *cxlrd, struct device *dev; int rc; - switch (mode) { - case CXL_DECODER_RAM: - case CXL_DECODER_PMEM: - break; - default: - dev_err(&cxlrd->cxlsd.cxld.dev, "unsupported mode %d\n", mode); - return ERR_PTR(-EINVAL); - } - cxlr = cxl_region_alloc(cxlrd, id); if (IS_ERR(cxlr)) return cxlr; @@ -2245,6 +2236,15 @@ static struct cxl_region *__create_region(struct cxl_root_decoder *cxlrd, { int rc; + switch (mode) { + case CXL_DECODER_RAM: + case CXL_DECODER_PMEM: + break; + default: + dev_err(&cxlrd->cxlsd.cxld.dev, "unsupported mode %d\n", mode); + return ERR_PTR(-EINVAL); + } + rc = memregion_alloc(GFP_KERNEL); if (rc < 0) return ERR_PTR(rc); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] scsi: ufs: Fix a deadlock in the error handler
by Pu Lehui 20 Jul '24

20 Jul '24

From: Bart Van Assche <bvanassche(a)acm.org> mainline inclusion from mainline-v5.17-rc1 commit 945c3cca05d78351bba29fa65d93834cb7934c7b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADG3U CVE: CVE-2021-47622 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The following deadlock has been observed on a test setup: - All tags allocated - The SCSI error handler calls ufshcd_eh_host_reset_handler() - ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler() - ufshcd_err_handler() locks up as follows: Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request. Link: https://lore.kernel.org/r/20211203231950.193369-10-bvanassche@acm.org Tested-by: Bean Huo <beanhuo(a)micron.com> Reviewed-by: Adrian Hunter <adrian.hunter(a)intel.com> Reviewed-by: Bean Huo <beanhuo(a)micron.com> Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Conflicts: drivers/scsi/ufs/ufshcd.c [The Conflicts were due to not backport some unnecessary patch] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/scsi/ufs/ufshcd.c | 52 +++++++++++---------------------------- drivers/scsi/ufs/ufshcd.h | 2 ++ 2 files changed, 16 insertions(+), 38 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 129c45c6bba5..3aa8a600e9a5 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -125,8 +125,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dump_regs); enum { UFSHCD_MAX_CHANNEL = 0, UFSHCD_MAX_ID = 1, - UFSHCD_CMD_PER_LUN = 32, - UFSHCD_CAN_QUEUE = 32, + UFSHCD_NUM_RESERVED = 1, + UFSHCD_CMD_PER_LUN = 32 - UFSHCD_NUM_RESERVED, + UFSHCD_CAN_QUEUE = 32 - UFSHCD_NUM_RESERVED, }; /* UFSHCD states */ @@ -2046,6 +2047,7 @@ static inline int ufshcd_hba_capabilities(struct ufs_hba *hba) hba->nutrs = (hba->capabilities & MASK_TRANSFER_REQUESTS_SLOTS) + 1; hba->nutmrs = ((hba->capabilities & MASK_TASK_MANAGEMENT_REQUEST_SLOTS) >> 16) + 1; + hba->reserved_slot = hba->nutrs - 1; /* Read crypto capabilities */ err = ufshcd_hba_init_crypto_capabilities(hba); @@ -2774,31 +2776,16 @@ static int ufshcd_wait_for_dev_cmd(struct ufs_hba *hba, static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, enum dev_cmd_type cmd_type, int timeout) { - struct request_queue *q = hba->cmd_queue; - struct request *req; + const u32 tag = hba->reserved_slot; struct ufshcd_lrb *lrbp; int err; - int tag; struct completion wait; unsigned long flags; - down_read(&hba->clk_scaling_lock); + /* Protects use of hba->reserved_slot. */ + lockdep_assert_held(&hba->dev_cmd.lock); - /* - * Get free slot, sleep if slots are unavailable. - * Even though we use wait_event() which sleeps indefinitely, - * the maximum wait time is bounded by SCSI request timeout. - */ - req = blk_get_request(q, REQ_OP_DRV_OUT, 0); - if (IS_ERR(req)) { - err = PTR_ERR(req); - goto out_unlock; - } - tag = req->tag; - WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag)); - /* Set the timeout such that the SCSI error handler is not activated. */ - req->timeout = msecs_to_jiffies(2 * timeout); - blk_mq_start_request(req); + down_read(&hba->clk_scaling_lock); init_completion(&wait); lrbp = &hba->lrb[tag]; @@ -2822,8 +2809,6 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, err ? "query_complete_err" : "query_complete"); out_put_tag: - blk_put_request(req); -out_unlock: up_read(&hba->clk_scaling_lock); return err; } @@ -6380,24 +6365,17 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba, enum dev_cmd_type cmd_type, enum query_opcode desc_op) { - struct request_queue *q = hba->cmd_queue; - struct request *req; + const u32 tag = hba->reserved_slot; struct ufshcd_lrb *lrbp; int err = 0; - int tag; struct completion wait; unsigned long flags; u8 upiu_flags; - down_read(&hba->clk_scaling_lock); + /* Protects use of hba->reserved_slot. */ + lockdep_assert_held(&hba->dev_cmd.lock); - req = blk_get_request(q, REQ_OP_DRV_OUT, 0); - if (IS_ERR(req)) { - err = PTR_ERR(req); - goto out_unlock; - } - tag = req->tag; - WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag)); + down_read(&hba->clk_scaling_lock); init_completion(&wait); lrbp = &hba->lrb[tag]; @@ -6474,8 +6452,6 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba, } } - blk_put_request(req); -out_unlock: up_read(&hba->clk_scaling_lock); return err; } @@ -9146,8 +9122,8 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq) /* Configure LRB */ ufshcd_host_memory_configure(hba); - host->can_queue = hba->nutrs; - host->cmd_per_lun = hba->nutrs; + host->can_queue = hba->nutrs - UFSHCD_NUM_RESERVED; + host->cmd_per_lun = hba->nutrs - UFSHCD_NUM_RESERVED; host->max_id = UFSHCD_MAX_ID; host->max_lun = UFS_MAX_LUNS; host->max_channel = UFSHCD_MAX_CHANNEL; diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index 35dd5197ccb9..160a6ef58942 100644 --- a/drivers/scsi/ufs/ufshcd.h +++ b/drivers/scsi/ufs/ufshcd.h @@ -634,6 +634,7 @@ struct ufs_hba_variant_params { * @capabilities: UFS Controller Capabilities * @nutrs: Transfer Request Queue depth supported by controller * @nutmrs: Task Management Queue depth supported by controller + * @reserved_slot: Used to submit device commands. Protected by @dev_cmd.lock. * @ufs_version: UFS Version to which controller complies * @vops: pointer to variant specific operations * @priv: pointer to variant specific private data @@ -719,6 +720,7 @@ struct ufs_hba { u32 capabilities; int nutrs; int nutmrs; + u32 reserved_slot; u32 ufs_version; const struct ufs_hba_variant_ops *vops; struct ufs_hba_variant_params *vps; -- 2.34.1

2 1

[PATCH OLK-5.10] scsi: ufs: Fix a deadlock in the error handler
by Pu Lehui 20 Jul '24

20 Jul '24

From: Bart Van Assche <bvanassche(a)acm.org> mainline inclusion from mainline-v5.17-rc1 commit 945c3cca05d78351bba29fa65d93834cb7934c7b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADG3U CVE: CVE-2021-47622 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The following deadlock has been observed on a test setup: - All tags allocated - The SCSI error handler calls ufshcd_eh_host_reset_handler() - ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler() - ufshcd_err_handler() locks up as follows: Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request. Link: https://lore.kernel.org/r/20211203231950.193369-10-bvanassche@acm.org Tested-by: Bean Huo <beanhuo(a)micron.com> Reviewed-by: Adrian Hunter <adrian.hunter(a)intel.com> Reviewed-by: Bean Huo <beanhuo(a)micron.com> Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Conflicts: drivers/scsi/ufs/ufshcd.c [The Conflicts were due to not backport some unnecessary patch] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/scsi/ufs/ufshcd.c | 52 +++++++++++---------------------------- drivers/scsi/ufs/ufshcd.h | 2 ++ 2 files changed, 16 insertions(+), 38 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 129c45c6bba5..3aa8a600e9a5 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -125,8 +125,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dump_regs); enum { UFSHCD_MAX_CHANNEL = 0, UFSHCD_MAX_ID = 1, - UFSHCD_CMD_PER_LUN = 32, - UFSHCD_CAN_QUEUE = 32, + UFSHCD_NUM_RESERVED = 1, + UFSHCD_CMD_PER_LUN = 32 - UFSHCD_NUM_RESERVED, + UFSHCD_CAN_QUEUE = 32 - UFSHCD_NUM_RESERVED, }; /* UFSHCD states */ @@ -2046,6 +2047,7 @@ static inline int ufshcd_hba_capabilities(struct ufs_hba *hba) hba->nutrs = (hba->capabilities & MASK_TRANSFER_REQUESTS_SLOTS) + 1; hba->nutmrs = ((hba->capabilities & MASK_TASK_MANAGEMENT_REQUEST_SLOTS) >> 16) + 1; + hba->reserved_slot = hba->nutrs - 1; /* Read crypto capabilities */ err = ufshcd_hba_init_crypto_capabilities(hba); @@ -2774,31 +2776,16 @@ static int ufshcd_wait_for_dev_cmd(struct ufs_hba *hba, static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, enum dev_cmd_type cmd_type, int timeout) { - struct request_queue *q = hba->cmd_queue; - struct request *req; + const u32 tag = hba->reserved_slot; struct ufshcd_lrb *lrbp; int err; - int tag; struct completion wait; unsigned long flags; - down_read(&hba->clk_scaling_lock); + /* Protects use of hba->reserved_slot. */ + lockdep_assert_held(&hba->dev_cmd.lock); - /* - * Get free slot, sleep if slots are unavailable. - * Even though we use wait_event() which sleeps indefinitely, - * the maximum wait time is bounded by SCSI request timeout. - */ - req = blk_get_request(q, REQ_OP_DRV_OUT, 0); - if (IS_ERR(req)) { - err = PTR_ERR(req); - goto out_unlock; - } - tag = req->tag; - WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag)); - /* Set the timeout such that the SCSI error handler is not activated. */ - req->timeout = msecs_to_jiffies(2 * timeout); - blk_mq_start_request(req); + down_read(&hba->clk_scaling_lock); init_completion(&wait); lrbp = &hba->lrb[tag]; @@ -2822,8 +2809,6 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, err ? "query_complete_err" : "query_complete"); out_put_tag: - blk_put_request(req); -out_unlock: up_read(&hba->clk_scaling_lock); return err; } @@ -6380,24 +6365,17 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba, enum dev_cmd_type cmd_type, enum query_opcode desc_op) { - struct request_queue *q = hba->cmd_queue; - struct request *req; + const u32 tag = hba->reserved_slot; struct ufshcd_lrb *lrbp; int err = 0; - int tag; struct completion wait; unsigned long flags; u8 upiu_flags; - down_read(&hba->clk_scaling_lock); + /* Protects use of hba->reserved_slot. */ + lockdep_assert_held(&hba->dev_cmd.lock); - req = blk_get_request(q, REQ_OP_DRV_OUT, 0); - if (IS_ERR(req)) { - err = PTR_ERR(req); - goto out_unlock; - } - tag = req->tag; - WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag)); + down_read(&hba->clk_scaling_lock); init_completion(&wait); lrbp = &hba->lrb[tag]; @@ -6474,8 +6452,6 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba, } } - blk_put_request(req); -out_unlock: up_read(&hba->clk_scaling_lock); return err; } @@ -9146,8 +9122,8 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq) /* Configure LRB */ ufshcd_host_memory_configure(hba); - host->can_queue = hba->nutrs; - host->cmd_per_lun = hba->nutrs; + host->can_queue = hba->nutrs - UFSHCD_NUM_RESERVED; + host->cmd_per_lun = hba->nutrs - UFSHCD_NUM_RESERVED; host->max_id = UFSHCD_MAX_ID; host->max_lun = UFS_MAX_LUNS; host->max_channel = UFSHCD_MAX_CHANNEL; diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index 35dd5197ccb9..160a6ef58942 100644 --- a/drivers/scsi/ufs/ufshcd.h +++ b/drivers/scsi/ufs/ufshcd.h @@ -634,6 +634,7 @@ struct ufs_hba_variant_params { * @capabilities: UFS Controller Capabilities * @nutrs: Transfer Request Queue depth supported by controller * @nutmrs: Task Management Queue depth supported by controller + * @reserved_slot: Used to submit device commands. Protected by @dev_cmd.lock. * @ufs_version: UFS Version to which controller complies * @vops: pointer to variant specific operations * @priv: pointer to variant specific private data @@ -719,6 +720,7 @@ struct ufs_hba { u32 capabilities; int nutrs; int nutmrs; + u32 reserved_slot; u32 ufs_version; const struct ufs_hba_variant_ops *vops; struct ufs_hba_variant_params *vps; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/3] CVE-2024-35931
by Liu Chuang 20 Jul '24

20 Jul '24

Fixing CVE-2024-35931 Asad Kamal (1): drm/amdgpu : Add hive ras recovery check Liu Chuang (1): drm/amdgpu: Fix kabi breakage in struct amdgpu_hive_info Stanley.Yang (1): drm/amdgpu: Skip do PCI error slot reset during RAS recovery drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 ++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 +++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 2 ++ 3 files changed, 25 insertions(+), 2 deletions(-) -- 2.34.1

2 4

[PATCH OLK-5.10] bpf: Fix overrunning reservations in ringbuf
by Pu Lehui 20 Jul '24

20 Jul '24

From: Daniel Borkmann <daniel(a)iogearbox.net> mainline inclusion from mainline-v6.10-rc6 commit cfa1a2329a691ffd991fcf7248a57d752e712881 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADR59 CVE: CVE-2024-41009 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Reported-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Reported-by: Muhammad Ramdhan <ramdhan(a)starlabs.sg> Co-developed-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Co-developed-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240621140828.18238-1-daniel@iogearbox.net Conflicts: kernel/bpf/ringbuf.c [The Conflicts were due to not merge commit 583c1f420173f] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/ringbuf.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c index d6fbe17432ae..d21d4ba2eb39 100644 --- a/kernel/bpf/ringbuf.c +++ b/kernel/bpf/ringbuf.c @@ -44,6 +44,7 @@ struct bpf_ringbuf { */ unsigned long consumer_pos __aligned(PAGE_SIZE); unsigned long producer_pos __aligned(PAGE_SIZE); + unsigned long pending_pos; char data[] __aligned(PAGE_SIZE); }; @@ -145,6 +146,7 @@ static struct bpf_ringbuf *bpf_ringbuf_alloc(size_t data_sz, int numa_node) rb->mask = data_sz - 1; rb->consumer_pos = 0; rb->producer_pos = 0; + rb->pending_pos = 0; return rb; } @@ -323,9 +325,9 @@ bpf_ringbuf_restore_from_rec(struct bpf_ringbuf_hdr *hdr) static void *__bpf_ringbuf_reserve(struct bpf_ringbuf *rb, u64 size) { - unsigned long cons_pos, prod_pos, new_prod_pos, flags; - u32 len, pg_off; + unsigned long cons_pos, prod_pos, new_prod_pos, pend_pos, flags; struct bpf_ringbuf_hdr *hdr; + u32 len, pg_off, tmp_size, hdr_len; if (unlikely(size > RINGBUF_MAX_RECORD_SZ)) return NULL; @@ -343,13 +345,29 @@ static void *__bpf_ringbuf_reserve(struct bpf_ringbuf *rb, u64 size) spin_lock_irqsave(&rb->spinlock, flags); } + pend_pos = rb->pending_pos; prod_pos = rb->producer_pos; new_prod_pos = prod_pos + len; - /* check for out of ringbuf space by ensuring producer position - * doesn't advance more than (ringbuf_size - 1) ahead + while (pend_pos < prod_pos) { + hdr = (void *)rb->data + (pend_pos & rb->mask); + hdr_len = READ_ONCE(hdr->len); + if (hdr_len & BPF_RINGBUF_BUSY_BIT) + break; + tmp_size = hdr_len & ~BPF_RINGBUF_DISCARD_BIT; + tmp_size = round_up(tmp_size + BPF_RINGBUF_HDR_SZ, 8); + pend_pos += tmp_size; + } + rb->pending_pos = pend_pos; + + /* check for out of ringbuf space: + * - by ensuring producer position doesn't advance more than + * (ringbuf_size - 1) ahead + * - by ensuring oldest not yet committed record until newest + * record does not span more than (ringbuf_size - 1) */ - if (new_prod_pos - cons_pos > rb->mask) { + if (new_prod_pos - cons_pos > rb->mask || + new_prod_pos - pend_pos > rb->mask) { spin_unlock_irqrestore(&rb->spinlock, flags); return NULL; } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] bpf: Fix overrunning reservations in ringbuf
by Pu Lehui 20 Jul '24

20 Jul '24

From: Daniel Borkmann <daniel(a)iogearbox.net> mainline inclusion from mainline-v6.10-rc6 commit cfa1a2329a691ffd991fcf7248a57d752e712881 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADR59 CVE: CVE-2024-41009 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Reported-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Reported-by: Muhammad Ramdhan <ramdhan(a)starlabs.sg> Co-developed-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Co-developed-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240621140828.18238-1-daniel@iogearbox.net Conflicts: kernel/bpf/ringbuf.c [The Conflicts were due to not merge commit 583c1f420173f] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/ringbuf.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c index d6fbe17432ae..d21d4ba2eb39 100644 --- a/kernel/bpf/ringbuf.c +++ b/kernel/bpf/ringbuf.c @@ -44,6 +44,7 @@ struct bpf_ringbuf { */ unsigned long consumer_pos __aligned(PAGE_SIZE); unsigned long producer_pos __aligned(PAGE_SIZE); + unsigned long pending_pos; char data[] __aligned(PAGE_SIZE); }; @@ -145,6 +146,7 @@ static struct bpf_ringbuf *bpf_ringbuf_alloc(size_t data_sz, int numa_node) rb->mask = data_sz - 1; rb->consumer_pos = 0; rb->producer_pos = 0; + rb->pending_pos = 0; return rb; } @@ -323,9 +325,9 @@ bpf_ringbuf_restore_from_rec(struct bpf_ringbuf_hdr *hdr) static void *__bpf_ringbuf_reserve(struct bpf_ringbuf *rb, u64 size) { - unsigned long cons_pos, prod_pos, new_prod_pos, flags; - u32 len, pg_off; + unsigned long cons_pos, prod_pos, new_prod_pos, pend_pos, flags; struct bpf_ringbuf_hdr *hdr; + u32 len, pg_off, tmp_size, hdr_len; if (unlikely(size > RINGBUF_MAX_RECORD_SZ)) return NULL; @@ -343,13 +345,29 @@ static void *__bpf_ringbuf_reserve(struct bpf_ringbuf *rb, u64 size) spin_lock_irqsave(&rb->spinlock, flags); } + pend_pos = rb->pending_pos; prod_pos = rb->producer_pos; new_prod_pos = prod_pos + len; - /* check for out of ringbuf space by ensuring producer position - * doesn't advance more than (ringbuf_size - 1) ahead + while (pend_pos < prod_pos) { + hdr = (void *)rb->data + (pend_pos & rb->mask); + hdr_len = READ_ONCE(hdr->len); + if (hdr_len & BPF_RINGBUF_BUSY_BIT) + break; + tmp_size = hdr_len & ~BPF_RINGBUF_DISCARD_BIT; + tmp_size = round_up(tmp_size + BPF_RINGBUF_HDR_SZ, 8); + pend_pos += tmp_size; + } + rb->pending_pos = pend_pos; + + /* check for out of ringbuf space: + * - by ensuring producer position doesn't advance more than + * (ringbuf_size - 1) ahead + * - by ensuring oldest not yet committed record until newest + * record does not span more than (ringbuf_size - 1) */ - if (new_prod_pos - cons_pos > rb->mask) { + if (new_prod_pos - cons_pos > rb->mask || + new_prod_pos - pend_pos > rb->mask) { spin_unlock_irqrestore(&rb->spinlock, flags); return NULL; } -- 2.34.1

2 1

[PATCH OLK-6.6] bpf: Fix overrunning reservations in ringbuf
by Pu Lehui 20 Jul '24

20 Jul '24

From: Daniel Borkmann <daniel(a)iogearbox.net> stable inclusion from stable-v6.6.37 commit 511804ab701c0503b72eac08217eabfd366ba069 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADR59 CVE: CVE-2024-41009 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit cfa1a2329a691ffd991fcf7248a57d752e712881 ] The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Reported-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Reported-by: Muhammad Ramdhan <ramdhan(a)starlabs.sg> Co-developed-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Co-developed-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20240621140828.18238-1-daniel@iogearbox.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/ringbuf.c | 31 +++++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c index f045fde632e5..238d9b206bbd 100644 --- a/kernel/bpf/ringbuf.c +++ b/kernel/bpf/ringbuf.c @@ -51,7 +51,8 @@ struct bpf_ringbuf { * This prevents a user-space application from modifying the * position and ruining in-kernel tracking. The permissions of the * pages depend on who is producing samples: user-space or the - * kernel. + * kernel. Note that the pending counter is placed in the same + * page as the producer, so that it shares the same cache line. * * Kernel-producer * --------------- @@ -70,6 +71,7 @@ struct bpf_ringbuf { */ unsigned long consumer_pos __aligned(PAGE_SIZE); unsigned long producer_pos __aligned(PAGE_SIZE); + unsigned long pending_pos; char data[] __aligned(PAGE_SIZE); }; @@ -179,6 +181,7 @@ static struct bpf_ringbuf *bpf_ringbuf_alloc(size_t data_sz, int numa_node) rb->mask = data_sz - 1; rb->consumer_pos = 0; rb->producer_pos = 0; + rb->pending_pos = 0; return rb; } @@ -404,9 +407,9 @@ bpf_ringbuf_restore_from_rec(struct bpf_ringbuf_hdr *hdr) static void *__bpf_ringbuf_reserve(struct bpf_ringbuf *rb, u64 size) { - unsigned long cons_pos, prod_pos, new_prod_pos, flags; - u32 len, pg_off; + unsigned long cons_pos, prod_pos, new_prod_pos, pend_pos, flags; struct bpf_ringbuf_hdr *hdr; + u32 len, pg_off, tmp_size, hdr_len; if (unlikely(size > RINGBUF_MAX_RECORD_SZ)) return NULL; @@ -424,13 +427,29 @@ static void *__bpf_ringbuf_reserve(struct bpf_ringbuf *rb, u64 size) spin_lock_irqsave(&rb->spinlock, flags); } + pend_pos = rb->pending_pos; prod_pos = rb->producer_pos; new_prod_pos = prod_pos + len; - /* check for out of ringbuf space by ensuring producer position - * doesn't advance more than (ringbuf_size - 1) ahead + while (pend_pos < prod_pos) { + hdr = (void *)rb->data + (pend_pos & rb->mask); + hdr_len = READ_ONCE(hdr->len); + if (hdr_len & BPF_RINGBUF_BUSY_BIT) + break; + tmp_size = hdr_len & ~BPF_RINGBUF_DISCARD_BIT; + tmp_size = round_up(tmp_size + BPF_RINGBUF_HDR_SZ, 8); + pend_pos += tmp_size; + } + rb->pending_pos = pend_pos; + + /* check for out of ringbuf space: + * - by ensuring producer position doesn't advance more than + * (ringbuf_size - 1) ahead + * - by ensuring oldest not yet committed record until newest + * record does not span more than (ringbuf_size - 1) */ - if (new_prod_pos - cons_pos > rb->mask) { + if (new_prod_pos - cons_pos > rb->mask || + new_prod_pos - pend_pos > rb->mask) { spin_unlock_irqrestore(&rb->spinlock, flags); return NULL; } -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] CVE-2024-35931
by Liu Chuang 20 Jul '24

20 Jul '24

Fixing CVE-2024-35931 Asad Kamal (1): drm/amdgpu : Add hive ras recovery check Stanley.Yang (1): drm/amdgpu: Skip do PCI error slot reset during RAS recovery drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 ++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 +++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 1 + .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 10 +++++++++- 4 files changed, 31 insertions(+), 3 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] cxl/region: Fix memregion leaks in devm_cxl_add_region()
by Pu Lehui 20 Jul '24

20 Jul '24

From: Li Zhijian <lizhijian(a)fujitsu.com> stable inclusion from stable-v6.6.35 commit d8316838aa0686da63a8be4194b7a17b0103ae4a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAD6H2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 49ba7b515c4c0719b866d16f068e62d16a8a3dd1 ] Move the mode verification to __create_region() before allocating the memregion to avoid the memregion leaks. Fixes: 6e099264185d ("cxl/region: Add volatile region creation support") Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Link: https://lore.kernel.org/r/20240507053421.456439-1-lizhijian@fujitsu.com Signed-off-by: Dave Jiang <dave.jiang(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/cxl/core/region.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c index e2a82ee4ff0c..6f06255012f0 100644 --- a/drivers/cxl/core/region.c +++ b/drivers/cxl/core/region.c @@ -2186,15 +2186,6 @@ static struct cxl_region *devm_cxl_add_region(struct cxl_root_decoder *cxlrd, struct device *dev; int rc; - switch (mode) { - case CXL_DECODER_RAM: - case CXL_DECODER_PMEM: - break; - default: - dev_err(&cxlrd->cxlsd.cxld.dev, "unsupported mode %d\n", mode); - return ERR_PTR(-EINVAL); - } - cxlr = cxl_region_alloc(cxlrd, id); if (IS_ERR(cxlr)) return cxlr; @@ -2245,6 +2236,15 @@ static struct cxl_region *__create_region(struct cxl_root_decoder *cxlrd, { int rc; + switch (mode) { + case CXL_DECODER_RAM: + case CXL_DECODER_PMEM: + break; + default: + dev_err(&cxlrd->cxlsd.cxld.dev, "unsupported mode %d\n", mode); + return ERR_PTR(-EINVAL); + } + rc = memregion_alloc(GFP_KERNEL); if (rc < 0) return ERR_PTR(rc); -- 2.34.1

2 1

[PATCH OLK-5.10 0/3] CVE-2024-35931
by Liu Chuang 20 Jul '24

20 Jul '24

Fixing CVE-2024-35931 Asad Kamal (1): drm/amdgpu : Add hive ras recovery check Liu Chuang (1): drm/amdgpu: Fix kabi breakage in struct amdgpu_hive_info Stanley.Yang (1): drm/amdgpu: Skip do PCI error slot reset during RAS recovery drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 ++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 +++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 2 ++ 3 files changed, 25 insertions(+), 2 deletions(-) -- 2.34.1

2 4

[PATCH OLK-6.6 0/2] CVE-2024-35931
by Liu Chuang 20 Jul '24

20 Jul '24

Fixing CVE-2024-35931 Asad Kamal (1): drm/amdgpu : Add hive ras recovery check Stanley.Yang (1): drm/amdgpu: Skip do PCI error slot reset during RAS recovery drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 ++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 +++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 1 + .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 10 +++++++++- 4 files changed, 31 insertions(+), 3 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/3] CVE-2024-35931
by Liu Chuang 20 Jul '24

20 Jul '24

Fixing CVE-2024-35931 Asad Kamal (1): drm/amdgpu : Add hive ras recovery check Liu Chuang (1): drm/amdgpu: Fix kabi breakage in struct amdgpu_hive_info Stanley.Yang (1): drm/amdgpu: Skip do PCI error slot reset during RAS recovery drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 ++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 +++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 2 ++ 3 files changed, 25 insertions(+), 2 deletions(-) -- 2.34.1

2 4

[PATCH OLK-5.10 0/3] CVE-2024-35931
by Liu Chuang 20 Jul '24

20 Jul '24

Fixing CVE-2024-35931 Asad Kamal (1): drm/amdgpu : Add hive ras recovery check Liu Chuang (1): drm/amdgpu: Fix kabi breakage in struct amdgpu_hive_info Stanley.Yang (1): drm/amdgpu: Skip do PCI error slot reset during RAS recovery drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 ++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 +++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 2 ++ 3 files changed, 25 insertions(+), 2 deletions(-) -- 2.34.1

2 4

[PATCH openEuler-22.03-LTS-SP1] net: mvpp2: clear BM pool before initialization
by Wang Hai 20 Jul '24

20 Jul '24

From: Jenishkumar Maheshbhai Patel <jpatel2(a)marvell.com> stable inclusion from stable-v5.10.210 commit 83f99138bf3b396f761600ab488054396fb5768f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9DC CVE: CVE-2024-35837 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9f538b415db862e74b8c5d3abbccfc1b2b6caa38 ] Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Jenishkumar Maheshbhai Patel <jpatel2(a)marvell.com> Reviewed-by: Maxime Chevallier <maxime.chevallier(a)bootlin.com> Link: https://lore.kernel.org/r/20240119035914.2595665-1-jpatel2@marvell.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 27 ++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c index 765ec3bc11ad..4bebab7a9bff 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -581,12 +581,38 @@ static int mvpp2_bm_pools_init(struct device *dev, struct mvpp2 *priv) return err; } +/* Cleanup pool before actual initialization in the OS */ +static void mvpp2_bm_pool_cleanup(struct mvpp2 *priv, int pool_id) +{ + unsigned int thread = mvpp2_cpu_to_thread(priv, get_cpu()); + u32 val; + int i; + + /* Drain the BM from all possible residues left by firmware */ + for (i = 0; i < MVPP2_BM_POOL_SIZE_MAX; i++) + mvpp2_thread_read(priv, thread, MVPP2_BM_PHY_ALLOC_REG(pool_id)); + + put_cpu(); + + /* Stop the BM pool */ + val = mvpp2_read(priv, MVPP2_BM_POOL_CTRL_REG(pool_id)); + val |= MVPP2_BM_STOP_MASK; + mvpp2_write(priv, MVPP2_BM_POOL_CTRL_REG(pool_id), val); +} + static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv) { enum dma_data_direction dma_dir = DMA_FROM_DEVICE; int i, err, poolnum = MVPP2_BM_POOLS_NUM; struct mvpp2_port *port; + if (priv->percpu_pools) + poolnum = mvpp2_get_nrxqs(priv) * 2; + + /* Clean up the pool state in case it contains stale state */ + for (i = 0; i < poolnum; i++) + mvpp2_bm_pool_cleanup(priv, i); + if (priv->percpu_pools) { for (i = 0; i < priv->port_count; i++) { port = priv->port_list[i]; @@ -596,7 +622,6 @@ static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv) } } - poolnum = mvpp2_get_nrxqs(priv) * 2; for (i = 0; i < poolnum; i++) { /* the pool in use */ int pn = i / (poolnum / 2); -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] udp: do not accept non-tunnel GSO skbs landing in a tunnel
by Wang Hai 20 Jul '24

20 Jul '24

From: Antoine Tenart <atenart(a)kernel.org> stable inclusion from stable-v5.10.215 commit 3391b157780bbedf8ef9f202cbf10ee90bf6b0f8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QG8X CVE: CVE-2024-35884 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3d010c8031e39f5fa1e8b13ada77e0321091011f ] When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with rx-gro-list. We saw this with geneve packets being GROed at the UDP level. In such case gso_size is set; later the packet goes through the geneve rx path, the geneve header is pulled, the offset are adjusted and frag_list skbs are not adjusted with regard to geneve. When those skbs hit skb_fragment, it will misbehave. Different outcomes are possible depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] triggered in skb_segment while processing the frag_list. Because gso_size is wrong (geneve header was pulled) skb_segment thinks there is "geneve header size" of data in frag_list, although it's in fact the next packet. The BUG_ON itself has nothing to do with the issue. This is only one of the potential issues. Looking up for a matching socket in udp_gro_receive is fragile: the lookup could be extended to all netns (not speaking about performances) but nothing prevents those packets from being modified in between and we could still not find a matching socket. It's OK to keep the current logic there as it should cover most cases but we also need to make sure we handle tunnel packets being GROed too early. This is done by extending the checks in udp_unexpected_gso: GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must be segmented. [1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560 Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets") Signed-off-by: Antoine Tenart <atenart(a)kernel.org> Reviewed-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: net/ipv4/udp_offload.c [commit 205c0514a5f6 was merged, which lead to context conflicts] Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- include/linux/udp.h | 28 ++++++++++++++++++++++++++++ net/ipv4/udp.c | 7 +++++++ net/ipv4/udp_offload.c | 6 ++++-- net/ipv6/udp.c | 2 +- 4 files changed, 40 insertions(+), 3 deletions(-) diff --git a/include/linux/udp.h b/include/linux/udp.h index ae58ff3b6b5b..a220880019d6 100644 --- a/include/linux/udp.h +++ b/include/linux/udp.h @@ -131,6 +131,24 @@ static inline void udp_cmsg_recv(struct msghdr *msg, struct sock *sk, } } +DECLARE_STATIC_KEY_FALSE(udp_encap_needed_key); +#if IS_ENABLED(CONFIG_IPV6) +DECLARE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +#endif + +static inline bool udp_encap_needed(void) +{ + if (static_branch_unlikely(&udp_encap_needed_key)) + return true; + +#if IS_ENABLED(CONFIG_IPV6) + if (static_branch_unlikely(&udpv6_encap_needed_key)) + return true; +#endif + + return false; +} + static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb) { if (!skb_is_gso(skb)) @@ -142,6 +160,16 @@ static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb) if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST && !udp_sk(sk)->accept_udp_fraglist) return true; + /* GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits might still + * land in a tunnel as the socket check in udp_gro_receive cannot be + * foolproof. + */ + if (udp_encap_needed() && + READ_ONCE(udp_sk(sk)->encap_rcv) && + !(skb_shinfo(skb)->gso_type & + (SKB_GSO_UDP_TUNNEL | SKB_GSO_UDP_TUNNEL_CSUM))) + return true; + return false; } diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index beccdd959d10..d1f642f4a37f 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -592,6 +592,13 @@ static inline bool __udp_is_mcast_sock(struct net *net, struct sock *sk, } DEFINE_STATIC_KEY_FALSE(udp_encap_needed_key); +EXPORT_SYMBOL(udp_encap_needed_key); + +#if IS_ENABLED(CONFIG_IPV6) +DEFINE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +EXPORT_SYMBOL(udpv6_encap_needed_key); +#endif + void udp_encap_enable(void) { static_branch_inc(&udp_encap_needed_key); diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index 0cdd356866ec..ed50a5f33302 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -512,8 +512,10 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb, unsigned int off = skb_gro_offset(skb); int flush = 1; - /* we can do L4 aggregation only if the packet can't land in a tunnel - * otherwise we could corrupt the inner stream + /* We can do L4 aggregation only if the packet can't land in a tunnel + * otherwise we could corrupt the inner stream. Detecting such packets + * cannot be foolproof and the aggregation might still happen in some + * cases. Such packets should be caught in udp_unexpected_gso later. */ NAPI_GRO_CB(skb)->is_flist = 0; if (!sk || !udp_sk(sk)->gro_receive) { diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index 08a2ceb6b999..83995db29358 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -451,7 +451,7 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, goto try_again; } -DEFINE_STATIC_KEY_FALSE(udpv6_encap_needed_key); +DECLARE_STATIC_KEY_FALSE(udpv6_encap_needed_key); void udpv6_encap_enable(void) { static_branch_inc(&udpv6_encap_needed_key); -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS 0/2] fix CVE-2022-48865
by Zhengchao Shao 20 Jul '24

20 Jul '24

Fix CVE-2022-48865 Tung Nguyen (1): tipc: fix kernel panic when enabling bearer Tuong Lien (1): tipc: fix NULL pointer dereference in tipc_disc_rcv() net/tipc/bearer.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1] drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group
by Kaixiong Yu 20 Jul '24

20 Jul '24

From: Junhao He <hejunhao3(a)huawei.com> stable inclusion from stable-v6.6.33 commit be1fa711e59c874d049f592aef1d4685bdd22bdf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SDT CVE: CVE-2024-38568 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 81bdd60a3d1d3b05e6cc6674845afb1694dd3a0e ] The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the memory write overflow of event_group array occurs. Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds. There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/} Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU") Signed-off-by: Junhao He <hejunhao3(a)huawei.com> Signed-off-by: Hao Chen <chenhao418(a)huawei.com> Acked-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Jijie Shao <shaojijie(a)huawei.com> Link: https://lore.kernel.org/r/20240425124627.13764-3-hejunhao3@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/perf/hisilicon/hns3_pmu.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/perf/hisilicon/hns3_pmu.c b/drivers/perf/hisilicon/hns3_pmu.c index 40edc4cfcc34..47c0de7671cc 100644 --- a/drivers/perf/hisilicon/hns3_pmu.c +++ b/drivers/perf/hisilicon/hns3_pmu.c @@ -1088,15 +1088,27 @@ static bool hns3_pmu_validate_event_group(struct perf_event *event) return false; for (num = 0; num < counters; num++) { + /* + * If we find a related event, then it's a valid group + * since we don't need to allocate a new counter for it. + */ if (hns3_pmu_cmp_event(event_group[num], sibling)) break; } + /* + * Otherwise it's a new event but if there's no available counter, + * fail the check since we cannot schedule all the events in + * the group simultaneously. + */ + if (num == HNS3_PMU_MAX_HW_EVENTS) + return false; + if (num == counters) event_group[counters++] = sibling; } - return counters <= HNS3_PMU_MAX_HW_EVENTS; + return true; } static u32 hns3_pmu_get_filter_condition(struct perf_event *event) -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/2] fix CVE-2022-48865
by Zhengchao Shao 20 Jul '24

20 Jul '24

Fix CVE-2022-48865. Tung Nguyen (1): tipc: fix kernel panic when enabling bearer Tuong Lien (1): tipc: fix NULL pointer dereference in tipc_disc_rcv() net/tipc/bearer.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] cxl/region: Fix memregion leaks in devm_cxl_add_region()
by Pu Lehui 20 Jul '24

20 Jul '24

From: Li Zhijian <lizhijian(a)fujitsu.com> stable inclusion from stable-v6.6.35 commit d8316838aa0686da63a8be4194b7a17b0103ae4a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAD6H2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 49ba7b515c4c0719b866d16f068e62d16a8a3dd1 ] Move the mode verification to __create_region() before allocating the memregion to avoid the memregion leaks. Fixes: 6e099264185d ("cxl/region: Add volatile region creation support") Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Link: https://lore.kernel.org/r/20240507053421.456439-1-lizhijian@fujitsu.com Signed-off-by: Dave Jiang <dave.jiang(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/cxl/core/region.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c index e2a82ee4ff0c..6f06255012f0 100644 --- a/drivers/cxl/core/region.c +++ b/drivers/cxl/core/region.c @@ -2186,15 +2186,6 @@ static struct cxl_region *devm_cxl_add_region(struct cxl_root_decoder *cxlrd, struct device *dev; int rc; - switch (mode) { - case CXL_DECODER_RAM: - case CXL_DECODER_PMEM: - break; - default: - dev_err(&cxlrd->cxlsd.cxld.dev, "unsupported mode %d\n", mode); - return ERR_PTR(-EINVAL); - } - cxlr = cxl_region_alloc(cxlrd, id); if (IS_ERR(cxlr)) return cxlr; @@ -2245,6 +2236,15 @@ static struct cxl_region *__create_region(struct cxl_root_decoder *cxlrd, { int rc; + switch (mode) { + case CXL_DECODER_RAM: + case CXL_DECODER_PMEM: + break; + default: + dev_err(&cxlrd->cxlsd.cxld.dev, "unsupported mode %d\n", mode); + return ERR_PTR(-EINVAL); + } + rc = memregion_alloc(GFP_KERNEL); if (rc < 0) return ERR_PTR(rc); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] gianfar: ethtool: Fix refcount leak in gfar_get_ts_info
by Zhengchao Shao 20 Jul '24

20 Jul '24

From: Miaoqian Lin <linmq006(a)gmail.com> stable inclusion from stable-v4.19.235 commit 6263f2eb93a85ad7df504daf0c341a7fb6bbe8a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADGRU CVE: CVE-2022-48856 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 2ac5b58e645c66932438bb021cb5b52097ce70b0 ] The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. Fixes: 7349a74ea75c ("net: ethernet: gianfar_ethtool: get phc index through drvdata") Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Reviewed-by: Claudiu Manoil <claudiu.manoil(a)nxp.com> Link: https://lore.kernel.org/r/20220310015313.14938-1-linmq006@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/freescale/gianfar_ethtool.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c index 395a5266ea30..0cddaaaf48aa 100644 --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c @@ -1528,6 +1528,7 @@ static int gfar_get_ts_info(struct net_device *dev, ptp_node = of_find_compatible_node(NULL, NULL, "fsl,etsec-ptp"); if (ptp_node) { ptp_dev = of_find_device_by_node(ptp_node); + of_node_put(ptp_node); if (ptp_dev) ptp = platform_get_drvdata(ptp_dev); } -- 2.34.1

2 1

[PATCH v3 OLK-6.6] PCI/ROM: Fix PCI ROM header check bug
by liwei 19 Jul '24

19 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAEAGS -------------------------------- In UEFI Specification Version 2.8, describes that the PCIR data structure must start on a 4-byte boundary. Add checks to prevent vulnerabilities. Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/pci/rom.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index 8fc9a4e911e3..c9b416e62a87 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -98,6 +98,12 @@ static size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, } /* get the PCI data structure and check its "PCIR" signature */ pds = image + readw(image + 24); + /* The PCIR data structure must begin on a 4-byte boundary */ + if (pds & 0x3) { + pci_info(pdev, "Invalid PCI ROM header signature: \ + Pointer to Configuration Utility Code Header %#06x\n", readw(image + 24)); + break; + } if (readl(pds) != 0x52494350) { pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n", readl(pds)); -- 2.25.1

2 1

[PATCH v2 OLK-6.6] PCI/ROM: Fix PCI ROM header check bug
by liwei 19 Jul '24

19 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAEAGS -------------------------------- In UEFI Specification Version 2.8, describes that the PCIR data structure must start on a 4-byte boundary. Add checks to prevent vulnerabilities. Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/pci/rom.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index 8fc9a4e911e3..e6135d9875de 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -98,6 +98,12 @@ static size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, } /* get the PCI data structure and check its "PCIR" signature */ pds = image + readw(image + 24); + /* The PCIR data structure must begin on a 4-byte boundary */ + if (pds && 0x3) { + pci_info(pdev, "Invalid PCI ROM header signature: \ + Pointer to Configuration Utility Code Header %#06x\n", readw(image + 24)); + break; + } if (readl(pds) != 0x52494350) { pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n", readl(pds)); -- 2.25.1

2 1

[PATCH] PCI/ROM: Fix PCI ROM header check bug
by liwei 19 Jul '24

19 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAEAGS In UEFI Specification Version 2.8, describes that the PCIR data structure must start on a 4-byte boundary. Add checks to prevent vulnerabilities. Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/pci/rom.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index 8fc9a4e911e3..e6135d9875de 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -98,6 +98,12 @@ static size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, } /* get the PCI data structure and check its "PCIR" signature */ pds = image + readw(image + 24); + /* The PCIR data structure must begin on a 4-byte boundary */ + if (pds && 0x3) { + pci_info(pdev, "Invalid PCI ROM header signature: \ + Pointer to Configuration Utility Code Header %#06x\n", readw(image + 24)); + break; + } if (readl(pds) != 0x52494350) { pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n", readl(pds)); -- 2.25.1

1 0

[PATCH OLK-5.10] dma-mapping: benchmark: fix node id validation
by Kaixiong Yu 19 Jul '24

19 Jul '24

From: Fedor Pchelkin <pchelkin(a)ispras.ru> stable inclusion from stable-v6.6.33 commit 34a816d8735f3924b74be8e5bf766ade1f3bd10b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DBN CVE: CVE-2024-34777 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1ff05e723f7ca30644b8ec3fb093f16312e408ad ] While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to: BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node. Found by Linux Verification Center (linuxtesting.org) Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs") Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- kernel/dma/map_benchmark.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index c2d225e1cd47..5c13c9352bb5 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -228,7 +228,8 @@ static long map_benchmark_ioctl(struct file *file, unsigned int cmd, } if (map->bparam.node != NUMA_NO_NODE && - !node_possible(map->bparam.node)) { + (map->bparam.node < 0 || map->bparam.node >= MAX_NUMNODES || + !node_possible(map->bparam.node))) { pr_err("invalid numa node\n"); return -EINVAL; } -- 2.25.1

2 1

[PATCH OLK-5.10] net: dsa: seville: register the mdiobus under devres
by Zhengchao Shao 19 Jul '24

19 Jul '24

From: Vladimir Oltean <vladimir.oltean(a)nxp.com> mainline inclusion from mainline-v5.17-rc4 commit bd488afc3b39e045ba71aab472233f2a78726e7b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADFY0 CVE: CVE-2022-48814 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Seville VSC9959 switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the seville switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The seville driver has a code structure that could accommodate both the mdiobus_unregister and mdiobus_free calls, but it has an external dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls devm_mdiobus_alloc_size() on its behalf. So rather than restructuring that, and exporting yet one more symbol mscc_miim_teardown(), let's work with devres and replace of_mdiobus_register with the devres variant. When we use all-devres, we can ensure that devres doesn't free a still-registered bus (it either runs both callbacks, or none). Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/dsa/ocelot/seville_vsc9953.c [The conflict occurs because the commit 5186c4a05b97("net: dsa: ocelot: seville: utilize of_mdiobus_register") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/dsa/ocelot/seville_vsc9953.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c b/drivers/net/dsa/ocelot/seville_vsc9953.c index 7026523f886c..81875e96096b 100644 --- a/drivers/net/dsa/ocelot/seville_vsc9953.c +++ b/drivers/net/dsa/ocelot/seville_vsc9953.c @@ -1092,7 +1092,7 @@ static int vsc9953_mdio_bus_alloc(struct ocelot *ocelot) snprintf(bus->id, MII_BUS_ID_SIZE, "%s-imdio", dev_name(dev)); /* Needed in order to initialize the bus mutex lock */ - rc = mdiobus_register(bus); + rc = devm_mdiobus_register(dev, bus); if (rc < 0) { dev_err(dev, "failed to register MDIO bus\n"); return rc; @@ -1144,7 +1144,8 @@ static void vsc9953_mdio_bus_free(struct ocelot *ocelot) mdio_device_free(pcs->mdio); lynx_pcs_destroy(pcs); } - mdiobus_unregister(felix->imdio); + + /* mdiobus_unregister and mdiobus_free handled by devres */ } static void vsc9953_xmit_template_populate(struct ocelot *ocelot, int port) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net: dsa: seville: register the mdiobus under devres
by Zhengchao Shao 19 Jul '24

19 Jul '24

From: Vladimir Oltean <vladimir.oltean(a)nxp.com> mainline inclusion from mainline-v5.17-rc4 commit bd488afc3b39e045ba71aab472233f2a78726e7b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADFY0 CVE: CVE-2022-48814 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Seville VSC9959 switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the seville switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The seville driver has a code structure that could accommodate both the mdiobus_unregister and mdiobus_free calls, but it has an external dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls devm_mdiobus_alloc_size() on its behalf. So rather than restructuring that, and exporting yet one more symbol mscc_miim_teardown(), let's work with devres and replace of_mdiobus_register with the devres variant. When we use all-devres, we can ensure that devres doesn't free a still-registered bus (it either runs both callbacks, or none). Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/dsa/ocelot/seville_vsc9953.c [The conflict occurs because the commit 5186c4a05b97("net: dsa: ocelot: seville: utilize of_mdiobus_register") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/dsa/ocelot/seville_vsc9953.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/ocelot/seville_vsc9953.c b/drivers/net/dsa/ocelot/seville_vsc9953.c index 7026523f886c..81875e96096b 100644 --- a/drivers/net/dsa/ocelot/seville_vsc9953.c +++ b/drivers/net/dsa/ocelot/seville_vsc9953.c @@ -1092,7 +1092,7 @@ static int vsc9953_mdio_bus_alloc(struct ocelot *ocelot) snprintf(bus->id, MII_BUS_ID_SIZE, "%s-imdio", dev_name(dev)); /* Needed in order to initialize the bus mutex lock */ - rc = mdiobus_register(bus); + rc = devm_mdiobus_register(dev, bus); if (rc < 0) { dev_err(dev, "failed to register MDIO bus\n"); return rc; @@ -1144,7 +1144,8 @@ static void vsc9953_mdio_bus_free(struct ocelot *ocelot) mdio_device_free(pcs->mdio); lynx_pcs_destroy(pcs); } - mdiobus_unregister(felix->imdio); + + /* mdiobus_unregister and mdiobus_free handled by devres */ } static void vsc9953_xmit_template_populate(struct ocelot *ocelot, int port) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] dma-mapping: benchmark: fix node id validation
by Kaixiong Yu 19 Jul '24

19 Jul '24

From: Fedor Pchelkin <pchelkin(a)ispras.ru> stable inclusion from stable-v6.6.33 commit 34a816d8735f3924b74be8e5bf766ade1f3bd10b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DBN CVE: CVE-2024-34777 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1ff05e723f7ca30644b8ec3fb093f16312e408ad ] While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to: BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node. Found by Linux Verification Center (linuxtesting.org) Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs") Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- kernel/dma/map_benchmark.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index c2d225e1cd47..5c13c9352bb5 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -228,7 +228,8 @@ static long map_benchmark_ioctl(struct file *file, unsigned int cmd, } if (map->bparam.node != NUMA_NO_NODE && - !node_possible(map->bparam.node)) { + (map->bparam.node < 0 || map->bparam.node >= MAX_NUMNODES || + !node_possible(map->bparam.node))) { pr_err("invalid numa node\n"); return -EINVAL; } -- 2.25.1

2 1

[PATCH OLK-6.6] dma-mapping: benchmark: fix node id validation
by Kaixiong Yu 19 Jul '24

19 Jul '24

From: Fedor Pchelkin <pchelkin(a)ispras.ru> stable inclusion from stable-v6.6.33 commit 34a816d8735f3924b74be8e5bf766ade1f3bd10b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DBN CVE: CVE-2024-34777 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1ff05e723f7ca30644b8ec3fb093f16312e408ad ] While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to: BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node. Found by Linux Verification Center (linuxtesting.org) Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs") Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- kernel/dma/map_benchmark.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index 02205ab53b7e..d0955ea67a11 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -208,7 +208,8 @@ static long map_benchmark_ioctl(struct file *file, unsigned int cmd, } if (map->bparam.node != NUMA_NO_NODE && - !node_possible(map->bparam.node)) { + (map->bparam.node < 0 || map->bparam.node >= MAX_NUMNODES || + !node_possible(map->bparam.node))) { pr_err("invalid numa node\n"); return -EINVAL; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] scsi: qedi: Fix crash while reading debugfs attribute
by Wenyu Huang 19 Jul '24

19 Jul '24

From: Manish Rangankar <mrangankar(a)marvell.com> stable inclusion from stable-v4.19.317 commit 56bec63a7fc87ad50b3373a87517dc9770eef9e0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQZS CVE: CVE-2024-40978 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 28027ec8e32ecbadcd67623edb290dad61e735b5 ] The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly on a __user pointer, which results into the crash. To fix this issue, use a small local stack buffer for sprintf() and then call simple_read_from_buffer(), which in turns make the copy_to_user() call. BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d Tested-by: Martin Hoyer <mhoyer(a)redhat.com> Reviewed-by: John Meneghini <jmeneghi(a)redhat.com> Signed-off-by: Manish Rangankar <mrangankar(a)marvell.com> Link: https://lore.kernel.org/r/20240415072155.30840-1-mrangankar@marvell.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wenyu Huang <huangwenyu5(a)huawei.com> --- drivers/scsi/qedi/qedi_debugfs.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/scsi/qedi/qedi_debugfs.c b/drivers/scsi/qedi/qedi_debugfs.c index fd914ca4149a..6bb5f2b31b88 100644 --- a/drivers/scsi/qedi/qedi_debugfs.c +++ b/drivers/scsi/qedi/qedi_debugfs.c @@ -136,15 +136,11 @@ static ssize_t qedi_dbg_do_not_recover_cmd_read(struct file *filp, char __user *buffer, size_t count, loff_t *ppos) { - size_t cnt = 0; - - if (*ppos) - return 0; + char buf[64]; + int len; - cnt = sprintf(buffer, "do_not_recover=%d\n", qedi_do_not_recover); - cnt = min_t(int, count, cnt - *ppos); - *ppos += cnt; - return cnt; + len = sprintf(buf, "do_not_recover=%d\n", qedi_do_not_recover); + return simple_read_from_buffer(buffer, count, ppos, buf, len); } static int -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] xfs: fix file creation
by Long Li 19 Jul '24

19 Jul '24

This patch set fix file create fail when get wrong longest extent. Zizhi Wo (2): xfs: Fix file creation failure xfs: Fix agf_longest update error fs/xfs/libxfs/xfs_alloc.c | 14 ++++++++++++++ fs/xfs/libxfs/xfs_alloc_btree.c | 13 ++++++++++--- fs/xfs/libxfs/xfs_btree.h | 1 + 3 files changed, 25 insertions(+), 3 deletions(-) -- 2.39.2

2 3

[PATCH OLK-5.10] xfs: Fix agf_longest update error
by Long Li 19 Jul '24

19 Jul '24

From: Zizhi Wo <wozizhi(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9TDTA CVE: NA -------------------------------- A concurrent file creation and little writing could unexpectedly return -ENOSPC error since there is a race window that the allocator could get the wrong agf->agf_longest. Write file process steps: 1) Find the entry that best meets the conditions, then calculate the start address and length of the remaining part of the entry after allocation. 2) Delete this entry and update the agf->agf_longest. 3) Insert the remaining unused parts of this entry based on the calculations in 1), and update the agf->agf_longest again if necessary. Create file process steps: 1) Check whether there are free inodes in the inode chunk. 2) If there is no free inode, check whether there has space for creating inode chunks, perform the no-lock judgment first. 3) If the judgment succeeds, the judgment is performed again with agf lock held. Otherwire, an error is returned directly. If the write process is in step 2) but not go to 3) yet, the create file process goes to 2) at this time, it will be mistaken for no space, resulting in the file system still has space but the file creation fails. Because in the previous code, if numrec == 0, longest will be temporarily set to 0 in write process step 2), and we have fixed it in commit 628ab796d8b1 ("xfs: Fix file creation failure") to update the longest in advance. But we don't fix it all. If numrec is not 0 in xfs_allocbt_update_lastrec, xfs will update the agf_longest to the -current- longest node currently. However, this is not true because the value of the node may be smaller than the remaining part of the original longest extent after part of it is deleted. The agf_longest updated at this moment is not accurate. Fix it by comparing cur->bc_free_longest with the -current- longest node and taking the maximum value as the agf_longest. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 628ab796d8b1 ("xfs: Fix file creation failure") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_alloc_btree.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/fs/xfs/libxfs/xfs_alloc_btree.c b/fs/xfs/libxfs/xfs_alloc_btree.c index d6dbbe85e819..8282a171131e 100644 --- a/fs/xfs/libxfs/xfs_alloc_btree.c +++ b/fs/xfs/libxfs/xfs_alloc_btree.c @@ -141,20 +141,20 @@ xfs_allocbt_update_lastrec( return; ASSERT(ptr == numrecs + 1); + /* + * Update in advance to prevent file creation failure + * for concurrent processes even though there is no + * numrec currently. + * And there's no need to worry as the value that not + * less than bc_free_longest will be inserted later. + */ + len = cpu_to_be32(cur->bc_free_longest); if (numrecs) { xfs_alloc_rec_t *rrp; rrp = XFS_ALLOC_REC_ADDR(cur->bc_mp, block, numrecs); - len = rrp->ar_blockcount; - } else { - /* - * Update in advance to prevent file creation failure - * for concurrent processes even though there is no - * numrec currently. - * And there's no need to worry as the value that not - * less than bc_free_longest will be inserted later. - */ - len = cpu_to_be32(cur->bc_free_longest); + len = cpu_to_be32(max_t(xfs_extlen_t, cur->bc_free_longest, + be32_to_cpu(rrp->ar_blockcount))); } break; -- 2.39.2

2 1

[PATCH OLK-5.10] sched/fair: Take the scheduling domain into account in select_idle_core()
by Zheng Zucheng 19 Jul '24

19 Jul '24

From: Keisuke Nishimura <keisuke.nishimura(a)inria.fr> mainline inclusion from mainline-v6.9-rc1 commit 23d04d8c6b8ec339057264659b7834027f3e6a63 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAE7OO Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When picking a CPU on task wakeup, select_idle_core() has to take into account the scheduling domain where the function looks for the CPU. This is because the "isolcpus" kernel command line option can remove CPUs from the domain to isolate them from other SMT siblings. This change replaces the set of CPUs allowed to run the task from p->cpus_ptr by the intersection of p->cpus_ptr and sched_domain_span(sd) which is stored in the 'cpus' argument provided by select_idle_cpu(). Fixes: 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()") Signed-off-by: Keisuke Nishimura <keisuke.nishimura(a)inria.fr> Signed-off-by: Julia Lawall <julia.lawall(a)inria.fr> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://lore.kernel.org/r/20240110131707.437301-2-keisuke.nishimura@inria.fr Conflicts: kernel/sched/fair.c Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/fair.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 778fb388b2e8..95d1841f8a20 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7223,11 +7223,7 @@ static int select_idle_core(struct task_struct *p, int core, struct cpumask *cpu if (!available_idle_cpu(cpu)) { idle = false; if (*idle_cpu == -1) { -#ifdef CONFIG_TASK_PLACEMENT_BY_CPU_RANGE - if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, p->select_cpus)) { -#else - if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, p->cpus_ptr)) { -#endif + if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, cpus)) { *idle_cpu = cpu; break; } @@ -7235,7 +7231,7 @@ static int select_idle_core(struct task_struct *p, int core, struct cpumask *cpu } break; } - if (*idle_cpu == -1 && cpumask_test_cpu(cpu, p->cpus_ptr)) + if (*idle_cpu == -1 && cpumask_test_cpu(cpu, cpus)) *idle_cpu = cpu; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] net: ieee802154: at86rf230: Stop leaking skb's
by Zhengchao Shao 19 Jul '24

19 Jul '24

From: Miquel Raynal <miquel.raynal(a)bootlin.com> stable inclusion from stable-v4.19.231 commit 6312f6a53fd3ea38125dcaca5e3c9aa7d8a60cf7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADG4I CVE: CVE-2022-48794 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit e5ce576d45bf72fd0e3dc37eff897bfcc488f6a9 ] Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. In the Tx case we then leak the skb structure. Free the skb structure upon error before returning when appropriate. As the 'is_tx = 0' cannot be moved in the complete handler because of a possible race between the delay in switching to STATE_RX_AACK_ON and a new interrupt, we introduce an intermediate 'was_tx' boolean just for this purpose. There is no Fixes tag applying here, many changes have been made on this area and the issue kind of always existed. Suggested-by: Alexander Aring <alex.aring(a)gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Acked-by: Alexander Aring <aahringo(a)redhat.com> Link: https://lore.kernel.org/r/20220125121426.848337-4-miquel.raynal@bootlin.com Signed-off-by: Stefan Schmidt <stefan(a)datenfreihafen.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ieee802154/at86rf230.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c index 3d9e91579866..1bc09b6c308f 100644 --- a/drivers/net/ieee802154/at86rf230.c +++ b/drivers/net/ieee802154/at86rf230.c @@ -108,6 +108,7 @@ struct at86rf230_local { unsigned long cal_timeout; bool is_tx; bool is_tx_from_off; + bool was_tx; u8 tx_retry; struct sk_buff *tx_skb; struct at86rf230_state_change tx; @@ -351,7 +352,11 @@ at86rf230_async_error_recover_complete(void *context) if (ctx->free) kfree(ctx); - ieee802154_wake_queue(lp->hw); + if (lp->was_tx) { + lp->was_tx = 0; + dev_kfree_skb_any(lp->tx_skb); + ieee802154_wake_queue(lp->hw); + } } static void @@ -360,7 +365,11 @@ at86rf230_async_error_recover(void *context) struct at86rf230_state_change *ctx = context; struct at86rf230_local *lp = ctx->lp; - lp->is_tx = 0; + if (lp->is_tx) { + lp->was_tx = 1; + lp->is_tx = 0; + } + at86rf230_async_state_change(lp, ctx, STATE_RX_AACK_ON, at86rf230_async_error_recover_complete); } -- 2.34.1

2 1

[PATCH OLK-5.10] sched/fair: Take the scheduling domain into account in select_idle_core()
by Zheng Zucheng 19 Jul '24

19 Jul '24

From: Keisuke Nishimura <keisuke.nishimura(a)inria.fr> mainline inclusion from mainline-v6.9-rc1 commit 23d04d8c6b8ec339057264659b7834027f3e6a63 category: bugfix bugzilla: 189658 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When picking a CPU on task wakeup, select_idle_core() has to take into account the scheduling domain where the function looks for the CPU. This is because the "isolcpus" kernel command line option can remove CPUs from the domain to isolate them from other SMT siblings. This change replaces the set of CPUs allowed to run the task from p->cpus_ptr by the intersection of p->cpus_ptr and sched_domain_span(sd) which is stored in the 'cpus' argument provided by select_idle_cpu(). Fixes: 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()") Signed-off-by: Keisuke Nishimura <keisuke.nishimura(a)inria.fr> Signed-off-by: Julia Lawall <julia.lawall(a)inria.fr> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://lore.kernel.org/r/20240110131707.437301-2-keisuke.nishimura@inria.fr Conflicts: kernel/sched/fair.c Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/fair.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 778fb388b2e8..95d1841f8a20 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7223,11 +7223,7 @@ static int select_idle_core(struct task_struct *p, int core, struct cpumask *cpu if (!available_idle_cpu(cpu)) { idle = false; if (*idle_cpu == -1) { -#ifdef CONFIG_TASK_PLACEMENT_BY_CPU_RANGE - if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, p->select_cpus)) { -#else - if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, p->cpus_ptr)) { -#endif + if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, cpus)) { *idle_cpu = cpu; break; } @@ -7235,7 +7231,7 @@ static int select_idle_core(struct task_struct *p, int core, struct cpumask *cpu } break; } - if (*idle_cpu == -1 && cpumask_test_cpu(cpu, p->cpus_ptr)) + if (*idle_cpu == -1 && cpumask_test_cpu(cpu, cpus)) *idle_cpu = cpu; } -- 2.34.1

2 1

[PATCH OLK-5.10] [Backport] sched/fair: Take the scheduling domain into account in select_idle_core()
by Zheng Zucheng 19 Jul '24

19 Jul '24

From: Keisuke Nishimura <keisuke.nishimura(a)inria.fr> mainline inclusion from mainline-v6.9-rc1 commit 23d04d8c6b8ec339057264659b7834027f3e6a63 category: bugfix bugzilla: 189658 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When picking a CPU on task wakeup, select_idle_core() has to take into account the scheduling domain where the function looks for the CPU. This is because the "isolcpus" kernel command line option can remove CPUs from the domain to isolate them from other SMT siblings. This change replaces the set of CPUs allowed to run the task from p->cpus_ptr by the intersection of p->cpus_ptr and sched_domain_span(sd) which is stored in the 'cpus' argument provided by select_idle_cpu(). Fixes: 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()") Signed-off-by: Keisuke Nishimura <keisuke.nishimura(a)inria.fr> Signed-off-by: Julia Lawall <julia.lawall(a)inria.fr> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://lore.kernel.org/r/20240110131707.437301-2-keisuke.nishimura@inria.fr Conflicts: kernel/sched/fair.c Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- kernel/sched/fair.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 6e52f42d4c54c..14cdc352b6bed 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6740,11 +6740,7 @@ static int select_idle_core(struct task_struct *p, int core, struct cpumask *cpu if (!available_idle_cpu(cpu)) { idle = false; if (*idle_cpu == -1) { -#ifdef CONFIG_QOS_SCHED_DYNAMIC_AFFINITY - if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, p->select_cpus)) { -#else - if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, p->cpus_ptr)) { -#endif + if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, cpus)) { *idle_cpu = cpu; break; } @@ -6752,7 +6748,7 @@ static int select_idle_core(struct task_struct *p, int core, struct cpumask *cpu } break; } - if (*idle_cpu == -1 && cpumask_test_cpu(cpu, p->cpus_ptr)) + if (*idle_cpu == -1 && cpumask_test_cpu(cpu, cpus)) *idle_cpu = cpu; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj
by Zhang Xiaoxu 19 Jul '24

19 Jul '24

From: Miaoqian Lin <linmq006(a)gmail.com> stable inclusion from stable-v4.19.231 commit 417947891bd5ae327f15efed1a0da2b12ef24962 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADGF1 CVE: CVE-2022-48775 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8bc69f86328e87a0ffa79438430cc82f3aa6a194 ] kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()： If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info") Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> Reviewed-by: Juan Vazquez <juvazq(a)linux.microsoft.com> Link: https://lore.kernel.org/r/20220203173008.43480-1-linmq006@gmail.com Signed-off-by: Wei Liu <wei.liu(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/hv/vmbus_drv.c [LST patch b57705c0ec not merge to this branch] Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> --- drivers/hv/vmbus_drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 9aa18f387a34..796764ff8581 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -1468,8 +1468,10 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel) kobj->kset = dev->channels_kset; ret = kobject_init_and_add(kobj, &vmbus_chan_ktype, NULL, "%u", relid); - if (ret) + if (ret) { + kobject_put(kobj); return ret; + } kobject_uevent(kobj, KOBJ_ADD); -- 2.34.1

2 1

[PATCH OLK-5.10 0/1] fix CVE-2024-40915
by Lin Yujun 19 Jul '24

19 Jul '24

*** BLURB HERE *** Nam Cao (1): riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context arch/riscv/mm/pageattr.c | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/3] Part of "mm: mapcount for large folios + page_mapcount() cleanups"
by Liu Shixin 19 Jul '24

19 Jul '24

Backport three patches from series "mm: mapcount for large folios + page_mapcount() cleanups". David Hildenbrand (3): mm: allow for detecting underflows with page_mapcount() again mm/rmap: always inline anon/file rmap duplication of a single PTE mm/rmap: add fast-path for small folios when adding/removing/duplicating include/linux/mm.h | 2 +- include/linux/rmap.h | 30 ++++++++++++++++++++++++++---- mm/rmap.c | 26 ++++++++++++++++---------- 3 files changed, 43 insertions(+), 15 deletions(-) -- 2.25.1

2 4