- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] vt: fix memory overlapping when deleting chars in the buffer
by Yi Yang 06 Mar '24

06 Mar '24

From: Yangxi Xiang <xyangxi5(a)gmail.com> mainline inclusion from mainline-v5.19-rc7 commit 39cdb68c64d84e71a4a717000b6e5de208ee60cc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ATI CVE: CVE-2022-48627 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. Fixes: 81732c3b2fed ("tty vt: Fix line garbage in virtual console on command line edition") Cc: stable <stable(a)kernel.org> Signed-off-by: Yangxi Xiang <xyangxi5(a)gmail.com> Link: https://lore.kernel.org/r/20220628093322.5688-1-xyangxi5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> conflicts: drivers/tty/vt/vt.c Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/vt/vt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 20565603a365..163186cbfe79 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -855,7 +855,7 @@ static void delete_char(struct vc_data *vc, unsigned int nr) unsigned short *p = (unsigned short *) vc->vc_pos; vc_uniscr_delete(vc, nr); - scr_memcpyw(p, p + nr, (vc->vc_cols - vc->vc_x - nr) * 2); + scr_memmovew(p, p + nr, (vc->vc_cols - vc->vc_x - nr) * 2); scr_memsetw(p + vc->vc_cols - vc->vc_x - nr, vc->vc_video_erase_char, nr * 2); vc->vc_need_wrap = 0; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] nvme-loop: fix memory leak in nvme_loop_create_ctrl()
by Li Nan 06 Mar '24

06 Mar '24

From: Wu Bo <wubo40(a)huawei.com> mainline inclusion from mainline-v5.13-rc3 commit 03504e3b54cc8118cc26c064e60a0b00c2308708 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I956G7 CVE: CVE-2021-47074 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping to the "out" label. Fixes: 3a85a5de29ea ("nvme-loop: add a NVMe loopback host driver") Signed-off-by: Wu Bo <wubo40(a)huawei.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Conflict: In mainline, commit 64d452b3560b and b6cec06d19d9 changed context. Does not affect the logic of this patch. Signed-off-by: Li Nan <linan122(a)huawei.com> --- drivers/nvme/target/loop.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c index 1eee21310dee..a8d15fd6ebe9 100644 --- a/drivers/nvme/target/loop.c +++ b/drivers/nvme/target/loop.c @@ -607,8 +607,10 @@ static struct nvme_ctrl *nvme_loop_create_ctrl(struct device *dev, ret = nvme_init_ctrl(&ctrl->ctrl, dev, &nvme_loop_ctrl_ops, 0 /* no quirks, we're perfect! */); - if (ret) + if (ret) { + kfree(ctrl); goto out_put_ctrl; + } ret = -ENOMEM; -- 2.39.2

2 1

[PATCH OLK-5.10] ieee802154: ca8210: Fix a potential UAF in ca8210_probe
by Yu Liao 06 Mar '24

06 Mar '24

From: Dinghao Liu <dinghao.liu(a)zju.edu.cn> stable inclusion from stable-v5.10.199 commit 55e06850c7894f00d41b767c5f5665459f83f58f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ASM CVE: CVE-2023-52510 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit f990874b1c98fe8e57ee9385669f501822979258 ] If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Signed-off-by: Dinghao Liu <dinghao.liu(a)zju.edu.cn> Message-ID: <20231007033049.22353-1-dinghao.liu(a)zju.edu.cn> Signed-off-by: Stefan Schmidt <stefan(a)datenfreihafen.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- drivers/net/ieee802154/ca8210.c | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c index 1c5d70c60354..0ce426c0c0bf 100644 --- a/drivers/net/ieee802154/ca8210.c +++ b/drivers/net/ieee802154/ca8210.c @@ -2783,7 +2783,6 @@ static int ca8210_register_ext_clock(struct spi_device *spi) struct device_node *np = spi->dev.of_node; struct ca8210_priv *priv = spi_get_drvdata(spi); struct ca8210_platform_data *pdata = spi->dev.platform_data; - int ret = 0; if (!np) return -EFAULT; @@ -2800,18 +2799,8 @@ static int ca8210_register_ext_clock(struct spi_device *spi) dev_crit(&spi->dev, "Failed to register external clk\n"); return PTR_ERR(priv->clk); } - ret = of_clk_add_provider(np, of_clk_src_simple_get, priv->clk); - if (ret) { - clk_unregister(priv->clk); - dev_crit( - &spi->dev, - "Failed to register external clock as clock provider\n" - ); - } else { - dev_info(&spi->dev, "External clock set as clock provider\n"); - } - return ret; + return of_clk_add_provider(np, of_clk_src_simple_get, priv->clk); } /** @@ -2823,8 +2812,8 @@ static void ca8210_unregister_ext_clock(struct spi_device *spi) { struct ca8210_priv *priv = spi_get_drvdata(spi); - if (!priv->clk) - return + if (IS_ERR_OR_NULL(priv->clk)) + return; of_clk_del_provider(spi->dev.of_node); clk_unregister(priv->clk); -- 2.25.1

2 1

[PATCH OLK-5.10] net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
by Zhang Xiaoxu 06 Mar '24

06 Mar '24

From: Shigeru Yoshida <syoshida(a)redhat.com> stable inclusion from stable-v5.10.198 commit 30bc4d7aebe33904b0f2d3aad4b4a9c6029ad0c5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95AXT CVE: CVE-2023-52528 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e9c65989920f7c28775ec4e0c11b483910fb67b8 ] syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable ----buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested. Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver") Reported-and-tested-by: syzbot+6966546b78d050bb0b5d(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6966546b78d050bb0b5d Signed-off-by: Shigeru Yoshida <syoshida(a)redhat.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://lore.kernel.org/r/20230923173549.3284502-1-syoshida@redhat.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> --- drivers/net/usb/smsc75xx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c index fb1389bd0939..6310841aeac7 100644 --- a/drivers/net/usb/smsc75xx.c +++ b/drivers/net/usb/smsc75xx.c @@ -90,7 +90,9 @@ static int __must_check __smsc75xx_read_reg(struct usbnet *dev, u32 index, ret = fn(dev, USB_VENDOR_REQUEST_READ_REGISTER, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0, index, &buf, 4); - if (unlikely(ret < 0)) { + if (unlikely(ret < 4)) { + ret = ret < 0 ? ret : -ENODATA; + netdev_warn(dev->net, "Failed to read reg index 0x%08x: %d\n", index, ret); return ret; -- 2.34.1

2 1

[openeuler:OLK-6.6 2180/3862] kernel/sched/fair.c:8988:1: sparse: sparse: symbol 'qos_smt_expell_switch' was not declared. Should it be static?
by kernel test robot 06 Mar '24

06 Mar '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: f44547cb66ee30ed552adb15046a912cd1409c1f commit: a62d532da0b51fe39f726c4c08f3debc8b3bc5d7 [2180/3862] sched/fair: Add cmdline nosmtexpell config: arm64-randconfig-r111-20240227 (https://download.01.org/0day-ci/archive/20240306/202403061134.XUPVJszR-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240306/202403061134.XUPVJszR-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/202403061134.XUPVJszR-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) kernel/sched/fair.c:151:14: sparse: sparse: symbol 'sysctl_overload_detect_period' was not declared. Should it be static? kernel/sched/fair.c:152:14: sparse: sparse: symbol 'sysctl_offline_wait_interval' was not declared. Should it be static? kernel/sched/fair.c:1284:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct sched_entity const *se @@ got struct sched_entity [noderef] __rcu * @@ kernel/sched/fair.c:1284:34: sparse: expected struct sched_entity const *se kernel/sched/fair.c:1284:34: sparse: got struct sched_entity [noderef] __rcu * kernel/sched/fair.c:13325:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:13325:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:13325:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:6038:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:6038:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:6038:22: sparse: struct task_struct * kernel/sched/fair.c:6780:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:6780:38: sparse: expected struct task_struct *curr kernel/sched/fair.c:6780:38: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:8163:20: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:8163:20: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:8163:20: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:8478:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] tmp @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:8478:9: sparse: expected struct sched_domain *[assigned] tmp kernel/sched/fair.c:8478:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:8590:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:8590:38: sparse: expected struct task_struct *curr kernel/sched/fair.c:8590:38: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:8936:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:8936:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:8936:22: sparse: struct task_struct * >> kernel/sched/fair.c:8988:1: sparse: sparse: symbol 'qos_smt_expell_switch' was not declared. Should it be static? kernel/sched/fair.c:9122:51: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct task_struct *sibling_p @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:9122:51: sparse: expected struct task_struct *sibling_p kernel/sched/fair.c:9122:51: sparse: got struct task_struct [noderef] __rcu *curr kernel/sched/fair.c:9127:30: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:9127:30: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:9127:30: sparse: struct task_struct * kernel/sched/fair.c:9205:48: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct task_struct *p @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:9454:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@ kernel/sched/fair.c:10525:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct sched_domain *child @@ got struct sched_domain [noderef] __rcu *child @@ kernel/sched/fair.c:11162:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:11162:22: sparse: struct task_struct [noderef] __rcu * kernel/sched/fair.c:11162:22: sparse: struct task_struct * kernel/sched/fair.c:12603:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:12603:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:12603:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:12260:44: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct sched_domain *sd_parent @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:12260:44: sparse: expected struct sched_domain *sd_parent kernel/sched/fair.c:12260:44: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c:12699:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] __rcu *parent @@ kernel/sched/fair.c:12699:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:12699:9: sparse: got struct sched_domain [noderef] __rcu *parent kernel/sched/fair.c: note: in included file (through include/linux/rculist.h, include/linux/pid.h, include/linux/sched.h, ...): include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true include/linux/list.h:83:21: sparse: sparse: self-comparison always evaluates to true kernel/sched/fair.c: note: in included file: kernel/sched/sched.h:2182:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2182:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2182:25: sparse: struct task_struct * kernel/sched/sched.h:2346:9: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2346:9: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2346:9: sparse: struct task_struct * kernel/sched/sched.h:2346:9: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2346:9: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2346:9: sparse: struct task_struct * kernel/sched/sched.h:2182:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2182:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2182:25: sparse: struct task_struct * kernel/sched/sched.h:2182:25: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/sched.h:2182:25: sparse: struct task_struct [noderef] __rcu * kernel/sched/sched.h:2182:25: sparse: struct task_struct * vim +/qos_smt_expell_switch +8988 kernel/sched/fair.c 8986 8987 #ifdef CONFIG_QOS_SCHED_SMT_EXPELLER > 8988 DEFINE_STATIC_KEY_TRUE(qos_smt_expell_switch); 8989 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send
by Ziyang Xuan 06 Mar '24

06 Mar '24

From: Lv Yunlong <lyl2019(a)mail.ustc.edu.cn> stable inclusion from stable-v4.19.191 commit 16d8c44be52e3650917736d45f5904384a9da834 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94JI5 CVE: CVE-2021-47013 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6d72e7c767acbbdd44ebc7d89c6690b405b32b57 ] In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later. Fixes: b9b17debc69d2 ("net: emac: emac gigabit ethernet controller driver") Signed-off-by: Lv Yunlong <lyl2019(a)mail.ustc.edu.cn> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- drivers/net/ethernet/qualcomm/emac/emac-mac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c b/drivers/net/ethernet/qualcomm/emac/emac-mac.c index 031f6e6ee9c17..351a906980103 100644 --- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c +++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c @@ -1449,6 +1449,7 @@ int emac_mac_tx_buf_send(struct emac_adapter *adpt, struct emac_tx_queue *tx_q, { struct emac_tpd tpd; u32 prod_idx; + int len; memset(&tpd, 0, sizeof(tpd)); @@ -1468,9 +1469,10 @@ int emac_mac_tx_buf_send(struct emac_adapter *adpt, struct emac_tx_queue *tx_q, if (skb_network_offset(skb) != ETH_HLEN) TPD_TYP_SET(&tpd, 1); + len = skb->len; emac_tx_fill_tpd(adpt, tx_q, skb, &tpd); - netdev_sent_queue(adpt->netdev, skb->len); + netdev_sent_queue(adpt->netdev, len); /* Make sure the are enough free descriptors to hold one * maximum-sized SKB. We need one desc for each fragment, -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] i2c: img-scb: fix reference leak when pm_runtime_get_sync fails
by felix 06 Mar '24

06 Mar '24

From: Qinglang Miao <miaoqinglang(a)huawei.com> stable inclusion from stable-v5.10.37 commit e80ae8bde41266d3b8bf012460b6593851766006 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94JR1 CVE: CVE-2020-36783 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 223125e37af8a641ea4a09747a6a52172fc4b903 ] The PM reference count is not expected to be incremented on return in functions img_i2c_xfer and img_i2c_init. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 93222bd9b966 ("i2c: img-scb: Add runtime PM") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> Signed-off-by: Wolfram Sang <wsa(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/i2c/busses/i2c-img-scb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-img-scb.c b/drivers/i2c/busses/i2c-img-scb.c index f038858b6c54..fecafb6493e2 100644 --- a/drivers/i2c/busses/i2c-img-scb.c +++ b/drivers/i2c/busses/i2c-img-scb.c @@ -1060,7 +1060,7 @@ static int img_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, atomic = true; } - ret = pm_runtime_get_sync(adap->dev.parent); + ret = pm_runtime_resume_and_get(adap->dev.parent); if (ret < 0) return ret; @@ -1161,7 +1161,7 @@ static int img_i2c_init(struct img_i2c *i2c) u32 rev; int ret; - ret = pm_runtime_get_sync(i2c->adap.dev.parent); + ret = pm_runtime_resume_and_get(i2c->adap.dev.parent); if (ret < 0) return ret; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] soundwire: stream: fix memory leak in stream config error path
by Zhu Wang 06 Mar '24

06 Mar '24

mainline inclusion from mainline-v5.13-rc1 commit 48f17f96a81763c7c8bf5500460a359b9939359f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94VOP CVE: CVE-2021-47020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When stream config is failed, master runtime will release all slave runtime in the slave_rt_list, but slave runtime is not added to the list at this time. This patch frees slave runtime in the config error path to fix the memory leak. Fixes: 89e590535f32 ("soundwire: Add support for SoundWire stream management") Signed-off-by: Rander Wang <rander.wang(a)intel.com> Reviewed-by: Keyon Jie <yang.jie(a)intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Link: https://lore.kernel.org/r/20210331004610.12242-1-yung-chuan.liao@linux.inte… Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Zhu Wang <wangzhu9(a)huawei.com> --- drivers/soundwire/stream.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 907a548645b7..42bc701e2304 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -1182,8 +1182,16 @@ int sdw_stream_add_slave(struct sdw_slave *slave, } ret = sdw_config_stream(&slave->dev, stream, stream_config, true); - if (ret) + if (ret) { + /* + * sdw_release_master_stream will release s_rt in slave_rt_list in + * stream_error case, but s_rt is only added to slave_rt_list + * when sdw_config_stream is successful, so free s_rt explicitly + * when sdw_config_stream is failed. + */ + kfree(s_rt); goto stream_error; + } list_add_tail(&s_rt->m_rt_node, &m_rt->slave_rt_list); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
by Zhang Xiaoxu 06 Mar '24

06 Mar '24

From: Shigeru Yoshida <syoshida(a)redhat.com> stable inclusion from stable-v4.19.296 commit 2a36d9e2995c8c3c3f179aab1215a69cff06cbed category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95AXT CVE: CVE-2023-52528 -------------------------------- [ Upstream commit e9c65989920f7c28775ec4e0c11b483910fb67b8 ] syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable ----buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested. Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver") Reported-and-tested-by: syzbot+6966546b78d050bb0b5d(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6966546b78d050bb0b5d Signed-off-by: Shigeru Yoshida <syoshida(a)redhat.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://lore.kernel.org/r/20230923173549.3284502-1-syoshida@redhat.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> --- drivers/net/usb/smsc75xx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c index ec287c9741e8..ef8589e3a6d1 100644 --- a/drivers/net/usb/smsc75xx.c +++ b/drivers/net/usb/smsc75xx.c @@ -102,7 +102,9 @@ static int __must_check __smsc75xx_read_reg(struct usbnet *dev, u32 index, ret = fn(dev, USB_VENDOR_REQUEST_READ_REGISTER, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0, index, &buf, 4); - if (unlikely(ret < 0)) { + if (unlikely(ret < 4)) { + ret = ret < 0 ? ret : -ENODATA; + netdev_warn(dev->net, "Failed to read reg index 0x%08x: %d\n", index, ret); return ret; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 13475/21720] net/can/j1939/main.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 06 Mar '24

06 Mar '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: ba030414a07b34111e8786469740412351906964 commit: e0c2ee9edcacfdda0e806166eaec1310cdf9e324 [13475/21720] can: add support of SAE J1939 protocol config: x86_64-buildonly-randconfig-003-20240224 (https://download.01.org/0day-ci/archive/20240306/202403061005.3SMjwiSq-lkp@…) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240306/202403061005.3SMjwiSq-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/202403061005.3SMjwiSq-lkp@intel.com/ All warnings (new ones prefixed by >>): >> net/can/j1939/main.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0