- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] ftrace: Use preempt disable instead of rcu lock in ftrace_location_range()
by Zheng Yejian 06 Jul '24

06 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAA3U5 CVE: NA -------------------------------- After commit 5e66a5bdad69 ("ftrace: Fix rcu warn in ftrace_location()"), syzkaller reports following warning: WARNING: lock held when returning to user space! 4.18.0+ #16 Tainted: G W ---------r- - ------------------------------------------------ modprobe/4255 is leaving the kernel with locks still held! 1 lock held by modprobe/4255: #0: 0000000012ba3568 (rcu_read_lock){....}, at: ftrace_location_range+0x292/0x440 BUG: scheduling while atomic: modprobe/4255/0x00000002 ============================= BUG: scheduling while atomic: modprobe/4256/0x00000002 INFO: lockdep is turned off. Modules linked in: Kernel panic - not syncing: scheduling while atomic It seems that rcu_read_lock() is held but rcu_read_unlock() is not called, this is most likely due to the inconsistent state when calling in_atomic(). To fix it, use preemt_{disable,enable}_notrace() instead of rcu_read_{,un}lock(). Fixes: 5e66a5bdad69 ("ftrace: Fix rcu warn in ftrace_location()") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/ftrace.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index ad4440da5b78..ceb4bab432f1 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1581,12 +1581,7 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) key.ip = start; key.flags = end; /* overload flags, as it is unsigned long */ - /* - * It is in atomic context when called from ftrace_int3_handler(), - * in this case rcu lock is not needed. - */ - if (!in_atomic()) - rcu_read_lock(); + preempt_disable_notrace(); for (pg = ftrace_pages_start; pg; pg = pg->next) { if (pg->index == 0 || end < pg->records[0].ip || @@ -1600,8 +1595,7 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) break; } } - if (!in_atomic()) - rcu_read_unlock(); + preempt_enable_notrace(); return ip; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] sch_cake: do not call cake_destroy() from cake_init()
by Xiang Yang 06 Jul '24

06 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.222 commit 4e388232e630ebe4f94b4a0715ec98c0e2b314a3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGX CVE: CVE-2021-47598 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit ab443c53916730862cec202078d36fd4008bea79 ] qdiscs are not supposed to call their own destroy() method from init(), because core stack already does that. syzbot was able to trigger use after free: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline] WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 Modules linked in: CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline] RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 Code: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8 RSP: 0018:ffffc9000627f290 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44 RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000 FS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0 Call Trace: <TASK> tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810 tcf_block_put_ext net/sched/cls_api.c:1381 [inline] tcf_block_put_ext net/sched/cls_api.c:1376 [inline] tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394 cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695 qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293 tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f1bb06badb9 Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f. RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9 RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003 R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688 R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2 </TASK> Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Link: https://lore.kernel.org/r/20211210142046.698336-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- net/sched/sch_cake.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c index 2025f0f559de..18c207b85d51 100644 --- a/net/sched/sch_cake.c +++ b/net/sched/sch_cake.c @@ -2675,7 +2675,7 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt, q->tins = kvcalloc(CAKE_MAX_TINS, sizeof(struct cake_tin_data), GFP_KERNEL); if (!q->tins) - goto nomem; + return -ENOMEM; for (i = 0; i < CAKE_MAX_TINS; i++) { struct cake_tin_data *b = q->tins + i; @@ -2705,10 +2705,6 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt, q->min_netlen = ~0; q->min_adjlen = ~0; return 0; - -nomem: - cake_destroy(sch); - return -ENOMEM; } static int cake_dump(struct Qdisc *sch, struct sk_buff *skb) -- 2.34.1

2 1

[PATCH OLK-5.10] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
by Zheng Zucheng 06 Jul '24

06 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit dcf53e6103b26e7458be71491d0641f49fbd5840 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEW CVE: CVE-2024-38548 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ] In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Robert Foss <rfoss(a)kernel.org> Signed-off-by: Robert Foss <rfoss(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c index 6af565ac307a..858f5b650849 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c @@ -2057,6 +2057,9 @@ static void cdns_mhdp_atomic_enable(struct drm_bridge *bridge, mhdp_state = to_cdns_mhdp_bridge_state(new_state); mhdp_state->current_mode = drm_mode_duplicate(bridge->dev, mode); + if (!mhdp_state->current_mode) + return; + drm_mode_set_name(mhdp_state->current_mode); dev_dbg(mhdp->dev, "%s: Enabling mode %s\n", __func__, mode->name); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
by Zheng Zucheng 06 Jul '24

06 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit dcf53e6103b26e7458be71491d0641f49fbd5840 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEW CVE: CVE-2024-38548 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ] In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Robert Foss <rfoss(a)kernel.org> Signed-off-by: Robert Foss <rfoss(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c index 6af565ac307a..858f5b650849 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c @@ -2057,6 +2057,9 @@ static void cdns_mhdp_atomic_enable(struct drm_bridge *bridge, mhdp_state = to_cdns_mhdp_bridge_state(new_state); mhdp_state->current_mode = drm_mode_duplicate(bridge->dev, mode); + if (!mhdp_state->current_mode) + return; + drm_mode_set_name(mhdp_state->current_mode); dev_dbg(mhdp->dev, "%s: Enabling mode %s\n", __func__, mode->name); -- 2.34.1

2 1

[PATCH OLK-6.6] drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
by Zheng Zucheng 06 Jul '24

06 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit dcf53e6103b26e7458be71491d0641f49fbd5840 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEW CVE: CVE-2024-38548 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ] In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Robert Foss <rfoss(a)kernel.org> Signed-off-by: Robert Foss <rfoss(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c index 6af565ac307a..858f5b650849 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c @@ -2057,6 +2057,9 @@ static void cdns_mhdp_atomic_enable(struct drm_bridge *bridge, mhdp_state = to_cdns_mhdp_bridge_state(new_state); mhdp_state->current_mode = drm_mode_duplicate(bridge->dev, mode); + if (!mhdp_state->current_mode) + return; + drm_mode_set_name(mhdp_state->current_mode); dev_dbg(mhdp->dev, "%s: Enabling mode %s\n", __func__, mode->name); -- 2.34.1

2 1

[PATCH OLK-5.10 v3] net: fix one NULL pointer dereference bug in net_rship module
by Liu Jian 06 Jul '24

06 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAZJ8 -------------------------------- The call trace as below: Call trace: __netdev_alloc_skb+0x8c/0x1e0 ad_lacpdu_send+0x34/0x18c [bonding] ad_tx_machine+0xcc/0x174 [bonding] bond_3ad_state_machine_handler+0x120/0x470 [bonding] process_one_work+0x1d8/0x4e0 worker_thread+0x154/0x420 kthread+0x108/0x150 ret_from_fork+0x10/0x18 It is caused by null pointer dereference in net_rship module. The code path is as follows: ad_lacpdu_send dev_alloc_skb netdev_alloc_skb(NULL, length) // dev is NULL __netdev_alloc_skb(dev, length, GFP_ATOMIC) net_rship_skb_record_dev_rxinfo(skb, dev) // here dereference dev, it is NULL pointer, trigger issue. So we should add null pointer check to avoid the issue. Fixes: 64ba5634c4c6 ("net: add some bpf hooks in tcp stack for network numa relationship") Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- include/net/net_rship.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/net/net_rship.h b/include/net/net_rship.h index ad8af5a5cb9b..dda4dd732bd0 100644 --- a/include/net/net_rship.h +++ b/include/net/net_rship.h @@ -222,6 +222,9 @@ static inline void net_rship_skb_record_dev_rxinfo(struct sk_buff *skb, struct n if (gnet_bpf_enabled(GNET_RCV_NIC_NODE)) { struct sched_net_rship_skb *ext = __get_skb_net_rship(skb); + if (!dev) + return; + ext->rx_dev_idx = dev->ifindex; ext->rx_dev_net_cookie = dev_net(dev)->net_cookie; } -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 4949c9455d5ad3ecd338b3fe8c5aafe54dfeacda
by kernel test robot 06 Jul '24

06 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 4949c9455d5ad3ecd338b3fe8c5aafe54dfeacda !9786 drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable() elapsed time: 733m 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 gcc-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 gcc-13.2.0 arm64 randconfig-002-20240705 gcc-13.2.0 arm64 randconfig-003-20240705 gcc-13.2.0 arm64 randconfig-004-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 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 ea4dd5f0e87fde262e6fa081be0fb7f9e103057f
by kernel test robot 06 Jul '24

06 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: ea4dd5f0e87fde262e6fa081be0fb7f9e103057f !9649 f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode() Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag `-- x86_64-randconfig-014-20240705 |-- crypto-asymmetric_keys-pgp_public_key.c:(.text):undefined-reference-to-public_key_subtype |-- ld:crypto-asymmetric_keys-pgp_public_key.c:(.text):undefined-reference-to-public_key_free `-- ld:crypto-asymmetric_keys-pgp_public_key.c:(.text):undefined-reference-to-public_key_subtype elapsed time: 730m configs tested: 38 configs skipped: 123 tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 loongarch allmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch randconfig-001-20240705 gcc-13.2.0 loongarch randconfig-002-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 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 3486fdb9082a474750f2067f80fb835c2f480a18
by kernel test robot 06 Jul '24

06 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 3486fdb9082a474750f2067f80fb835c2f480a18 !9373 ALSA: core: Fix NULL module pointer assignment at card init Warning ids grouped by kconfigs: recent_errors `-- x86_64-allnoconfig `-- drivers-arm-spe-spe.c:linux-perf-arm_pmu.h-is-included-more-than-once. elapsed time: 729m 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-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 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 openEuler-22.03-LTS-SP1 0/3] CVE-2024-27017
by Wang Hai 05 Jul '24

05 Jul '24

CVE-2024-27017 Pablo Neira Ayuso (3): netfilter: nft_set_pipapo: .walk does not deal with generations netfilter: nft_set_pipapo: walk over current view on netlink dump netfilter: nf_tables: missing iterator type in lookup walk include/net/netfilter/nf_tables.h | 13 +++++++++++++ net/netfilter/nf_tables_api.c | 6 ++++++ net/netfilter/nft_lookup.c | 1 + net/netfilter/nft_set_pipapo.c | 8 +++++++- 4 files changed, 27 insertions(+), 1 deletion(-) -- 2.17.1

2 4

[PATCH openEuler-22.03-LTS-SP1] clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
by Wang Hai 05 Jul '24

05 Jul '24

From: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> stable inclusion from stable-v5.10.201 commit 3994387ba3564976731179c4d4a6d7850ddda71a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFZV CVE: CVE-2023-52873 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f57f78fbacf630430bf954e5a84caafdfea30c0 ] Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support") Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> Link: https://lore.kernel.org/r/20230912093407.21505-2-jiasheng@iscas.ac.cn Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Signed-off-by: Stephen Boyd <sboyd(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/clk/mediatek/clk-mt6779.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/clk/mediatek/clk-mt6779.c b/drivers/clk/mediatek/clk-mt6779.c index 6e0d3a166729..cf720651fc53 100644 --- a/drivers/clk/mediatek/clk-mt6779.c +++ b/drivers/clk/mediatek/clk-mt6779.c @@ -1216,6 +1216,8 @@ static int clk_mt6779_apmixed_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK); + if (!clk_data) + return -ENOMEM; mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data); @@ -1236,6 +1238,8 @@ static int clk_mt6779_top_probe(struct platform_device *pdev) return PTR_ERR(base); clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK); + if (!clk_data) + return -ENOMEM; mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks), clk_data); -- 2.17.1

2 1

[PATCH OLK-5.10 v2] net: fix one NULL pointer dereference bug in net_rship module
by Liu Jian 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAZJ8 -------------------------------- The call trace as below: Call trace: __netdev_alloc_skb+0x8c/0x1e0 ad_lacpdu_send+0x34/0x18c [bonding] ad_tx_machine+0xcc/0x174 [bonding] bond_3ad_state_machine_handler+0x120/0x470 [bonding] process_one_work+0x1d8/0x4e0 worker_thread+0x154/0x420 kthread+0x108/0x150 ret_from_fork+0x10/0x18 Fixes: 64ba5634c4c6 ("net: add some bpf hooks in tcp stack for network numa relationship") Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- include/net/net_rship.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/net/net_rship.h b/include/net/net_rship.h index ad8af5a5cb9b..dda4dd732bd0 100644 --- a/include/net/net_rship.h +++ b/include/net/net_rship.h @@ -222,6 +222,9 @@ static inline void net_rship_skb_record_dev_rxinfo(struct sk_buff *skb, struct n if (gnet_bpf_enabled(GNET_RCV_NIC_NODE)) { struct sched_net_rship_skb *ext = __get_skb_net_rship(skb); + if (!dev) + return; + ext->rx_dev_idx = dev->ifindex; ext->rx_dev_net_cookie = dev_net(dev)->net_cookie; } -- 2.34.1

2 1

[openeuler:OLK-6.6 3342/10589] crypto/asymmetric_keys/pgp_public_key.c:359:undefined reference to `public_key_subtype'
by kernel test robot 05 Jul '24

05 Jul '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 17b5ba51d6bc20767e5e5c03df0acf15609b6d11 commit: 43d4042e06d2bf96adf67d25e8d91653507a4cf9 [3342/10589] KEYS: Provide a function to load keys from a PGP keyring blob config: x86_64-randconfig-014-20240705 (https://download.01.org/0day-ci/archive/20240705/202407051911.Va4emssv-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/20240705/202407051911.Va4emssv-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/202407051911.Va4emssv-lkp@intel.com/ All errors (new ones prefixed by >>): ld: vmlinux.o: in function `pgp_key_parse': >> crypto/asymmetric_keys/pgp_public_key.c:359:(.text+0x1b11e1c): undefined reference to `public_key_subtype' >> ld: crypto/asymmetric_keys/pgp_public_key.c:359:(.text+0x1b11e3b): undefined reference to `public_key_subtype' ld: crypto/asymmetric_keys/pgp_public_key.c:360:(.text+0x1b11e67): undefined reference to `public_key_subtype' >> ld: crypto/asymmetric_keys/pgp_public_key.c:369:(.text+0x1b11f38): undefined reference to `public_key_free' ld: crypto/asymmetric_keys/pgp_public_key.c:359:(.text+0x1b11fbf): undefined reference to `public_key_subtype' Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for PGP_KEY_PARSER Depends on [n]: CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=y] && ASYMMETRIC_PUBLIC_KEY_SUBTYPE [=n] Selected by [y]: - PGP_PRELOAD [=y] && CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=y] vim +359 crypto/asymmetric_keys/pgp_public_key.c 4e59d757dc3f7f Roberto Sassu 2023-09-12 300 4e59d757dc3f7f Roberto Sassu 2023-09-12 301 /* 4e59d757dc3f7f Roberto Sassu 2023-09-12 302 * Attempt to parse the instantiation data blob for a key as a PGP packet 4e59d757dc3f7f Roberto Sassu 2023-09-12 303 * message holding a key. 4e59d757dc3f7f Roberto Sassu 2023-09-12 304 */ 4e59d757dc3f7f Roberto Sassu 2023-09-12 305 static int pgp_key_parse(struct key_preparsed_payload *prep) 4e59d757dc3f7f Roberto Sassu 2023-09-12 306 { 4e59d757dc3f7f Roberto Sassu 2023-09-12 307 struct pgp_key_data_parse_context ctx; 4e59d757dc3f7f Roberto Sassu 2023-09-12 308 int ret; 4e59d757dc3f7f Roberto Sassu 2023-09-12 309 4e59d757dc3f7f Roberto Sassu 2023-09-12 310 kenter(""); 4e59d757dc3f7f Roberto Sassu 2023-09-12 311 4e59d757dc3f7f Roberto Sassu 2023-09-12 312 memset(&ctx, 0, sizeof(ctx)); e8c01f299ab793 David Howells 2023-09-12 313 ctx.pgp.types_of_interest = (1 << PGP_PKT_PUBLIC_KEY) | e8c01f299ab793 David Howells 2023-09-12 314 (1 << PGP_PKT_USER_ID); 4e59d757dc3f7f Roberto Sassu 2023-09-12 315 ctx.pgp.process_packet = pgp_process_public_key; 4e59d757dc3f7f Roberto Sassu 2023-09-12 316 4e59d757dc3f7f Roberto Sassu 2023-09-12 317 ret = pgp_parse_packets(prep->data, prep->datalen, &ctx.pgp); 4e59d757dc3f7f Roberto Sassu 2023-09-12 318 if (ret < 0) 4e59d757dc3f7f Roberto Sassu 2023-09-12 319 goto error; 4e59d757dc3f7f Roberto Sassu 2023-09-12 320 e8c01f299ab793 David Howells 2023-09-12 321 if (!ctx.fingerprint) { e8c01f299ab793 David Howells 2023-09-12 322 ret = -EINVAL; e8c01f299ab793 David Howells 2023-09-12 323 goto error; e8c01f299ab793 David Howells 2023-09-12 324 } e8c01f299ab793 David Howells 2023-09-12 325 e8c01f299ab793 David Howells 2023-09-12 326 if (ctx.user_id && ctx.user_id_len > 0) { e8c01f299ab793 David Howells 2023-09-12 327 /* Propose a description for the key e8c01f299ab793 David Howells 2023-09-12 328 * (user ID without the comment) e8c01f299ab793 David Howells 2023-09-12 329 */ e8c01f299ab793 David Howells 2023-09-12 330 size_t ulen = ctx.user_id_len, flen = ctx.fingerprint_len; e8c01f299ab793 David Howells 2023-09-12 331 const char *p; e8c01f299ab793 David Howells 2023-09-12 332 e8c01f299ab793 David Howells 2023-09-12 333 p = memchr(ctx.user_id, '(', ulen); e8c01f299ab793 David Howells 2023-09-12 334 if (p) { e8c01f299ab793 David Howells 2023-09-12 335 /* Remove the comment */ e8c01f299ab793 David Howells 2023-09-12 336 do { e8c01f299ab793 David Howells 2023-09-12 337 p--; e8c01f299ab793 David Howells 2023-09-12 338 } while (*p == ' ' && p > ctx.user_id); e8c01f299ab793 David Howells 2023-09-12 339 if (*p != ' ') e8c01f299ab793 David Howells 2023-09-12 340 p++; e8c01f299ab793 David Howells 2023-09-12 341 ulen = p - ctx.user_id; e8c01f299ab793 David Howells 2023-09-12 342 } e8c01f299ab793 David Howells 2023-09-12 343 e8c01f299ab793 David Howells 2023-09-12 344 if (ulen > 255 - 9) e8c01f299ab793 David Howells 2023-09-12 345 ulen = 255 - 9; e8c01f299ab793 David Howells 2023-09-12 346 prep->description = kmalloc(ulen + 1 + 8 + 1, GFP_KERNEL); e8c01f299ab793 David Howells 2023-09-12 347 ret = -ENOMEM; e8c01f299ab793 David Howells 2023-09-12 348 if (!prep->description) e8c01f299ab793 David Howells 2023-09-12 349 goto error; e8c01f299ab793 David Howells 2023-09-12 350 memcpy(prep->description, ctx.user_id, ulen); e8c01f299ab793 David Howells 2023-09-12 351 prep->description[ulen] = ' '; e8c01f299ab793 David Howells 2023-09-12 352 memcpy(prep->description + ulen + 1, e8c01f299ab793 David Howells 2023-09-12 353 ctx.fingerprint + flen - 8, 8); e8c01f299ab793 David Howells 2023-09-12 354 prep->description[ulen + 9] = 0; e8c01f299ab793 David Howells 2023-09-12 355 pr_debug("desc '%s'\n", prep->description); e8c01f299ab793 David Howells 2023-09-12 356 } e8c01f299ab793 David Howells 2023-09-12 357 4e59d757dc3f7f Roberto Sassu 2023-09-12 358 /* We're pinning the module by being linked against it */ 4e59d757dc3f7f Roberto Sassu 2023-09-12 @359 __module_get(public_key_subtype.owner); 4e59d757dc3f7f Roberto Sassu 2023-09-12 360 prep->payload.data[asym_subtype] = &public_key_subtype; 4e59d757dc3f7f Roberto Sassu 2023-09-12 361 prep->payload.data[asym_key_ids] = pgp_key_generate_id(&ctx); 4e59d757dc3f7f Roberto Sassu 2023-09-12 362 prep->payload.data[asym_crypto] = ctx.pub; 4e59d757dc3f7f Roberto Sassu 2023-09-12 363 prep->quotalen = 100; 4e59d757dc3f7f Roberto Sassu 2023-09-12 364 kfree(ctx.fingerprint); 4e59d757dc3f7f Roberto Sassu 2023-09-12 365 kfree(ctx.raw_fingerprint); 4e59d757dc3f7f Roberto Sassu 2023-09-12 366 return 0; 4e59d757dc3f7f Roberto Sassu 2023-09-12 367 4e59d757dc3f7f Roberto Sassu 2023-09-12 368 error: 4e59d757dc3f7f Roberto Sassu 2023-09-12 @369 public_key_free(ctx.pub); 4e59d757dc3f7f Roberto Sassu 2023-09-12 370 kfree(ctx.fingerprint); 4e59d757dc3f7f Roberto Sassu 2023-09-12 371 kfree(ctx.raw_fingerprint); 4e59d757dc3f7f Roberto Sassu 2023-09-12 372 return ret; 4e59d757dc3f7f Roberto Sassu 2023-09-12 373 } 4e59d757dc3f7f Roberto Sassu 2023-09-12 374 :::::: The code at line 359 was first introduced by commit :::::: 4e59d757dc3f7f2e2a646a2e3f0f271ae4599eeb KEYS: PGP data parser :::::: TO: Roberto Sassu <roberto.sassu(a)huawei.com> :::::: CC: zgzxx <zhangguangzhi3(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] net: fix wrong return value in bpf_sock_ops_get_uid_gid
by Liu Jian 05 Jul '24

05 Jul '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I8KU3B CVE: NA -------------------------------- We should return 0 on success. Fixes: e62b4a1c5593 ("bpf: Add bpf_get_sockops_uid_gid helper function") Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/core/filter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/filter.c b/net/core/filter.c index 6ec353bf36f3..c88f51f7d3f9 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -5675,7 +5675,7 @@ static int bpf_sock_ops_get_uid_gid(struct bpf_sock_ops_kern *bpf_sock, *(u32 *)optval = from_kgid_munged(sock_net(sk)->user_ns, gid); *((u32 *)optval + 1) = from_kuid_munged(sock_net(sk)->user_ns, uid); - return sizeof(u64); + return 0; } static int bpf_sk_original_addr(struct bpf_sock_ops_kern *bpf_sock, -- 2.34.1

2 1

[PATCH OLK-5.10] net: fix one NULL pointer dereference bug in net_rship module
by Liu Jian 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAZJ8 -------------------------------- The call trace as below: Call trace: __netdev_alloc_skb+0x8c/0x1e0 ad_lacpdu_send+0x34/0x18c [bonding] ad_tx_machine+0xcc/0x174 [bonding] bond_3ad_state_machine_handler+0x120/0x470 [bonding] process_one_work+0x1d8/0x4e0 worker_thread+0x154/0x420 kthread+0x108/0x150 ret_from_fork+0x10/0x18 Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- include/net/net_rship.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/net/net_rship.h b/include/net/net_rship.h index ad8af5a5cb9b..dda4dd732bd0 100644 --- a/include/net/net_rship.h +++ b/include/net/net_rship.h @@ -222,6 +222,9 @@ static inline void net_rship_skb_record_dev_rxinfo(struct sk_buff *skb, struct n if (gnet_bpf_enabled(GNET_RCV_NIC_NODE)) { struct sched_net_rship_skb *ext = __get_skb_net_rship(skb); + if (!dev) + return; + ext->rx_dev_idx = dev->ifindex; ext->rx_dev_net_cookie = dev_net(dev)->net_cookie; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()
by Hui Tang 05 Jul '24

05 Jul '24

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v6.6-rc1 commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917IV CVE: CVE-2024-22386 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ----------------------------------- The variable crtc->state->event is often protected by the lock crtc->dev->event_lock when is accessed. However, it is accessed as a condition of an if statement in exynos_drm_crtc_atomic_disable() without holding the lock: if (crtc->state->event && !crtc->state->active) However, if crtc->state->event is changed to NULL by another thread right after the conditions of the if statement is checked to be true, a null-pointer dereference can occur in drm_crtc_send_vblank_event(): e->pipe = pipe; To fix this possible null-pointer dereference caused by data race, the spin lock coverage is extended to protect the if statement as well as the function call to drm_crtc_send_vblank_event(). Reported-by: BassCheck <bass(a)buaa.edu.cn> Link: https://sites.google.com/view/basscheck/home Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Added relevant link. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 2696289ecc78..b3e23ace5869 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -43,13 +43,12 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc *crtc, if (exynos_crtc->ops->disable) exynos_crtc->ops->disable(exynos_crtc); + spin_lock_irq(&crtc->dev->event_lock); if (crtc->state->event && !crtc->state->active) { - spin_lock_irq(&crtc->dev->event_lock); drm_crtc_send_vblank_event(crtc, crtc->state->event); - spin_unlock_irq(&crtc->dev->event_lock); - crtc->state->event = NULL; } + spin_unlock_irq(&crtc->dev->event_lock); } static int exynos_crtc_atomic_check(struct drm_crtc *crtc, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()
by Hui Tang 05 Jul '24

05 Jul '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v6.6-rc1 commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917IV CVE: CVE-2024-22386 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- The variable crtc->state->event is often protected by the lock crtc->dev->event_lock when is accessed. However, it is accessed as a condition of an if statement in exynos_drm_crtc_atomic_disable() without holding the lock: if (crtc->state->event && !crtc->state->active) However, if crtc->state->event is changed to NULL by another thread right after the conditions of the if statement is checked to be true, a null-pointer dereference can occur in drm_crtc_send_vblank_event(): e->pipe = pipe; To fix this possible null-pointer dereference caused by data race, the spin lock coverage is extended to protect the if statement as well as the function call to drm_crtc_send_vblank_event(). Reported-by: BassCheck <bass(a)buaa.edu.cn> Link: https://sites.google.com/view/basscheck/home Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Added relevant link. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 2696289ecc78..b3e23ace5869 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -43,13 +43,12 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc *crtc, if (exynos_crtc->ops->disable) exynos_crtc->ops->disable(exynos_crtc); + spin_lock_irq(&crtc->dev->event_lock); if (crtc->state->event && !crtc->state->active) { - spin_lock_irq(&crtc->dev->event_lock); drm_crtc_send_vblank_event(crtc, crtc->state->event); - spin_unlock_irq(&crtc->dev->event_lock); - crtc->state->event = NULL; } + spin_unlock_irq(&crtc->dev->event_lock); } static int exynos_crtc_atomic_check(struct drm_crtc *crtc, -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/3] CVE-2024-38598
by Li Nan 05 Jul '24

05 Jul '24

Li Nan (2): Revert "md/raid10: fix slab-out-of-bounds in md_bitmap_get_counter" md/raid10: check slab-out-of-bounds in md_bitmap_get_counter Yu Kuai (1): md: fix resync softlockup when bitmap size is less than array size drivers/md/md-bitmap.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.39.2

2 4

[PATCH OLK-5.10 0/3] CVE-2024-38598
by Li Nan 05 Jul '24

05 Jul '24

Li Nan (2): Revert "md/raid10: fix slab-out-of-bounds in md_bitmap_get_counter" md/raid10: check slab-out-of-bounds in md_bitmap_get_counter Yu Kuai (1): md: fix resync softlockup when bitmap size is less than array size drivers/md/md-bitmap.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) -- 2.39.2

2 4

[OLK-6.6] usb-storage: alauda: Check whether the media is initialized
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Shichao Lai <shichaorai(a)gmail.com> mainline inclusion from mainline-v6.10-rc4 commit 16637fea001ab3c8df528a8995b3211906165a30 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6YQV CVE: CVE-2024-38619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Shichao Lai <shichaorai(a)gmail.com> Link: https://lore.kernel.org/r/20240526012745.2852061-1-shichaorai@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/usb/storage/alauda.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c index 115f05a6201a..40d34cc28344 100644 --- a/drivers/usb/storage/alauda.c +++ b/drivers/usb/storage/alauda.c @@ -105,6 +105,8 @@ struct alauda_info { unsigned char sense_key; unsigned long sense_asc; /* additional sense code */ unsigned long sense_ascq; /* additional sense code qualifier */ + + bool media_initialized; }; #define short_pack(lsb,msb) ( ((u16)(lsb)) | ( ((u16)(msb))<<8 ) ) @@ -476,11 +478,12 @@ static int alauda_check_media(struct us_data *us) } /* Check for media change */ - if (status[0] & 0x08) { + if (status[0] & 0x08 || !info->media_initialized) { usb_stor_dbg(us, "Media change detected\n"); alauda_free_maps(&MEDIA_INFO(us)); - alauda_init_media(us); - + rc = alauda_init_media(us); + if (rc == USB_STOR_TRANSPORT_GOOD) + info->media_initialized = true; info->sense_key = UNIT_ATTENTION; info->sense_asc = 0x28; info->sense_ascq = 0x00; -- 2.25.1

1 0

[openEuler-22.03-LTS-SP1] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

1 0

[OLK-5.10] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

1 0

[PATCH OLK-6.6] usb-storage: alauda: Check whether the media is initialized
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Shichao Lai <shichaorai(a)gmail.com> mainline inclusion from mainline-v6.10-rc4 commit 16637fea001ab3c8df528a8995b3211906165a30 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6YQV CVE: CVE-2024-38619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support") Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Shichao Lai <shichaorai(a)gmail.com> Link: https://lore.kernel.org/r/20240526012745.2852061-1-shichaorai@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/usb/storage/alauda.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c index 115f05a6201a..40d34cc28344 100644 --- a/drivers/usb/storage/alauda.c +++ b/drivers/usb/storage/alauda.c @@ -105,6 +105,8 @@ struct alauda_info { unsigned char sense_key; unsigned long sense_asc; /* additional sense code */ unsigned long sense_ascq; /* additional sense code qualifier */ + + bool media_initialized; }; #define short_pack(lsb,msb) ( ((u16)(lsb)) | ( ((u16)(msb))<<8 ) ) @@ -476,11 +478,12 @@ static int alauda_check_media(struct us_data *us) } /* Check for media change */ - if (status[0] & 0x08) { + if (status[0] & 0x08 || !info->media_initialized) { usb_stor_dbg(us, "Media change detected\n"); alauda_free_maps(&MEDIA_INFO(us)); - alauda_init_media(us); - + rc = alauda_init_media(us); + if (rc == USB_STOR_TRANSPORT_GOOD) + info->media_initialized = true; info->sense_key = UNIT_ATTENTION; info->sense_asc = 0x28; info->sense_ascq = 0x00; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

2 1

[PATCH OLK-5.10] ksmbd: fix wrong DataOffset validation of create context
by Jinjiang Tu 05 Jul '24

05 Jul '24

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.6-rc1 commit 17d5b135bb720832364e8f55f6a887a3c7ec8fdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAAVBH CVE: CVE-2023-4458 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If ->DataOffset of create context is 0, DataBuffer size is not correctly validated. This patch change wrong validation code and consider tag length in request. Cc: stable(a)vger.kernel.org Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-21824 Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/oplock.c fs/smb/server/oplock.c [oplock.c hasn't moved from fs/ksmbd to fs/smb/server.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- fs/ksmbd/oplock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/oplock.c b/fs/ksmbd/oplock.c index fc5b2137002f..6df455a54b70 100644 --- a/fs/ksmbd/oplock.c +++ b/fs/ksmbd/oplock.c @@ -1488,7 +1488,7 @@ struct create_context *smb2_find_context_vals(void *open_req, const char *tag, i name_len < 4 || name_off + name_len > cc_len || (value_off & 0x7) != 0 || - (value_off && (value_off < name_off + name_len)) || + (value_len && value_off < name_off + (name_len < 8 ? 8 : name_len)) || ((u64)value_off + value_len > cc_len)) return ERR_PTR(-EINVAL); -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] CVE-2024-39461
by Yongqiang Liu 05 Jul '24

05 Jul '24

Nathan Chancellor (1): clk: bcm: rpi: Assign ->num before accessing ->hws drivers/clk/bcm/clk-raspberrypi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-5.10 0/2] CVE-2024-23848
by Yongqiang Liu 05 Jul '24

05 Jul '24

Hans Verkuil (2): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() drivers/media/cec/core/cec-adap.c | 3 +-- drivers/media/cec/core/cec-api.c | 3 +++ 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-23848
by Yongqiang Liu 05 Jul '24

05 Jul '24

CVE-2024-23848 Hans Verkuil (2): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() drivers/media/cec/cec-adap.c | 3 +-- drivers/media/cec/cec-api.c | 3 +++ 2 files changed, 4 insertions(+), 2 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 05 Jul '24

05 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit ee25389df80138907bc9dcdf4a2be2067cde9a81 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index efe38b2c1df7..71c2bf8817dc 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1590,6 +1590,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH OLK-6.6] mm/slub: Reduce memory consumption in extreme scenarios
by Liu Shixin 05 Jul '24

05 Jul '24

From: Chen Jun <chenjun102(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit 9198ffbd2b494daae3a67cac1d59c3a2754e64cd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAATAS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When kmalloc_node() is called without __GFP_THISNODE and the target node lacks sufficient memory, SLUB allocates a folio from a different node other than the requested node, instead of taking a partial slab from it. However, since the allocated folio does not belong to the requested node, on the following allocation it is deactivated and added to the partial slab list of the node it belongs to. This behavior can result in excessive memory usage when the requested node has insufficient memory, as SLUB will repeatedly allocate folios from other nodes without reusing the previously allocated ones. To prevent memory wastage, when a preferred node is indicated (not NUMA_NO_NODE) but without a prior __GFP_THISNODE constraint: 1) try to get a partial slab from target node only by having __GFP_THISNODE in pc.flags for get_partial() 2) if 1) failed, try to allocate a new slab from target node with GFP_NOWAIT | __GFP_THISNODE opportunistically. 3) if 2) failed, retry with original gfpflags which will allow get_partial() try partial lists of other nodes before potentially allocating new page from other nodes Without a preferred node, or with __GFP_THISNODE constraint, the behavior remains unchanged. On qemu with 4 numa nodes and each numa has 1G memory. Write a test ko to call kmalloc_node(196, GFP_KERNEL, 3) for (4 * 1024 + 4) * 1024 times. cat /proc/slabinfo shows: kmalloc-256 4200530 13519712 256 32 2 : tunables.. after this patch, cat /proc/slabinfo shows: kmalloc-256 4200558 4200768 256 32 2 : tunables.. Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/slub.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index ee3e32cdb7fd..7fcd18261c1e 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2392,7 +2392,7 @@ static struct slab *get_partial(struct kmem_cache *s, int node, searchnode = numa_mem_id(); slab = get_partial_node(s, get_node(s, searchnode), pc); - if (slab || node != NUMA_NO_NODE) + if (slab || (node != NUMA_NO_NODE && (pc->flags & __GFP_THISNODE))) return slab; return get_any_partial(s, pc); @@ -3068,6 +3068,7 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, struct slab *slab; unsigned long flags; struct partial_context pc; + bool try_thisnode = true; stat(s, ALLOC_SLOWPATH); @@ -3194,6 +3195,21 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, new_objects: pc.flags = gfpflags; + /* + * When a preferred node is indicated but no __GFP_THISNODE + * + * 1) try to get a partial slab from target node only by having + * __GFP_THISNODE in pc.flags for get_partial() + * 2) if 1) failed, try to allocate a new slab from target node with + * GPF_NOWAIT | __GFP_THISNODE opportunistically + * 3) if 2) failed, retry with original gfpflags which will allow + * get_partial() try partial lists of other nodes before potentially + * allocating new page from other nodes + */ + if (unlikely(node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode)) + pc.flags = GFP_NOWAIT | __GFP_THISNODE; + pc.orig_size = orig_size; slab = get_partial(s, node, &pc); if (slab) { @@ -3215,10 +3231,15 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, } slub_put_cpu_ptr(s->cpu_slab); - slab = new_slab(s, gfpflags, node); + slab = new_slab(s, pc.flags, node); c = slub_get_cpu_ptr(s->cpu_slab); if (unlikely(!slab)) { + if (node != NUMA_NO_NODE && !(gfpflags & __GFP_THISNODE) + && try_thisnode) { + try_thisnode = false; + goto new_objects; + } slab_out_of_memory(s, gfpflags, node); return NULL; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 05 Jul '24

05 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c9ba61413c98..9bad601c7fe8 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -412,7 +412,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -421,6 +420,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] btrfs: fix use-after-free after failure to create a snapshot
by Baokun Li 05 Jul '24

05 Jul '24

From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v5.17-rc3 commit 28b21c558a3753171097193b6f6602a94169093a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72FO CVE: CVE-2022-48733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. CC: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/ioctl.c fs/btrfs/transaction.c [Because commit 74e97958121a ("btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations") was merged before this commit and current commit d0c2f4fa555eh ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") has not been merged yet.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/ioctl.c | 5 +---- fs/btrfs/transaction.c | 24 ++++++++++++++++++++++++ fs/btrfs/transaction.h | 2 ++ 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 3d96eef71e2b..ca0894de2ecd 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -868,10 +868,7 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir, btrfs_qgroup_convert_reserved_meta(root, qgroup_reserved); qgroup_reserved = 0; - spin_lock(&fs_info->trans_lock); - list_add(&pending_snapshot->list, - &trans->transaction->pending_snapshots); - spin_unlock(&fs_info->trans_lock); + trans->pending_snapshot = pending_snapshot; ret = btrfs_commit_transaction(trans); if (ret) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index eb9ab3d3a7b3..897ea85e04e4 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2031,6 +2031,27 @@ static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1); } +/* + * Add a pending snapshot associated with the given transaction handle to the + * respective handle. This must be called after the transaction commit started + * and while holding fs_info->trans_lock. + * This serves to guarantee a caller of btrfs_commit_transaction() that it can + * safely free the pending snapshot pointer in case btrfs_commit_transaction() + * returns an error. + */ +static void add_pending_snapshot(struct btrfs_trans_handle *trans) +{ + struct btrfs_transaction *cur_trans = trans->transaction; + + if (!trans->pending_snapshot) + return; + + lockdep_assert_held(&trans->fs_info->trans_lock); + ASSERT(cur_trans->state >= TRANS_STATE_COMMIT_START); + + list_add(&trans->pending_snapshot->list, &cur_trans->pending_snapshots); +} + int btrfs_commit_transaction(struct btrfs_trans_handle *trans) { struct btrfs_fs_info *fs_info = trans->fs_info; @@ -2117,6 +2138,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) spin_lock(&fs_info->trans_lock); if (cur_trans->state >= TRANS_STATE_COMMIT_START) { + add_pending_snapshot(trans); + spin_unlock(&fs_info->trans_lock); refcount_inc(&cur_trans->use_count); ret = btrfs_end_transaction(trans); @@ -2199,6 +2222,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) * COMMIT_DOING so make sure to wait for num_writers to == 1 again. */ spin_lock(&fs_info->trans_lock); + add_pending_snapshot(trans); cur_trans->state = TRANS_STATE_COMMIT_DOING; spin_unlock(&fs_info->trans_lock); wait_event(cur_trans->writer_wait, diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h index f73654d93fa0..eb26eb068fe8 100644 --- a/fs/btrfs/transaction.h +++ b/fs/btrfs/transaction.h @@ -122,6 +122,8 @@ struct btrfs_trans_handle { struct btrfs_transaction *transaction; struct btrfs_block_rsv *block_rsv; struct btrfs_block_rsv *orig_rsv; + /* Set by a task that wants to create a snapshot. */ + struct btrfs_pending_snapshot *pending_snapshot; refcount_t use_count; unsigned int type; /* -- 2.31.1

2 1

[PATCH OLK-5.10] btrfs: fix use-after-free after failure to create a snapshot
by Baokun Li 05 Jul '24

05 Jul '24

From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v5.17-rc3 commit 28b21c558a3753171097193b6f6602a94169093a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72FO CVE: CVE-2022-48733 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. CC: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/ioctl.c fs/btrfs/transaction.c [Because commit 74e97958121a ("btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations") was merged before this commit and current commit d0c2f4fa555eh ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") has not been merged yet.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/btrfs/ioctl.c | 5 +---- fs/btrfs/transaction.c | 24 ++++++++++++++++++++++++ fs/btrfs/transaction.h | 2 ++ 3 files changed, 27 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index f625c42f48a3..358b9a5937a4 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -868,10 +868,7 @@ static int create_snapshot(struct btrfs_root *root, struct inode *dir, btrfs_qgroup_convert_reserved_meta(root, qgroup_reserved); qgroup_reserved = 0; - spin_lock(&fs_info->trans_lock); - list_add(&pending_snapshot->list, - &trans->transaction->pending_snapshots); - spin_unlock(&fs_info->trans_lock); + trans->pending_snapshot = pending_snapshot; ret = btrfs_commit_transaction(trans); if (ret) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 968f5b45062c..a73b400450ce 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -2038,6 +2038,27 @@ static inline void btrfs_wait_delalloc_flush(struct btrfs_fs_info *fs_info) btrfs_wait_ordered_roots(fs_info, U64_MAX, 0, (u64)-1); } +/* + * Add a pending snapshot associated with the given transaction handle to the + * respective handle. This must be called after the transaction commit started + * and while holding fs_info->trans_lock. + * This serves to guarantee a caller of btrfs_commit_transaction() that it can + * safely free the pending snapshot pointer in case btrfs_commit_transaction() + * returns an error. + */ +static void add_pending_snapshot(struct btrfs_trans_handle *trans) +{ + struct btrfs_transaction *cur_trans = trans->transaction; + + if (!trans->pending_snapshot) + return; + + lockdep_assert_held(&trans->fs_info->trans_lock); + ASSERT(cur_trans->state >= TRANS_STATE_COMMIT_START); + + list_add(&trans->pending_snapshot->list, &cur_trans->pending_snapshots); +} + int btrfs_commit_transaction(struct btrfs_trans_handle *trans) { struct btrfs_fs_info *fs_info = trans->fs_info; @@ -2124,6 +2145,8 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) spin_lock(&fs_info->trans_lock); if (cur_trans->state >= TRANS_STATE_COMMIT_START) { + add_pending_snapshot(trans); + spin_unlock(&fs_info->trans_lock); refcount_inc(&cur_trans->use_count); ret = btrfs_end_transaction(trans); @@ -2206,6 +2229,7 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans) * COMMIT_DOING so make sure to wait for num_writers to == 1 again. */ spin_lock(&fs_info->trans_lock); + add_pending_snapshot(trans); cur_trans->state = TRANS_STATE_COMMIT_DOING; spin_unlock(&fs_info->trans_lock); wait_event(cur_trans->writer_wait, diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h index f73654d93fa0..eb26eb068fe8 100644 --- a/fs/btrfs/transaction.h +++ b/fs/btrfs/transaction.h @@ -122,6 +122,8 @@ struct btrfs_trans_handle { struct btrfs_transaction *transaction; struct btrfs_block_rsv *block_rsv; struct btrfs_block_rsv *orig_rsv; + /* Set by a task that wants to create a snapshot. */ + struct btrfs_pending_snapshot *pending_snapshot; refcount_t use_count; unsigned int type; /* -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/7] Sync bugfix from OLK-5.10
by Zheng Yejian 05 Jul '24

05 Jul '24

Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Kumar Kartikeya Dwivedi (1): bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Martin KaFai Lau (1): bpf: Check the other end of slot_type for STACK_SPILL Stanislav Fomichev (2): bpf: Don't EFAULT for getsockopt with optval=NULL bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen Wang Yufen (1): bpf: Fix memory leaks in __check_func_call kernel/bpf/cgroup.c | 24 +++++++- kernel/bpf/verifier.c | 61 ++++++++++++------- .../testing/selftests/bpf/prog_tests/align.c | 4 +- 3 files changed, 61 insertions(+), 28 deletions(-) -- 2.25.1

2 8

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 1b4ca2a2c1253c9e2d2428cc4fae541fdf3b326d
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 1b4ca2a2c1253c9e2d2428cc4fae541fdf3b326d !9765 i40e: Fix queues reservation for XDP Unverified Warning (likely false positive, please contact us if interested): drivers/uio/uio_hv_generic.c:311 hv_uio_probe() warn: 'pdata->recv_buf' double freed drivers/uio/uio_hv_generic.c:311 hv_uio_probe() warn: 'pdata->send_buf' double freed Warning ids grouped by kconfigs: recent_errors `-- x86_64-randconfig-161-20240704 |-- drivers-uio-uio_hv_generic.c-hv_uio_probe()-warn:pdata-recv_buf-double-freed `-- drivers-uio-uio_hv_generic.c-hv_uio_probe()-warn:pdata-send_buf-double-freed elapsed time: 734m 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-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 gcc-13.2.0 arm64 randconfig-002-20240705 gcc-13.2.0 arm64 randconfig-003-20240705 gcc-13.2.0 arm64 randconfig-004-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 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 SUCCESS b206e4b36a7f6d4d7806d653f1e71867dd56571d
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: b206e4b36a7f6d4d7806d653f1e71867dd56571d !9757 net: openvswitch: fix overwriting ct original tuple for ICMPv6 Warning ids grouped by kconfigs: recent_errors `-- arm64-allmodconfig `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag elapsed time: 723m configs tested: 21 configs skipped: 124 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-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 loongarch allmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch randconfig-001-20240705 gcc-13.2.0 loongarch randconfig-002-20240705 gcc-13.2.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 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 0/2] Add a switch to enable hungtask check for io
by Li Lingfeng 05 Jul '24

05 Jul '24

Add a switch to enable hungtask check for io Li Lingfeng (1): block: disable BLK_IO_HUNG_TASK_CHECK by default Yu Kuai (1): block: add a switch to enable hungtask check for io arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + block/Kconfig | 9 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 ++++++++++++- block/blk-mq.c | 2 +- block/blk.h | 1 + 7 files changed, 26 insertions(+), 3 deletions(-) -- 2.31.1

2 3

[PATCH openEuler-22.03-LTS-SP1] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 6fac6d0e975afe1dec ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 6fac6d0e975a ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index ad12ffcc5085..4760a481e444 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1

2 1

[PATCH OLK-5.10] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 05 Jul '24

05 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 48774b90b5677bdb4 ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 48774b90b567 ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 61cc9a13a40a..fc9908d79f93 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1

2 1

[openeuler:OLK-5.10] BUILD SUCCESS 451734a9a63432990e3124ae33b413c8bb221f5a
by kernel test robot 05 Jul '24

05 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 451734a9a63432990e3124ae33b413c8bb221f5a !9716 ax25: Fix reference count leak issues of ax25_dev Warning ids grouped by kconfigs: recent_errors `-- x86_64-allnoconfig `-- drivers-arm-spe-spe.c:linux-perf-arm_pmu.h-is-included-more-than-once. elapsed time: 725m 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 clang-19 arm64 allnoconfig gcc-13.2.0 arm64 randconfig-001-20240705 clang-19 arm64 randconfig-002-20240705 clang-19 arm64 randconfig-003-20240705 clang-19 arm64 randconfig-004-20240705 clang-19 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240705 gcc-7 x86_64 buildonly-randconfig-002-20240705 gcc-13 x86_64 buildonly-randconfig-003-20240705 clang-18 x86_64 buildonly-randconfig-004-20240705 clang-18 x86_64 buildonly-randconfig-005-20240705 clang-18 x86_64 buildonly-randconfig-006-20240705 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240705 clang-18 x86_64 randconfig-002-20240705 gcc-13 x86_64 randconfig-003-20240705 clang-18 x86_64 randconfig-004-20240705 gcc-13 x86_64 randconfig-005-20240705 gcc-13 x86_64 randconfig-006-20240705 gcc-13 x86_64 randconfig-011-20240705 clang-18 x86_64 randconfig-012-20240705 gcc-9 x86_64 randconfig-013-20240705 clang-18 x86_64 randconfig-014-20240705 gcc-13 x86_64 randconfig-015-20240705 clang-18 x86_64 randconfig-016-20240705 gcc-9 x86_64 randconfig-071-20240705 gcc-13 x86_64 randconfig-072-20240705 gcc-13 x86_64 randconfig-073-20240705 clang-18 x86_64 randconfig-074-20240705 gcc-13 x86_64 randconfig-075-20240705 clang-18 x86_64 randconfig-076-20240705 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 openEuler-22.03-LTS-SP1] f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
by Baokun Li 04 Jul '24

04 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.219 commit a6e1f7744e9b84f86a629a76024bba8468aa153b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YN0 CVE: CVE-2024-34027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0a4ed2d97cb6d044196cc3e726b6699222b41019 ] It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. Fixes: ef8d563f184e ("f2fs: introduce F2FS_IOC_RELEASE_COMPRESS_BLOCKS") Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/f2fs/file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 38510a24861d..ab708374d88e 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -3572,9 +3572,12 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3592,6 +3595,8 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; @@ -3725,9 +3730,12 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3745,6 +3753,8 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; -- 2.31.1

2 1

[PATCH OLK-5.10] f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
by Baokun Li 04 Jul '24

04 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.219 commit a6e1f7744e9b84f86a629a76024bba8468aa153b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YN0 CVE: CVE-2024-34027 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0a4ed2d97cb6d044196cc3e726b6699222b41019 ] It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. Fixes: ef8d563f184e ("f2fs: introduce F2FS_IOC_RELEASE_COMPRESS_BLOCKS") Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS") Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/f2fs/file.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 01995d1b2437..eff0b359f1a3 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -3579,9 +3579,12 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3599,6 +3602,8 @@ static int f2fs_release_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; @@ -3732,9 +3737,12 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) struct dnode_of_data dn; pgoff_t end_offset, count; + f2fs_lock_op(sbi); + set_new_dnode(&dn, inode, NULL, NULL, 0); ret = f2fs_get_dnode_of_data(&dn, page_idx, LOOKUP_NODE); if (ret) { + f2fs_unlock_op(sbi); if (ret == -ENOENT) { page_idx = f2fs_get_next_page_offset(&dn, page_idx); @@ -3752,6 +3760,8 @@ static int f2fs_reserve_compress_blocks(struct file *filp, unsigned long arg) f2fs_put_dnode(&dn); + f2fs_unlock_op(sbi); + if (ret < 0) break; -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] i40e: Fix queues reservation for XDP
by Zeng Heng 04 Jul '24

04 Jul '24

From: Sylwester Dziedziuch <sylwesterx.dziedziuch(a)intel.com> stable inclusion from stable-v4.19.228 commit d46fa4ea9756ef6cbcf9752d0832cc66e2d7121b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72DT CVE: CVE-2021-47619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 92947844b8beee988c0ce17082b705c2f75f0742 upstream. When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on. Fix this by always allocating last queue in PF queue pile for a flow director VSI. Fixes: 41c445ff0f48 ("i40e: main driver core") Fixes: 74608d17fe29 ("i40e: add support for XDP_TX action") Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch(a)intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski(a)intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski(a)intel.com> Tested-by: Kiran Bhandare <kiranx.bhandare(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/net/ethernet/intel/i40e/i40e_main.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 74cf22982f59..bfa5e286c489 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -193,6 +193,20 @@ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile, return -EINVAL; } + /* Allocate last queue in the pile for FDIR VSI queue + * so it doesn't fragment the qp_pile + */ + if (pile == pf->qp_pile && pf->vsi[id]->type == I40E_VSI_FDIR) { + if (pile->list[pile->num_entries - 1] & I40E_PILE_VALID_BIT) { + dev_err(&pf->pdev->dev, + "Cannot allocate queue %d for I40E_VSI_FDIR\n", + pile->num_entries - 1); + return -ENOMEM; + } + pile->list[pile->num_entries - 1] = id | I40E_PILE_VALID_BIT; + return pile->num_entries - 1; + } + /* start the linear search with an imperfect hint */ i = pile->search_hint; while (i < pile->num_entries) { -- 2.25.1

2 1

[PATCH OLK-5.10] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit ee25389df80138907bc9dcdf4a2be2067cde9a81 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index efe38b2c1df7..71c2bf8817dc 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1590,6 +1590,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] Fix xfs file creation issue
by Zizhi Wo 04 Jul '24

04 Jul '24

Revert the previous fix patch and adapt to the latest repair solution. Zizhi Wo (2): Revert "xfs: Fix file creation failure" xfs: Avoid races with cnt_btree lastrec updates fs/xfs/libxfs/xfs_alloc.c | 125 +++++++++++++++++++++++++++++--- fs/xfs/libxfs/xfs_alloc_btree.c | 72 ------------------ fs/xfs/libxfs/xfs_btree.c | 51 ------------- fs/xfs/libxfs/xfs_btree.h | 19 +---- 4 files changed, 115 insertions(+), 152 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH OLK-5.10 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/3] CVE-2024-23848
by Yongqiang Liu 04 Jul '24

04 Jul '24

Hans Verkuil (3): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() media: cec: core: avoid recursive cec_claim_log_addrs drivers/media/cec/cec-adap.c | 9 ++++++--- drivers/media/cec/cec-api.c | 5 ++++- include/media/cec.h | 1 + 3 files changed, 11 insertions(+), 4 deletions(-) -- 2.34.1

2 4

[PATCH v2 OLK-5.10] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 1c3a1962cade..0043fd374a62 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -596,6 +596,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-6.6] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index 33b21a0c0548..8a848ce72e29 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -561,7 +561,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -570,6 +569,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH OLK-5.10] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c9ba61413c98..9bad601c7fe8 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -412,7 +412,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -421,6 +420,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v4.19.316 commit 79ddf5f2020fd593d50f1363bb5131283d74f78f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index da2d179430ca..91b524ca3243 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1580,6 +1580,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index 56b8e7167790..857b1ffe3d85 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -427,7 +427,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -436,6 +435,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH v2 OLK-5.10] arm64: arm_pmuv3: Correctly extract and check the PMUVer
by Junhao He 04 Jul '24

04 Jul '24

mainline inclusion from mainline-v6.10-rc1 commit b782e8d07baac95a5ce3f8773cc61f4ed7d0ccbc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9J01A CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- Currently we're using "sbfx" to extract the PMUVer from ID_AA64DFR0_EL1 and skip the init/reset if no PMU present when the extracted PMUVer is negative or is zero. However for PMUv3p8 the PMUVer will be 0b1000 and PMUVer extracted by "sbfx" will always be negative and we'll skip the init/reset in __init_el2_debug/reset_pmuserenr_el0 unexpectedly. So this patch use "ubfx" instead of "sbfx" to extract the PMUVer. If the PMUVer is implementation defined (0b1111) or not implemented(0b0000) then skip the reset/init. Previously we'll also skip the init/reset if the PMUVer is higher than the version we known (currently PMUv3p9), with this patch we'll only skip if the PMU is not implemented or implementation defined. This keeps consistence with how we probe the PMU in the driver with pmuv3_implemented(). Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> Link: https://lore.kernel.org/r/20240411123030.7201-1-yangyicong@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 7 ++++--- arch/arm64/include/asm/sysreg.h | 1 + arch/arm64/kernel/head.S | 9 +++++---- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 5e6bacda05d8..63db8e5ec9f8 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -466,9 +466,10 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU */ .macro reset_pmuserenr_el0, tmpreg mrs \tmpreg, id_aa64dfr0_el1 - sbfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp \tmpreg, #1 // Skip if no PMU present - b.lt 9000f + ubfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp \tmpreg, #ID_AA64DFR0_PMUVER_NI + ccmp \tmpreg, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 9000f msr pmuserenr_el0, xzr // Disable PMU access from EL0 9000: .endm diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 8bcc9ac9963e..9705f7abd428 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -1488,6 +1488,7 @@ #define ID_AA64DFR0_EL1_BRBE_NI 0x0 #define ID_AA64DFR0_EL1_BRBE_IMP 0x1 #define ID_AA64DFR0_EL1_BRBE_BRBE_V1P1 0x2 +#define ID_AA64DFR0_PMUVER_NI 0x0 #define ID_AA64DFR0_PMUVER_8_0 0x1 #define ID_AA64DFR0_PMUVER_8_1 0x4 #define ID_AA64DFR0_PMUVER_8_4 0x5 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 91890de6cefa..b44213388bab 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -623,13 +623,14 @@ set_hcr: /* EL2 debug */ mrs x1, id_aa64dfr0_el1 - sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp x0, #1 - b.lt 4f // Skip if no PMU present + ubfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp x0, #ID_AA64DFR0_PMUVER_NI + ccmp x0, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 4f // Skip if no PMU present mrs x0, pmcr_el0 // Disable debug access traps ubfx x0, x0, #11, #5 // to EL2 and allow access to 4: - csel x3, xzr, x0, lt // all PMU counters from EL1 + csel x3, xzr, x0, eq // all PMU counters from EL1 /* Statistical profiling */ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4 -- 2.33.0

2 1

[PATCH openEuler-22.03-LTS-SP1] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 1c3a1962cade..0043fd374a62 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -596,6 +596,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-5.10] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 3a6c8ebc8032..4fe8eab9152f 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -579,6 +579,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-5.10] arm64: arm_pmuv3: Correctly extract and check the PMUVer
by Junhao He 04 Jul '24

04 Jul '24

mainline inclusion from mainline-v6.10-rc1 commit b782e8d07baac95a5ce3f8773cc61f4ed7d0ccbc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9GLIG CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- Currently we're using "sbfx" to extract the PMUVer from ID_AA64DFR0_EL1 and skip the init/reset if no PMU present when the extracted PMUVer is negative or is zero. However for PMUv3p8 the PMUVer will be 0b1000 and PMUVer extracted by "sbfx" will always be negative and we'll skip the init/reset in __init_el2_debug/reset_pmuserenr_el0 unexpectedly. So this patch use "ubfx" instead of "sbfx" to extract the PMUVer. If the PMUVer is implementation defined (0b1111) or not implemented(0b0000) then skip the reset/init. Previously we'll also skip the init/reset if the PMUVer is higher than the version we known (currently PMUv3p9), with this patch we'll only skip if the PMU is not implemented or implementation defined. This keeps consistence with how we probe the PMU in the driver with pmuv3_implemented(). Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> Link: https://lore.kernel.org/r/20240411123030.7201-1-yangyicong@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 7 ++++--- arch/arm64/include/asm/sysreg.h | 1 + arch/arm64/kernel/head.S | 9 +++++---- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 5e6bacda05d8..63db8e5ec9f8 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -466,9 +466,10 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU */ .macro reset_pmuserenr_el0, tmpreg mrs \tmpreg, id_aa64dfr0_el1 - sbfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp \tmpreg, #1 // Skip if no PMU present - b.lt 9000f + ubfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp \tmpreg, #ID_AA64DFR0_PMUVER_NI + ccmp \tmpreg, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 9000f msr pmuserenr_el0, xzr // Disable PMU access from EL0 9000: .endm diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 8bcc9ac9963e..9705f7abd428 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -1488,6 +1488,7 @@ #define ID_AA64DFR0_EL1_BRBE_NI 0x0 #define ID_AA64DFR0_EL1_BRBE_IMP 0x1 #define ID_AA64DFR0_EL1_BRBE_BRBE_V1P1 0x2 +#define ID_AA64DFR0_PMUVER_NI 0x0 #define ID_AA64DFR0_PMUVER_8_0 0x1 #define ID_AA64DFR0_PMUVER_8_1 0x4 #define ID_AA64DFR0_PMUVER_8_4 0x5 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 91890de6cefa..b44213388bab 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -623,13 +623,14 @@ set_hcr: /* EL2 debug */ mrs x1, id_aa64dfr0_el1 - sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp x0, #1 - b.lt 4f // Skip if no PMU present + ubfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp x0, #ID_AA64DFR0_PMUVER_NI + ccmp x0, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 4f // Skip if no PMU present mrs x0, pmcr_el0 // Disable debug access traps ubfx x0, x0, #11, #5 // to EL2 and allow access to 4: - csel x3, xzr, x0, lt // all PMU counters from EL1 + csel x3, xzr, x0, eq // all PMU counters from EL1 /* Statistical profiling */ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4 -- 2.33.0

2 1

[PATCH openEuler-1.0-LTS] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> stable inclusion from stable-v4.19.311 commit 13edb509abc91c72152a11baaf0e7c060a312e03 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit aaa8736370db1a78f0e8434344a484f9fd20be3b ] When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 3a6c8ebc8032..4fe8eab9152f 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -579,6 +579,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-6.6] cxl/pci: Skip to handle RAS errors if CXL.mem device is detached
by Wei Li 04 Jul '24

04 Jul '24

From: Li Ming <ming4.li(a)intel.com> mainline inclusion from mainline-v6.8-rc6 commit eef5c7b28dbecd6b141987a96db6c54e49828102 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2M3 CVE: CVE-2024-26762 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- The PCI AER model is an awkward fit for CXL error handling. While the expectation is that a PCI device can escalate to link reset to recover from an AER event, the same reset on CXL amounts to a surprise memory hotplug of massive amounts of memory. At present, the CXL error handler attempts some optimistic error handling to unbind the device from the cxl_mem driver after reaping some RAS register values. This results in a "hopeful" attempt to unplug the memory, but there is no guarantee that will succeed. A subsequent AER notification after the memdev unbind event can no longer assume the registers are mapped. Check for memdev bind before reaping status register values to avoid crashes of the form: BUG: unable to handle page fault for address: ffa00000195e9100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core] [...] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? kernelmode_fixup_or_oops+0x84/0x110 ? exc_page_fault+0x113/0x170 ? asm_exc_page_fault+0x26/0x30 ? __pfx_dpc_reset_link+0x10/0x10 ? __cxl_handle_ras+0x30/0x110 [cxl_core] ? find_cxl_port+0x59/0x80 [cxl_core] cxl_handle_rp_ras+0xbc/0xd0 [cxl_core] cxl_error_detected+0x6c/0xf0 [cxl_core] report_error_detected+0xc7/0x1c0 pci_walk_bus+0x73/0x90 pcie_do_recovery+0x23f/0x330 Longer term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might need to be replaced with a new PCI_ERS_RESULT_PANIC. Fixes: 6ac07883dbb5 ("cxl/pci: Add RCH downstream port error logging") Cc: stable(a)vger.kernel.org Suggested-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Li Ming <ming4.li(a)intel.com> Link: https://lore.kernel.org/r/20240129131856.2458980-1-ming4.li@intel.com Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Wei Li <liwei391(a)huawei.com> --- drivers/cxl/core/pci.c | 43 ++++++++++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 12 deletions(-) diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c index 011197fa61036..e78c8e6a5c9a7 100644 --- a/drivers/cxl/core/pci.c +++ b/drivers/cxl/core/pci.c @@ -904,11 +904,21 @@ static void cxl_handle_rdport_errors(struct cxl_dev_state *cxlds) { } void cxl_cor_error_detected(struct pci_dev *pdev) { struct cxl_dev_state *cxlds = pci_get_drvdata(pdev); + struct device *dev = &cxlds->cxlmd->dev; + + scoped_guard(device, dev) { + if (!dev->driver) { + dev_warn(&pdev->dev, + "%s: memdev disabled, abort error handling\n", + dev_name(dev)); + return; + } - if (cxlds->rcd) - cxl_handle_rdport_errors(cxlds); + if (cxlds->rcd) + cxl_handle_rdport_errors(cxlds); - cxl_handle_endpoint_cor_ras(cxlds); + cxl_handle_endpoint_cor_ras(cxlds); + } } EXPORT_SYMBOL_NS_GPL(cxl_cor_error_detected, CXL); @@ -920,16 +930,25 @@ pci_ers_result_t cxl_error_detected(struct pci_dev *pdev, struct device *dev = &cxlmd->dev; bool ue; - if (cxlds->rcd) - cxl_handle_rdport_errors(cxlds); + scoped_guard(device, dev) { + if (!dev->driver) { + dev_warn(&pdev->dev, + "%s: memdev disabled, abort error handling\n", + dev_name(dev)); + return PCI_ERS_RESULT_DISCONNECT; + } + + if (cxlds->rcd) + cxl_handle_rdport_errors(cxlds); + /* + * A frozen channel indicates an impending reset which is fatal to + * CXL.mem operation, and will likely crash the system. On the off + * chance the situation is recoverable dump the status of the RAS + * capability registers and bounce the active state of the memdev. + */ + ue = cxl_handle_endpoint_ras(cxlds); + } - /* - * A frozen channel indicates an impending reset which is fatal to - * CXL.mem operation, and will likely crash the system. On the off - * chance the situation is recoverable dump the status of the RAS - * capability registers and bounce the active state of the memdev. - */ - ue = cxl_handle_endpoint_ras(cxlds); switch (state) { case pci_channel_io_normal: -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH v2 OLK-6.6] Revert "ACPI: processor: Add support for processors described as container packages"
by liwei 04 Jul '24

04 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAJ94 ---------------------------- 'processor_container_handler' identifies ACPI0010 does not match the Processor information reported by DSDT. This reverts commit 2f257a8ec840ccc5fcefab424f468552da7b15ff. Fixes: 2f257a8ec840 ("ACPI: processor: Add support for processors described as container packages") Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/acpi/acpi_processor.c | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 0ff69af46a50..d46e1fe25d58 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -698,31 +698,9 @@ static struct acpi_scan_handler processor_handler = { }, }; -static acpi_status acpi_processor_container_walk(acpi_handle handle, - u32 lvl, - void *context, - void **rv) -{ - struct acpi_device *adev; - acpi_status status; - - adev = acpi_get_acpi_dev(handle); - if (!adev) - return AE_ERROR; - - status = acpi_processor_add(adev, &processor_device_ids[0]); - acpi_put_acpi_dev(adev); - - return status; -} - static int acpi_processor_container_attach(struct acpi_device *dev, const struct acpi_device_id *id) { - acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle, - ACPI_UINT32_MAX, acpi_processor_container_walk, - NULL, NULL, NULL); - return 1; } -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2024-36949
by Zheng Zucheng 04 Jul '24

04 Jul '24

Mukul Joshi (1): drm/amdkfd: Rework kfd_locked handling Zhigang Luo (1): amd/amdkfd: sync all devices to wait all processes being evicted drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 3 --- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 27 +++++++++++++++--------- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 + drivers/gpu/drm/amd/amdkfd/kfd_process.c | 8 ++++++- 4 files changed, 25 insertions(+), 14 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS V1] USB: core: Fix hang in usb_kill_urb by adding memory barriers
by Cheng Yu 04 Jul '24

04 Jul '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v5.10.96 commit e3b131e30e612ff0e32de6c1cb4f69f89db29193 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72HV CVE: CVE-2022-48760 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 26fbe9772b8c459687930511444ce443011f86bf upstream. The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers. CC: <stable(a)vger.kernel.org> Reported-and-tested-by: syzbot+76629376e06e2c2ad626(a)syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/usb/core/hcd.c | 14 ++++++++++++++ drivers/usb/core/urb.c | 12 ++++++++++++ 2 files changed, 26 insertions(+) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 62e6c526e6ed..acff95a9f239 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1663,6 +1663,13 @@ int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags) urb->hcpriv = NULL; INIT_LIST_HEAD(&urb->urb_list); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + atomic_dec(&urb->dev->urbnum); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); @@ -1772,6 +1779,13 @@ static void __usb_hcd_giveback_urb(struct urb *urb) usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + if (unlikely(atomic_read(&urb->reject))) wake_up(&usb_kill_urb_queue); usb_put_urb(urb); diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c index 5e844097a9e3..abf4681159df 100644 --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -692,6 +692,12 @@ void usb_kill_urb(struct urb *urb) if (!(urb && urb->dev && urb->ep)) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); usb_hcd_unlink_urb(urb, -ENOENT); wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); @@ -733,6 +739,12 @@ void usb_poison_urb(struct urb *urb) if (!urb) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); if (!urb->dev || !urb->ep) return; -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 23159/23203] include/asm-generic/atomic-instrumented.h:33:9: warning: 'wait_req' may be used uninitialized
by kernel test robot 04 Jul '24

04 Jul '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 3747e12f550e11fcfb6878af5c6e88f3e4af0d1f commit: 6741506ca02825b90e77088e8fce01c3d02edfdd [23159/23203] nilfs2: fix unexpected freezing of nilfs_segctor_sync() config: x86_64-buildonly-randconfig-005-20240704 (https://download.01.org/0day-ci/archive/20240704/202407041352.YmlrzTKf-lkp@…) compiler: gcc-12 (Ubuntu 12.3.0-9ubuntu2) 12.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240704/202407041352.YmlrzTKf-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/202407041352.YmlrzTKf-lkp@intel.com/ Note: it may well be a FALSE warning. FWIW you are at least aware of it now. http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings All warnings (new ones prefixed by >>): In file included from arch/x86/include/asm/atomic.h:265, from arch/x86/include/asm/msr.h:67, from arch/x86/include/asm/processor.h:21, from arch/x86/include/asm/cpufeature.h:5, from arch/x86/include/asm/thread_info.h:53, from include/linux/thread_bits.h:22, from include/linux/thread_info.h:14, from arch/x86/include/asm/preempt.h:7, from include/linux/preempt.h:81, from include/linux/spinlock.h:51, from include/linux/mmzone.h:9, from include/linux/gfp.h:6, from include/linux/mm.h:11, from include/linux/pagemap.h:8, from fs/nilfs2/segment.c:11: In function 'atomic_set', inlined from 'nilfs_segctor_sync' at fs/nilfs2/segment.c:2175:2: >> include/asm-generic/atomic-instrumented.h:33:9: warning: 'wait_req' may be used uninitialized [-Wmaybe-uninitialized] 33 | kasan_check_write(v, sizeof(*v)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/compiler.h:265, from include/asm-generic/bug.h:5, from arch/x86/include/asm/bug.h:83, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/mm.h:10: include/linux/kasan-checks.h: In function 'nilfs_segctor_sync': include/linux/kasan-checks.h:7:6: note: by argument 1 of type 'const volatile void *' to 'kasan_check_write' declared here 7 | void kasan_check_write(const volatile void *p, unsigned int size); | ^~~~~~~~~~~~~~~~~ fs/nilfs2/segment.c:2170:43: note: 'wait_req' declared here 2170 | struct nilfs_segctor_wait_request wait_req; | ^~~~~~~~ vim +/wait_req +33 include/asm-generic/atomic-instrumented.h b06ed71a624ba0 Dmitry Vyukov 2018-01-29 30 b06ed71a624ba0 Dmitry Vyukov 2018-01-29 31 static __always_inline void atomic_set(atomic_t *v, int i) b06ed71a624ba0 Dmitry Vyukov 2018-01-29 32 { a35353bb9eb199 Dmitry Vyukov 2018-01-29 @33 kasan_check_write(v, sizeof(*v)); b06ed71a624ba0 Dmitry Vyukov 2018-01-29 34 arch_atomic_set(v, i); b06ed71a624ba0 Dmitry Vyukov 2018-01-29 35 } b06ed71a624ba0 Dmitry Vyukov 2018-01-29 36 :::::: The code at line 33 was first introduced by commit :::::: a35353bb9eb1990a44a0d7585f99e9589bcdb682 locking/atomic, asm-generic: Add KASAN instrumentation to atomic operations :::::: TO: Dmitry Vyukov <dvyukov(a)google.com> :::::: CC: Ingo Molnar <mingo(a)kernel.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] Revert "ACPI: processor: Add support for processors described as container packages"
by liwei 04 Jul '24

04 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAJ94 ---------------------------- 'processor_container_handler' identifies ACPI0010 does not match the Processor information reported by DSDT. This reverts commit 2f257a8ec840ccc5fcefab424f468552da7b15ff. Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/acpi/acpi_processor.c | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 0ff69af46a50..d46e1fe25d58 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -698,31 +698,9 @@ static struct acpi_scan_handler processor_handler = { }, }; -static acpi_status acpi_processor_container_walk(acpi_handle handle, - u32 lvl, - void *context, - void **rv) -{ - struct acpi_device *adev; - acpi_status status; - - adev = acpi_get_acpi_dev(handle); - if (!adev) - return AE_ERROR; - - status = acpi_processor_add(adev, &processor_device_ids[0]); - acpi_put_acpi_dev(adev); - - return status; -} - static int acpi_processor_container_attach(struct acpi_device *dev, const struct acpi_device_id *id) { - acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle, - ACPI_UINT32_MAX, acpi_processor_container_walk, - NULL, NULL, NULL); - return 1; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] scsi: qedf: Ensure the copied buf is NUL terminated
by Zheng Zucheng 04 Jul '24

04 Jul '24

From: Bui Quang Minh <minhquangbui99(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit d0184a375ee797eb657d74861ba0935b6e405c62 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHD CVE: CVE-2024-38559 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Signed-off-by: Bui Quang Minh <minhquangbui99(a)gmail.com> Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-4-f1f1b53a10f4@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/scsi/qedf/qedf_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qedf/qedf_debugfs.c b/drivers/scsi/qedf/qedf_debugfs.c index c29c162a494f..e7a609b5791d 100644 --- a/drivers/scsi/qedf/qedf_debugfs.c +++ b/drivers/scsi/qedf/qedf_debugfs.c @@ -181,7 +181,7 @@ qedf_dbg_debug_cmd_write(struct file *filp, const char __user *buffer, if (!count || *ppos) return 0; - kern_buf = memdup_user(buffer, count); + kern_buf = memdup_user_nul(buffer, count); if (IS_ERR(kern_buf)) return PTR_ERR(kern_buf); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] dma-mapping: benchmark: handle NUMA_NO_NODE correctly
by Liu Shixin 04 Jul '24

04 Jul '24

From: Fedor Pchelkin <pchelkin(a)ispras.ru> mainline inclusion from mainline-v6.10-rc2 commit e64746e74f717961250a155e14c156616fcd981f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DCL CVE: CVE-2024-39277 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan.c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) 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) Use cpumask_of_node() in place when binding a kernel thread to a cpuset of a particular node. Note that the provided node id is checked inside map_benchmark_ioctl(). It's just a NUMA_NO_NODE case which is not handled properly later. 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> Acked-by: Barry Song <baohua(a)kernel.org> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- kernel/dma/map_benchmark.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index e0e64f8b0739..c2d225e1cd47 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -121,7 +121,6 @@ static int do_map_benchmark(struct map_benchmark_data *map) struct task_struct **tsk; int threads = map->bparam.threads; int node = map->bparam.node; - const cpumask_t *cpu_mask = cpumask_of_node(node); u64 loops; int ret = 0; int i; @@ -142,7 +141,7 @@ static int do_map_benchmark(struct map_benchmark_data *map) } if (node != NUMA_NO_NODE) - kthread_bind_mask(tsk[i], cpu_mask); + kthread_bind_mask(tsk[i], cpumask_of_node(node)); } /* clear the old value in the previous benchmark */ -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
by Liu Shixin 04 Jul '24

04 Jul '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.219 commit 4b68b861b514a5c09220d622ac3784c0ebac6c80 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGC CVE: CVE-2024-38547 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3b621e9e9e148c0928ab109ac3d4b81487469acb ] The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered. Link: https://lore.kernel.org/r/20240118151303.3828292-1-alexious@zju.edu.cn Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- drivers/staging/media/atomisp/pci/sh_css.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/atomisp/pci/sh_css.c b/drivers/staging/media/atomisp/pci/sh_css.c index 54a18921fbd1..cb0354520360 100644 --- a/drivers/staging/media/atomisp/pci/sh_css.c +++ b/drivers/staging/media/atomisp/pci/sh_css.c @@ -5477,6 +5477,7 @@ static int load_video_binaries(struct ia_css_pipe *pipe) mycs->yuv_scaler_binary = kzalloc(cas_scaler_descr.num_stage * sizeof(struct ia_css_binary), GFP_KERNEL); if (!mycs->yuv_scaler_binary) { + mycs->num_yuv_scaler = 0; err = -ENOMEM; return err; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-38621
by Liao Chen 04 Jul '24

04 Jul '24

media: stk1160: fix bounds checking in stk1160_copy_video() Dan Carpenter (1): media: stk1160: fix bounds checking in stk1160_copy_video() drivers/media/usb/stk1160/stk1160-video.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] net/9p: fix uninit-value in p9_client_rpc()
by Yang Yingliang 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc2 commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEF CVE: CVE-2024-39301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. Reported-and-tested-by: syzbot+ff14db38f56329ef68df(a)syzkaller.appspotmail.com Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Cc: stable(a)vger.kernel.org Message-ID: <20240408141039.30428-1-n.zhandarovich(a)fintech.ru> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/9p/client.c b/net/9p/client.c index d62f83f93d7b..557b7798d642 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -250,6 +250,8 @@ static int p9_fcall_init(struct p9_client *c, struct p9_fcall *fc, if (!fc->sdata) return -ENOMEM; fc->capacity = alloc_msize; + fc->id = 0; + fc->tag = P9_NOTAG; return 0; } -- 2.25.1

2 1

[PATCH OLK-6.6] net/9p: fix uninit-value in p9_client_rpc()
by Yang Yingliang 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc2 commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEF CVE: CVE-2024-39301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. Reported-and-tested-by: syzbot+ff14db38f56329ef68df(a)syzkaller.appspotmail.com Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Cc: stable(a)vger.kernel.org Message-ID: <20240408141039.30428-1-n.zhandarovich(a)fintech.ru> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/9p/client.c b/net/9p/client.c index f7e90b4769bb..b05f73c291b4 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_client *c, struct p9_fcall *fc, if (!fc->sdata) return -ENOMEM; fc->capacity = alloc_msize; + fc->id = 0; + fc->tag = P9_NOTAG; return 0; } -- 2.25.1

2 1

[PATCH OLK-5.10] net/9p: fix uninit-value in p9_client_rpc()
by Yang Yingliang 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc2 commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEF CVE: CVE-2024-39301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. Reported-and-tested-by: syzbot+ff14db38f56329ef68df(a)syzkaller.appspotmail.com Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Cc: stable(a)vger.kernel.org Message-ID: <20240408141039.30428-1-n.zhandarovich(a)fintech.ru> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/9p/client.c b/net/9p/client.c index cd85a4b6448b..0fa324e8b245 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_client *c, struct p9_fcall *fc, if (!fc->sdata) return -ENOMEM; fc->capacity = alloc_msize; + fc->id = 0; + fc->tag = P9_NOTAG; return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net/9p: fix uninit-value in p9_client_rpc()
by Yang Yingliang 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc2 commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEF CVE: CVE-2024-39301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. Reported-and-tested-by: syzbot+ff14db38f56329ef68df(a)syzkaller.appspotmail.com Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Cc: stable(a)vger.kernel.org Message-ID: <20240408141039.30428-1-n.zhandarovich(a)fintech.ru> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/9p/client.c b/net/9p/client.c index cd85a4b6448b..0fa324e8b245 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_client *c, struct p9_fcall *fc, if (!fc->sdata) return -ENOMEM; fc->capacity = alloc_msize; + fc->id = 0; + fc->tag = P9_NOTAG; return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
by Tong Tiangen 04 Jul '24

04 Jul '24

From: Hao Chen <chenhao418(a)huawei.com> mainline inclusion from mainline-v6.9-rc1 commit 582c1aeee0a9e73010cf1c4cef338709860deeb0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9HCSA CVE: CVE-2024-38603 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=fo… ------------------------------------------------------------------------ pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action() fails, the irq vector is not freed, which leads to a memory leak. Replace the devm_add_action with devm_add_action_or_reset to ensure the irq vector can be destroyed when it fails. Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU") Signed-off-by: Hao Chen <chenhao418(a)huawei.com> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> Reviewed-by: Jijie Shao <shaojijie(a)huawei.com> Acked-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Link: https://lore.kernel.org/r/20240425124627.13764-4-hejunhao3@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Slim6882 <yangjunshuo(a)huawei.com> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/perf/hisilicon/hns3_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/perf/hisilicon/hns3_pmu.c b/drivers/perf/hisilicon/hns3_pmu.c index 08b2068b5278..40edc4cfcc34 100644 --- a/drivers/perf/hisilicon/hns3_pmu.c +++ b/drivers/perf/hisilicon/hns3_pmu.c @@ -1518,7 +1518,7 @@ static int hns3_pmu_irq_register(struct pci_dev *pdev, return ret; } - ret = devm_add_action(&pdev->dev, hns3_pmu_free_irq, pdev); + ret = devm_add_action_or_reset(&pdev->dev, hns3_pmu_free_irq, pdev); if (ret) { pci_err(pdev, "failed to add free irq action, ret = %d.\n", ret); return ret; -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): [Backport] nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): [Backport] nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH OLK-5.10 v2 0/5] Backport bpf bugfixes
by Zheng Yejian 04 Jul '24

04 Jul '24

v1 -> v2: Update bugzilla link info in patch1 & patch2 Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Kumar Kartikeya Dwivedi (1): bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Stanislav Fomichev (1): bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen Wang Yufen (1): bpf: Fix memory leaks in __check_func_call kernel/bpf/cgroup.c | 15 +++++++++ kernel/bpf/verifier.c | 33 +++++++++++-------- .../testing/selftests/bpf/prog_tests/align.c | 4 +-- 3 files changed, 37 insertions(+), 15 deletions(-) -- 2.25.1

2 6

[PATCH OLK-6.6] efi: libstub: only free priv.runtime_map when allocated
by Tong Tiangen 04 Jul '24

04 Jul '24

From: Hagar Hemdan <hagarhem(a)amazon.com> stable inclusion from stable-v6.6.33 commit 9dce01f386c9ce6990c0a83fa14b1c95330b037e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D2K CVE: CVE-2024-33619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974 upstream. priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: f80d26043af9 ("efi: libstub: avoid efi_get_memory_map() for allocating the virt map") Cc: <stable(a)vger.kernel.org> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/firmware/efi/libstub/fdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index 70e9789ff9de..6a337f1f8787 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -335,8 +335,8 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle, fail: efi_free(fdt_size, fdt_addr); - - efi_bs_call(free_pool, priv.runtime_map); + if (!efi_novamap) + efi_bs_call(free_pool, priv.runtime_map); return EFI_LOAD_ERROR; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] seg6: fix the iif in the IPv6 socket control block
by Dong Chenchen 04 Jul '24

04 Jul '24

From: Andrea Mayer <andrea.mayer(a)uniroma2.it> stable inclusion from stable-v4.19.221 commit 6431e71093f3da586a00c6d931481ffb0dc2db0e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9S252 CVE: CVE-2021-47515 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ae68d93354e5bf5191ee673982251864ea24dd5c upstream. When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif; If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29). Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero). As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied. To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again. Fixes: ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") Signed-off-by: Andrea Mayer <andrea.mayer(a)uniroma2.it> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20211208195409.12169-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ipv6/seg6_iptunnel.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c index ee5403cbe655..26882fd9323a 100644 --- a/net/ipv6/seg6_iptunnel.c +++ b/net/ipv6/seg6_iptunnel.c @@ -148,6 +148,14 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto) hdr->hop_limit = ip6_dst_hoplimit(skb_dst(skb)); memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); + + /* the control block has been erased, so we have to set the + * iif once again. + * We read the receiving interface index directly from the + * skb->skb_iif as it is done in the IPv4 receiving path (i.e.: + * ip_rcv_core(...)). + */ + IP6CB(skb)->iif = skb->skb_iif; } hdr->nexthdr = NEXTHDR_ROUTING; -- 2.25.1

2 1

[PATCH OLK-5.10 0/5] Backport bpf bugfixes
by Zheng Yejian 04 Jul '24

04 Jul '24

Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Kumar Kartikeya Dwivedi (1): bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Stanislav Fomichev (1): bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen Wang Yufen (1): bpf: Fix memory leaks in __check_func_call kernel/bpf/cgroup.c | 15 +++++++++ kernel/bpf/verifier.c | 33 +++++++++++-------- .../testing/selftests/bpf/prog_tests/align.c | 4 +-- 3 files changed, 37 insertions(+), 15 deletions(-) -- 2.25.1

2 6

[openEuler-22.03-LTS-SP1 0/1] CVE-2024-38621
by Liao Chen 04 Jul '24

04 Jul '24

media: stk1160: fix bounds checking in stk1160_copy_video() Dan Carpenter (1): media: stk1160: fix bounds checking in stk1160_copy_video() drivers/media/usb/stk1160/stk1160-video.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) -- 2.34.1

1 1

[PATCH openEuler-1.0-LTS] net: amd-xgbe: Fix skb data length underflow
by Zheng Zucheng 04 Jul '24

04 Jul '24

From: Shyam Sundar S K <Shyam-sundar.S-k(a)amd.com> mainline inclusion from mainline-v5.17-rc3 commit 5aac9108a180fc06e28d4e7fb00247ce603b72ee category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72MM CVE: CVE-2022-48743 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. Fixes: 622c36f143fc ("amd-xgbe: Fix jumbo MTU processing on newer hardware") Suggested-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k(a)amd.com> Acked-by: Tom Lendacky <thomas.lendacky(a)amd.com> Link: https://lore.kernel.org/r/20220127092003.2812745-1-Shyam-sundar.S-k@amd.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c index d96a84a62d78..cdbabd77f2d4 100644 --- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c @@ -2765,6 +2765,14 @@ static int xgbe_rx_poll(struct xgbe_channel *channel, int budget) buf2_len = xgbe_rx_buf2_len(rdata, packet, len); len += buf2_len; + if (buf2_len > rdata->rx.buf.dma_len) { + /* Hardware inconsistency within the descriptors + * that has resulted in a length underflow. + */ + error = 1; + goto skip_data; + } + if (!skb) { skb = xgbe_create_skb(pdata, napi, rdata, buf1_len); @@ -2794,8 +2802,10 @@ static int xgbe_rx_poll(struct xgbe_channel *channel, int budget) if (!last || context_next) goto read_again; - if (!skb) + if (!skb || error) { + dev_kfree_skb(skb); goto next_packet; + } /* Be sure we don't exceed the configured MTU */ max_len = netdev->mtu + ETH_HLEN; -- 2.34.1

2 1

[PATCH OLK-6.6] efi: libstub: only free priv.runtime_map when allocated
by Tong Tiangen 04 Jul '24

04 Jul '24

From: Hagar Hemdan <hagarhem(a)amazon.com> stable inclusion from stable-v6.6.33 commit 9dce01f386c9ce6990c0a83fa14b1c95330b037e 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… -------------------------------- commit 4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974 upstream. priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: f80d26043af9 ("efi: libstub: avoid efi_get_memory_map() for allocating the virt map") Cc: <stable(a)vger.kernel.org> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/firmware/efi/libstub/fdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index 70e9789ff9de..6a337f1f8787 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -335,8 +335,8 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle, fail: efi_free(fdt_size, fdt_addr); - - efi_bs_call(free_pool, priv.runtime_map); + if (!efi_novamap) + efi_bs_call(free_pool, priv.runtime_map); return EFI_LOAD_ERROR; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS v2 0/2] net: Fix CVE-2022-48757
by Dong Chenchen 04 Jul '24

04 Jul '24

fix CVE-2022-48757. Congyu Liu (1): net: fix information leakage in /proc/net/ptype Dong Chenchen (1): net: fix kabi breakage in struct packet_type include/linux/netdevice.h | 4 ++++ net/core/net-procfs.c | 3 ++- net/packet/af_packet.c | 2 ++ 3 files changed, 8 insertions(+), 1 deletion(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/4] Fix CVE-2024-35915
by Zheng Zucheng 03 Jul '24

03 Jul '24

Ryosuke Yasuoka (3): nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet nfc: nci: Fix uninit-value in nci_rx_work nfc: nci: Fix handling of zero-length payload packets in nci_rx_work() Tetsuo Handa (1): nfc: nci: Fix kcov check in nci_rx_work() net/nfc/nci/core.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) -- 2.34.1

2 5

[PATCH openEuler-1.0-LTS 0/2] net: fix CVE-2022-48757
by Dong Chenchen 03 Jul '24

03 Jul '24

fix CVE-2022-48757. Congyu Liu (1): net: fix information leakage in /proc/net/ptype Dong Chenchen (1): net: fix kabi breakage in struct packet_type include/linux/netdevice.h | 4 ++++ net/core/net-procfs.c | 3 ++- net/packet/af_packet.c | 2 ++ 3 files changed, 8 insertions(+), 1 deletion(-) -- 2.25.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/1] ext4: delete redundant uptodate
by Zheng Zengkai 03 Jul '24

03 Jul '24

Backport patch from mainline to optimize file copy performance. Yang Guo (1): ext4: delete redundant uptodate check for buffer fs/ext4/inode.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) -- 2.20.1

2 2

[PATCH OLK-6.6] drm: vc4: Fix possible null pointer dereference
by Ze Zuo 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit 42c22b63056cea259d5313bf138a834840af85a5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGI CVE: CVE-2024-38546 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c534b63bede6cb987c2946ed4d0b0013a52c5ba7 ] In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240409075622.11783-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 4626fe9aac56..643754fa6a8a 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -2729,6 +2729,8 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) index = 1; addr = of_get_address(dev->of_node, index, NULL, NULL); + if (!addr) + return -EINVAL; vc4_hdmi->audio.dma_data.addr = be32_to_cpup(addr) + mai_data->offset; vc4_hdmi->audio.dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] firewire: ohci: mask bus reset interrupts between ISR and bottom half
by Ze Zuo 03 Jul '24

03 Jul '24

From: Adam Goldman <adamg(a)pobox.com> stable inclusion from stable-v5.10.217 commit fa273f312334246c909475c5868e6daab889cc8c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UOCQ CVE: CVE-2024-36950 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 752e3c53de0fa3b7d817a83050b6699b8e9c6ec9 ] In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until bus_reset_work has serviced and cleared the interrupt. Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them. irq_handler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irq_handler, because we won't service the event until later. irq_handler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irq_handler being called again each time it exits. This freeze can be reproduced by loading firewire_ohci with "modprobe firewire_ohci debug=-1" (to enable all debugging output). Apparently there are also some cases where bus_reset_work will get called soon enough to clear the event, and operation will continue normally. This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization. irq_handler will now leave the event flag set but mask bus reset interrupts, so irq_handler won't be called again and there will be no freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired. As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after bus_reset_work has executed. Signed-off-by: Adam Goldman <adamg(a)pobox.com> Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- drivers/firewire/ohci.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 9811c40956e5..5810b8f068ef 100644 --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -2001,6 +2001,8 @@ static void bus_reset_work(struct work_struct *work) ohci->generation = generation; reg_write(ohci, OHCI1394_IntEventClear, OHCI1394_busReset); + if (param_debug & OHCI_PARAM_DEBUG_BUSRESETS) + reg_write(ohci, OHCI1394_IntMaskSet, OHCI1394_busReset); if (ohci->quirks & QUIRK_RESET_PACKET) ohci->request_generation = generation; @@ -2067,12 +2069,14 @@ static irqreturn_t irq_handler(int irq, void *data) return IRQ_NONE; /* - * busReset and postedWriteErr must not be cleared yet + * busReset and postedWriteErr events must not be cleared yet * (OHCI 1.1 clauses 7.2.3.2 and 13.2.8.1) */ reg_write(ohci, OHCI1394_IntEventClear, event & ~(OHCI1394_busReset | OHCI1394_postedWriteErr)); log_irqs(ohci, event); + if (event & OHCI1394_busReset) + reg_write(ohci, OHCI1394_IntMaskClear, OHCI1394_busReset); if (event & OHCI1394_selfIDComplete) queue_work(selfid_workqueue, &ohci->bus_reset_work); -- 2.25.1

2 1

[PATCH OLK-5.10] KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
by Zeng Heng 03 Jul '24

03 Jul '24

From: Wanpeng Li <wanpengli(a)tencent.com> mainline inclusion from mainline-v5.17-rc2 commit 35fe7cfbab2e81f1afb23fc4212210b1de6d9633 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72K9 CVE: CVE-2022-48765 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The below warning is splatting during guest reboot. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Call Trace: <TASK> kvm_vcpu_ioctl+0x279/0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC. Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Message-Id: <1643102220-35667-1-git-send-email-wanpengli(a)tencent.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Conflicts: arch/x86/kvm/lapic.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 610a79f1c469..d6272f97368f 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2631,7 +2631,7 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct kvm_lapic_state *s) kvm_apic_set_version(vcpu); apic_update_ppr(apic); - hrtimer_cancel(&apic->lapic_timer.timer); + cancel_apic_timer(apic); apic_update_lvtt(apic); apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0)); update_divide_count(apic); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
by Zeng Heng 03 Jul '24

03 Jul '24

From: Wanpeng Li <wanpengli(a)tencent.com> mainline inclusion from mainline-v5.17-rc2 commit 35fe7cfbab2e81f1afb23fc4212210b1de6d9633 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72K9 CVE: CVE-2022-48765 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The below warning is splatting during guest reboot. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Call Trace: <TASK> kvm_vcpu_ioctl+0x279/0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC. Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Message-Id: <1643102220-35667-1-git-send-email-wanpengli(a)tencent.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Conflicts: arch/x86/kvm/lapic.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 610a79f1c469..d6272f97368f 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2631,7 +2631,7 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct kvm_lapic_state *s) kvm_apic_set_version(vcpu); apic_update_ppr(apic); - hrtimer_cancel(&apic->lapic_timer.timer); + cancel_apic_timer(apic); apic_update_lvtt(apic); apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0)); update_divide_count(apic); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ax25: Fix reference count leak issues of ax25_dev
by Liu Jian 03 Jul '24

03 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit b505e0319852b08a3a716b64620168eab21f4ced category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8I CVE: CVE-2024-38602 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the issue of ax25_dev_device_down(), increase the reference count of ax25_dev once in ax25_dev_device_up() and decrease the reference count of ax25_dev after it is removed from the ax25_dev_list. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/361bbf2a4b091e120006279ec3b382d73c4a0c17.17152470… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/ax25_dev.c [The conflict occurs because the commit a968c799eb1d("ax25: merge repeat codes in ax25_dev_device_down()") and a7d6e36b9ad0("ax25: Use kernel universal linked list to implement ax25_dev_list") are not merged] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ax25/ax25_dev.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c index d1d8d8a21ddd..fe730fad1c38 100644 --- a/net/ax25/ax25_dev.c +++ b/net/ax25/ax25_dev.c @@ -38,6 +38,7 @@ ax25_dev *ax25_addr_ax25dev(ax25_address *addr) if (ax25cmp(addr, (ax25_address *)ax25_dev->dev->dev_addr) == 0) { res = ax25_dev; ax25_dev_hold(ax25_dev); + break; } spin_unlock_bh(&ax25_dev_lock); @@ -86,7 +87,6 @@ void ax25_dev_device_up(struct net_device *dev) ax25_dev->next = ax25_dev_list; ax25_dev_list = ax25_dev; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_hold(ax25_dev); ax25_register_dev_sysctl(ax25_dev); } @@ -116,7 +116,6 @@ void ax25_dev_device_down(struct net_device *dev) if ((s = ax25_dev_list) == ax25_dev) { ax25_dev_list = s->next; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_put(ax25_dev); dev->ax25_ptr = NULL; dev_put(dev); ax25_dev_put(ax25_dev); @@ -127,7 +126,6 @@ void ax25_dev_device_down(struct net_device *dev) if (s->next == ax25_dev) { s->next = ax25_dev->next; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_put(ax25_dev); dev->ax25_ptr = NULL; dev_put(dev); ax25_dev_put(ax25_dev); -- 2.34.1

2 1

[PATCH OLK-5.10] ax25: Fix reference count leak issues of ax25_dev
by Liu Jian 03 Jul '24

03 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit b505e0319852b08a3a716b64620168eab21f4ced category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8I CVE: CVE-2024-38602 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the issue of ax25_dev_device_down(), increase the reference count of ax25_dev once in ax25_dev_device_up() and decrease the reference count of ax25_dev after it is removed from the ax25_dev_list. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/361bbf2a4b091e120006279ec3b382d73c4a0c17.17152470… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/ax25_dev.c [The conflict occurs because the commit a968c799eb1d("ax25: merge repeat codes in ax25_dev_device_down()") and a7d6e36b9ad0("ax25: Use kernel universal linked list to implement ax25_dev_list") are not merged] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ax25/ax25_dev.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c index d1d8d8a21ddd..fe730fad1c38 100644 --- a/net/ax25/ax25_dev.c +++ b/net/ax25/ax25_dev.c @@ -38,6 +38,7 @@ ax25_dev *ax25_addr_ax25dev(ax25_address *addr) if (ax25cmp(addr, (ax25_address *)ax25_dev->dev->dev_addr) == 0) { res = ax25_dev; ax25_dev_hold(ax25_dev); + break; } spin_unlock_bh(&ax25_dev_lock); @@ -86,7 +87,6 @@ void ax25_dev_device_up(struct net_device *dev) ax25_dev->next = ax25_dev_list; ax25_dev_list = ax25_dev; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_hold(ax25_dev); ax25_register_dev_sysctl(ax25_dev); } @@ -116,7 +116,6 @@ void ax25_dev_device_down(struct net_device *dev) if ((s = ax25_dev_list) == ax25_dev) { ax25_dev_list = s->next; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_put(ax25_dev); dev->ax25_ptr = NULL; dev_put(dev); ax25_dev_put(ax25_dev); @@ -127,7 +126,6 @@ void ax25_dev_device_down(struct net_device *dev) if (s->next == ax25_dev) { s->next = ax25_dev->next; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_put(ax25_dev); dev->ax25_ptr = NULL; dev_put(dev); ax25_dev_put(ax25_dev); -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] CVE-2024-38602
by Liu Jian 03 Jul '24

03 Jul '24

CVE-2024-38602 Duoming Zhou (2): ax25: Use kernel universal linked list to implement ax25_dev_list ax25: Fix reference count leak issues of ax25_dev include/net/ax25.h | 3 +-- net/ax25/ax25_dev.c | 43 ++++++++++++++++--------------------------- 2 files changed, 17 insertions(+), 29 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1] KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
by Zeng Heng 03 Jul '24

03 Jul '24

From: Wanpeng Li <wanpengli(a)tencent.com> mainline inclusion from mainline-v5.17-rc2 commit 35fe7cfbab2e81f1afb23fc4212210b1de6d9633 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72K9 CVE: CVE-2022-48765 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The below warning is splatting during guest reboot. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Call Trace: <TASK> kvm_vcpu_ioctl+0x279/0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC. Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Message-Id: <1643102220-35667-1-git-send-email-wanpengli(a)tencent.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 610a79f1c469..d6272f97368f 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2631,7 +2631,7 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct kvm_lapic_state *s) kvm_apic_set_version(vcpu); apic_update_ppr(apic); - hrtimer_cancel(&apic->lapic_timer.timer); + cancel_apic_timer(apic); apic_update_lvtt(apic); apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0)); update_divide_count(apic); -- 2.25.1

2 3

[PATCH OLK-5.10] KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
by Zeng Heng 03 Jul '24

03 Jul '24

From: Wanpeng Li <wanpengli(a)tencent.com> mainline inclusion from mainline-v5.17-rc2 commit 35fe7cfbab2e81f1afb23fc4212210b1de6d9633 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72K9 CVE: CVE-2022-48765 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The below warning is splatting during guest reboot. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Call Trace: <TASK> kvm_vcpu_ioctl+0x279/0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC. Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Message-Id: <1643102220-35667-1-git-send-email-wanpengli(a)tencent.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 610a79f1c469..d6272f97368f 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2631,7 +2631,7 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct kvm_lapic_state *s) kvm_apic_set_version(vcpu); apic_update_ppr(apic); - hrtimer_cancel(&apic->lapic_timer.timer); + cancel_apic_timer(apic); apic_update_lvtt(apic); apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0)); update_divide_count(apic); -- 2.25.1

2 3

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

03 Jul '24

*** BLURB HERE *** Michal Schmidt (1): bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq drivers/infiniband/hw/bnxt_re/qplib_fp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-5.10 0/4] fix CVE-2024-38615
by Lin Yujun 03 Jul '24

03 Jul '24

*** BLURB HERE *** Rafael J. Wysocki (3): cpufreq: Reorganize checks in cpufreq_offline() cpufreq: Split cpufreq_offline() cpufreq: Rearrange locking in cpufreq_remove_dev() Viresh Kumar (1): cpufreq: exit() callback is optional drivers/cpufreq/cpufreq.c | 83 +++++++++++++++++++++++---------------- 1 file changed, 49 insertions(+), 34 deletions(-) -- 2.34.1

2 5

[PATCH OLK6.6 0/1] fix CVE-2024-38615
by Lin Yujun 03 Jul '24

03 Jul '24

*** BLURB HERE *** Viresh Kumar (1): cpufreq: exit() callback is optional drivers/cpufreq/cpufreq.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) -- 2.34.1

1 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2022-48738
by Jialin Zhang 03 Jul '24

03 Jul '24

Marek Vasut (1): ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min Mark Brown (1): ASoC: ops: Reject out of bounds values in snd_soc_put_volsw() sound/soc/soc-ops.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/1] cgroup: fix uaf when proc_cpuset_show
by Chen Ridong 03 Jul '24

03 Jul '24

*** BLURB HERE *** Chen Ridong (1): cgroup: fix uaf when proc_cpuset_show kernel/cgroup/cpuset.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1 V1] drm/msm: Fix null ptr access msm_ioctl_gem_submit()
by Cheng Yu 03 Jul '24

03 Jul '24

From: Akhil P Oommen <akhilpo(a)codeaurora.org> mainline inclusion from mainline-v5.16-rc4 commit 26d776fd0f79f093a5d0ce1a4c7c7a992bc3264c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SJ0 CVE: CVE-2021-47610 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix the below null pointer dereference in msm_ioctl_gem_submit(): 26545.260705: Call trace: 26545.263223: kref_put+0x1c/0x60 26545.266452: msm_ioctl_gem_submit+0x254/0x744 26545.270937: drm_ioctl_kernel+0xa8/0x124 26545.274976: drm_ioctl+0x21c/0x33c 26545.278478: drm_compat_ioctl+0xdc/0xf0 26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100 26545.287169: el0_svc_common+0xf8/0x250 26545.291025: do_el0_svc_compat+0x28/0x54 26545.295066: el0_svc_compat+0x10/0x1c 26545.298838: el0_sync_compat_handler+0xa8/0xcc 26545.303403: el0_sync_compat+0x188/0x1c0 26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008) 26545.318799: Kernel panic - not syncing: Oops: Fatal exception Signed-off-by: Akhil P Oommen <akhilpo(a)codeaurora.org> Link: https://lore.kernel.org/r/20211118154903.2.I3ae019673a0cc45d83a193a7858748d… Signed-off-by: Rob Clark <robdclark(a)chromium.org> Conflicts: drivers/gpu/drm/msm/msm_gem_submit.c [This is a conflict caused by commit 79341eb74c1f("drm/msm: Return ERR_PTR() from submit_create()") which is not merged and some context conflicts.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/gpu/drm/msm/msm_gem_submit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index aa5c60a7132d..9005646dfb15 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -681,6 +681,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, args->nr_cmds); if (!submit) { ret = -ENOMEM; + submit = NULL; goto out_unlock; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] nilfs2: fix use-after-free of timer for log writer thread
by Guo Mengqi 03 Jul '24

03 Jul '24

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> stable inclusion from stable-v4.19.316 commit 822ae5a8eac30478578a75f7e064f0584931bf2d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5D CVE: CVE-2024-38583 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f5d4e04634c9cf68bdf23de08ada0bb92e8befe7 upstream. Patch series "nilfs2: fix log writer related issues". This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log. This patch (of 3): A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive. Link: https://lkml.kernel.org/r/20240520132621.4054-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20240520132621.4054-2-konishi.ryusuke@gmail.com Fixes: fdce895ea5dd ("nilfs2: change sc_timer from a pointer to an embedded one in struct nilfs_sc_info") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: "Bai, Shuangpeng" <sjb7183(a)psu.edu> Closes: https://groups.google.com/g/syzkaller/c/MK_LYqtt8ko/m/8rgdWeseAwAJ Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/nilfs2/segment.c [context conflict] Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- fs/nilfs2/segment.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 63422a044a23..04cd0a643234 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -2125,8 +2125,10 @@ static void nilfs_segctor_start_timer(struct nilfs_sc_info *sci) { spin_lock(&sci->sc_state_lock); if (!(sci->sc_state & NILFS_SEGCTOR_COMMIT)) { - sci->sc_timer.expires = jiffies + sci->sc_interval; - add_timer(&sci->sc_timer); + if (sci->sc_task) { + sci->sc_timer.expires = jiffies + sci->sc_interval; + add_timer(&sci->sc_timer); + } sci->sc_state |= NILFS_SEGCTOR_COMMIT; } spin_unlock(&sci->sc_state_lock); @@ -2346,10 +2348,21 @@ int nilfs_construct_dsync_segment(struct super_block *sb, struct inode *inode, */ static void nilfs_segctor_accept(struct nilfs_sc_info *sci) { + bool thread_is_alive; + spin_lock(&sci->sc_state_lock); sci->sc_seq_accepted = sci->sc_seq_request; + thread_is_alive = (bool)sci->sc_task; spin_unlock(&sci->sc_state_lock); - del_timer_sync(&sci->sc_timer); + + /* + * This function does not race with the log writer thread's + * termination. Therefore, deleting sc_timer, which should not be + * done after the log writer thread exits, can be done safely outside + * the area protected by sc_state_lock. + */ + if (thread_is_alive) + del_timer_sync(&sci->sc_timer); } /** @@ -2375,7 +2388,7 @@ static void nilfs_segctor_notify(struct nilfs_sc_info *sci, int mode, int err) sci->sc_flush_request &= ~FLUSH_DAT_BIT; /* re-enable timer if checkpoint creation was not done */ - if ((sci->sc_state & NILFS_SEGCTOR_COMMIT) && + if ((sci->sc_state & NILFS_SEGCTOR_COMMIT) && sci->sc_task && time_before(jiffies, sci->sc_timer.expires)) add_timer(&sci->sc_timer); } @@ -2565,6 +2578,7 @@ static int nilfs_segctor_thread(void *arg) int timeout = 0; sci->sc_timer_task = current; + timer_setup(&sci->sc_timer, nilfs_construction_timeout, 0); /* start sync. */ sci->sc_task = current; @@ -2633,6 +2647,7 @@ static int nilfs_segctor_thread(void *arg) /* end sync. */ sci->sc_task = NULL; + del_timer_sync(&sci->sc_timer); wake_up(&sci->sc_wait_task); /* for nilfs_segctor_kill_thread() */ return 0; } @@ -2695,7 +2710,6 @@ static struct nilfs_sc_info *nilfs_segctor_new(struct super_block *sb, INIT_LIST_HEAD(&sci->sc_gc_inodes); INIT_LIST_HEAD(&sci->sc_iput_queue); INIT_WORK(&sci->sc_iput_work, nilfs_iput_work_func); - timer_setup(&sci->sc_timer, nilfs_construction_timeout, 0); sci->sc_interval = HZ * NILFS_SC_DEFAULT_TIMEOUT; sci->sc_mjcp_freq = HZ * NILFS_SC_DEFAULT_SR_FREQ; @@ -2781,7 +2795,6 @@ static void nilfs_segctor_destroy(struct nilfs_sc_info *sci) down_write(&nilfs->ns_segctor_sem); - del_timer_sync(&sci->sc_timer); kfree(sci); } -- 2.17.1

2 1

[PATCH OLK-5.10 0/3] Backport bpf bugfixes
by Zheng Yejian 03 Jul '24

03 Jul '24

Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Stanislav Fomichev (1): bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen kernel/bpf/cgroup.c | 15 +++++++++++++++ kernel/bpf/verifier.c | 13 ++++++++----- tools/testing/selftests/bpf/prog_tests/align.c | 4 ++-- 3 files changed, 25 insertions(+), 7 deletions(-) -- 2.25.1

2 4

[PATCH OLK-5.10] net/hinic3: Add pcie device ID adaption for DPU_NIC card
by z00857956 03 Jul '24

03 Jul '24

From: zhoushuai <zhoushuai28(a)huawei.com> driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IA9G0T?from=project-issue CVE: NA -------------------------------- The pcie device ID of DPU_NIC card is 0x0224, need be added to nic_devID_list, otherwise card_node will be alloced for every PF. Signed-off-by: zhoushuai <zhoushuai28(a)huawei.com> --- drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c | 2 +- drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c index fdf92ab66e3b..5863beebde39 100644 --- a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c @@ -48,7 +48,7 @@ static int get_nic_drv_version(void *buf_out, const u32 *out_size) } err = snprintf(ver_info->ver, sizeof(ver_info->ver), "%s %s", - HINIC3_NIC_DRV_VERSION, "2023-05-17_19:56:38"); + HINIC3_NIC_DRV_VERSION, "2024-07-03_09:33:00"); if (err < 0) return -EINVAL; diff --git a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h index 0b7bf8e18732..a327c4a4e4ac 100644 --- a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h +++ b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h @@ -21,7 +21,9 @@ #define ULD_LOCK_MAX_USLEEP_TIME 1000 #define HINIC3_IS_VF_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_VF) -#define HINIC3_IS_SPU_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_SPU) +#define HINIC3_IS_SPU_DEV(pdev) \ + (((pdev)->device == HINIC3_DEV_ID_SPU) || ((pdev)->device == HINIC3_DEV_ID_SDI_5_0_PF) || \ + (((pdev)->device == HINIC3_DEV_ID_DPU_PF))) enum { HINIC3_NOT_PROBE = 1, -- 2.43.0

2 1

[PATCH OLK-6.6] net/hinic3: Add pcie device ID adaption for DPU_NIC card
by z00857956 03 Jul '24

03 Jul '24

From: zhoushuai <zhoushuai28(a)huawei.com> driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IA9G0T?from=project-issue CVE: NA -------------------------------- The pcie device ID of DPU_NIC card is 0x0224, need be added to nic_devID_list, otherwise card_node will be alloced for every PF. Signed-off-by: zhoushuai <zhoushuai28(a)huawei.com> --- drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c | 2 +- drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c index 40ff4738420e..93231ebac18e 100644 --- a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c @@ -48,7 +48,7 @@ static int get_nic_drv_version(void *buf_out, const u32 *out_size) } err = snprintf(ver_info->ver, sizeof(ver_info->ver), "%s %s", - HINIC3_NIC_DRV_VERSION, "2023-05-17_19:56:38"); + HINIC3_NIC_DRV_VERSION, "2024-07-03_09:33:00"); if (err < 0) return -EINVAL; diff --git a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h index bb7f5bb67ecb..7fd91117a0a3 100644 --- a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h +++ b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h @@ -21,7 +21,9 @@ #define ULD_LOCK_MAX_USLEEP_TIME 1000 #define HINIC3_IS_VF_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_VF) -#define HINIC3_IS_SPU_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_SPU) +#define HINIC3_IS_SPU_DEV(pdev) \ + (((pdev)->device == HINIC3_DEV_ID_SPU) || ((pdev)->device == HINIC3_DEV_ID_SDI_5_0_PF) || \ + (((pdev)->device == HINIC3_DEV_ID_DPU_PF))) enum { HINIC3_NOT_PROBE = 1, -- 2.43.0

2 1

[PATCH OLK-6.6] dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
by Zheng Zucheng 03 Jul '24

03 Jul '24

From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> mainline inclusion from mainline-v6.10-rc2 commit b794918961516f667b0c745aebdfebbb8a98df39 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DBQ CVE: CVE-2024-38780 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq(). Reported-by: syzbot <syzbot+a225ee3df7e7f9372dbe(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=a225ee3df7e7f9372dbe Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2e46020-aaa6-4e06-bf73-f0582… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/dma-buf/sync_debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c index 101394f16930..237bce21d1e7 100644 --- a/drivers/dma-buf/sync_debug.c +++ b/drivers/dma-buf/sync_debug.c @@ -110,12 +110,12 @@ static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj) seq_printf(s, "%s: %d\n", obj->name, obj->value); - spin_lock_irq(&obj->lock); + spin_lock(&obj->lock); /* Caller already disabled IRQ. */ list_for_each(pos, &obj->pt_list) { struct sync_pt *pt = container_of(pos, struct sync_pt, link); sync_print_fence(s, &pt->base, false); } - spin_unlock_irq(&obj->lock); + spin_unlock(&obj->lock); } static void sync_print_sync_file(struct seq_file *s, -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
by Zheng Zucheng 03 Jul '24

03 Jul '24

From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> mainline inclusion from mainline-v6.10-rc2 commit b794918961516f667b0c745aebdfebbb8a98df39 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DBQ CVE: CVE-2024-38780 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq(). Reported-by: syzbot <syzbot+a225ee3df7e7f9372dbe(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=a225ee3df7e7f9372dbe Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2e46020-aaa6-4e06-bf73-f0582… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/dma-buf/sync_debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c index 101394f16930..237bce21d1e7 100644 --- a/drivers/dma-buf/sync_debug.c +++ b/drivers/dma-buf/sync_debug.c @@ -110,12 +110,12 @@ static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj) seq_printf(s, "%s: %d\n", obj->name, obj->value); - spin_lock_irq(&obj->lock); + spin_lock(&obj->lock); /* Caller already disabled IRQ. */ list_for_each(pos, &obj->pt_list) { struct sync_pt *pt = container_of(pos, struct sync_pt, link); sync_print_fence(s, &pt->base, false); } - spin_unlock_irq(&obj->lock); + spin_unlock(&obj->lock); } static void sync_print_sync_file(struct seq_file *s, -- 2.34.1

2 1

[PATCH OLK-5.10] dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
by Zheng Zucheng 03 Jul '24

03 Jul '24

From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> mainline inclusion from mainline-v6.10-rc2 commit b794918961516f667b0c745aebdfebbb8a98df39 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DBQ CVE: CVE-2024-38780 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq(). Reported-by: syzbot <syzbot+a225ee3df7e7f9372dbe(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=a225ee3df7e7f9372dbe Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2e46020-aaa6-4e06-bf73-f0582… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/dma-buf/sync_debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c index 101394f16930..237bce21d1e7 100644 --- a/drivers/dma-buf/sync_debug.c +++ b/drivers/dma-buf/sync_debug.c @@ -110,12 +110,12 @@ static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj) seq_printf(s, "%s: %d\n", obj->name, obj->value); - spin_lock_irq(&obj->lock); + spin_lock(&obj->lock); /* Caller already disabled IRQ. */ list_for_each(pos, &obj->pt_list) { struct sync_pt *pt = container_of(pos, struct sync_pt, link); sync_print_fence(s, &pt->base, false); } - spin_unlock_irq(&obj->lock); + spin_unlock(&obj->lock); } static void sync_print_sync_file(struct seq_file *s, -- 2.34.1

2 1

[PATCH v2 openEuler-1.0-LTS] crypto: bcm - Fix pointer arithmetic
by liwei 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> mainline inclusion from mainline-v6.10-rc1 commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5T CVE: CVE-2024-38579 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/crypto/bcm/spu2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/bcm/spu2.c b/drivers/crypto/bcm/spu2.c index bf7ac621c591..0f6023347cc8 100644 --- a/drivers/crypto/bcm/spu2.c +++ b/drivers/crypto/bcm/spu2.c @@ -506,7 +506,7 @@ static void spu2_dump_omd(u8 *omd, u16 hash_key_len, u16 ciph_key_len, if (hash_iv_len) { packet_log(" Hash IV Length %u bytes\n", hash_iv_len); packet_dump(" hash IV: ", ptr, hash_iv_len); - ptr += ciph_key_len; + ptr += hash_iv_len; } if (ciph_iv_len) { -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
by Zheng Zucheng 03 Jul '24

03 Jul '24

From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> mainline inclusion from mainline-v6.10-rc2 commit b794918961516f667b0c745aebdfebbb8a98df39 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DBQ CVE: CVE-2024-38780 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq(). Reported-by: syzbot <syzbot+a225ee3df7e7f9372dbe(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=a225ee3df7e7f9372dbe Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2e46020-aaa6-4e06-bf73-f0582… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/dma-buf/sync_debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c index c4c8ecb24aa9..cfe31e52d78d 100644 --- a/drivers/dma-buf/sync_debug.c +++ b/drivers/dma-buf/sync_debug.c @@ -119,12 +119,12 @@ static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj) seq_printf(s, "%s: %d\n", obj->name, obj->value); - spin_lock_irq(&obj->lock); + spin_lock(&obj->lock); /* Caller already disabled IRQ. */ list_for_each(pos, &obj->pt_list) { struct sync_pt *pt = container_of(pos, struct sync_pt, link); sync_print_fence(s, &pt->base, false); } - spin_unlock_irq(&obj->lock); + spin_unlock(&obj->lock); } static void sync_print_sync_file(struct seq_file *s, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2021-47270
by Zheng Zucheng 03 Jul '24

03 Jul '24

Maciej Żenczykowski (1): usb: fix various gadgets null ptr deref on 10gbps cabling. Pavankumar Kondeti (1): usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS drivers/usb/gadget/function/f_ecm.c | 2 +- drivers/usb/gadget/function/f_eem.c | 2 +- drivers/usb/gadget/function/f_hid.c | 3 ++- drivers/usb/gadget/function/f_loopback.c | 2 +- drivers/usb/gadget/function/f_printer.c | 3 ++- drivers/usb/gadget/function/f_rndis.c | 2 +- drivers/usb/gadget/function/f_serial.c | 2 +- drivers/usb/gadget/function/f_sourcesink.c | 4 +++- drivers/usb/gadget/function/f_subset.c | 2 +- drivers/usb/gadget/function/f_tcm.c | 3 ++- 10 files changed, 15 insertions(+), 10 deletions(-) -- 2.34.1

2 3

[PATCH v3 openEuler-1.0-LTS 0/2] Fix CVE-2024-38567
by Li Huafei 03 Jul '24

03 Jul '24

Alan Stern (1): USB: core: Add routines for endpoint checks in old drivers Nikita Zhandarovich (1): wifi: carl9170: add a proper sanity check for endpoints drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++ drivers/usb/core/usb.c | 76 +++++++++++++++++++++++++ include/linux/usb.h | 5 ++ 3 files changed, 113 insertions(+) -- 2.25.1

2 3

[PATCH OLK-5.10] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 03 Jul '24

03 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 48774b90b5677bdb4 ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 48774b90b5677bdb4 ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 61cc9a13a40a..fc9908d79f93 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] iomap: Don't finish dio under irq when there exists pages
by Zhihao Cheng 03 Jul '24

03 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA4DAW CVE: NA -------------------------------- Since commit 6fac6d0e975afe1dec ("ext4: Optimize endio process for DIO overwrites"), pages invalidating won't be done in io completeing process, which could make generic/451 failed. In generic 451, there are two concurrent tasks: task A is reading(with page cache) a file, task B is directly writing and reading to verify content. Task B will verify failed in following process: task A task B direct_write(offs=L, content_Y) submit_IO content_X = read_page(offs=L) // stale data, because IO is not completed content_X = find_page(offs=L) // content_Y != content_X Fixes: 6fac6d0e975afe1dec ("ext4: Optimize endio process for DIO overwrites") Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/iomap/direct-io.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index ad12ffcc5085..4760a481e444 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -180,6 +180,11 @@ static void iomap_dio_bio_end_io(struct bio *bio) goto release_bio; } + if ((dio->flags & IOMAP_DIO_INLINE_COMP) && dio->size && + (dio->flags & IOMAP_DIO_WRITE) && + file_inode(iocb->ki_filp)->i_mapping->nrpages) + dio->flags &= ~IOMAP_DIO_INLINE_COMP; + /* * Flagged with IOMAP_DIO_INLINE_COMP, we can complete it inline */ -- 2.31.1

2 1

[PATCH OLK-5.10 V1] drm/msm: Fix null ptr access msm_ioctl_gem_submit()
by Cheng Yu 03 Jul '24

03 Jul '24

From: Akhil P Oommen <akhilpo(a)codeaurora.org> mainline inclusion from mainline-v5.16-rc4 commit 26d776fd0f79f093a5d0ce1a4c7c7a992bc3264c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SJ0 CVE: CVE-2021-47610 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix the below null pointer dereference in msm_ioctl_gem_submit(): 26545.260705: Call trace: 26545.263223: kref_put+0x1c/0x60 26545.266452: msm_ioctl_gem_submit+0x254/0x744 26545.270937: drm_ioctl_kernel+0xa8/0x124 26545.274976: drm_ioctl+0x21c/0x33c 26545.278478: drm_compat_ioctl+0xdc/0xf0 26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100 26545.287169: el0_svc_common+0xf8/0x250 26545.291025: do_el0_svc_compat+0x28/0x54 26545.295066: el0_svc_compat+0x10/0x1c 26545.298838: el0_sync_compat_handler+0xa8/0xcc 26545.303403: el0_sync_compat+0x188/0x1c0 26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008) 26545.318799: Kernel panic - not syncing: Oops: Fatal exception Signed-off-by: Akhil P Oommen <akhilpo(a)codeaurora.org> Link: https://lore.kernel.org/r/20211118154903.2.I3ae019673a0cc45d83a193a7858748d… Signed-off-by: Rob Clark <robdclark(a)chromium.org> Conflicts: drivers/gpu/drm/msm/msm_gem_submit.c [This is a conflict caused by commit 79341eb74c1f("drm/msm: Return ERR_PTR() from submit_create()") which is not merged and some context conflicts.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/gpu/drm/msm/msm_gem_submit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index c4e5037512b9..16f0fe22d81a 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -680,6 +680,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, args->nr_cmds); if (!submit) { ret = -ENOMEM; + submit = NULL; goto out_unlock; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS V1] drm/msm: Fix null ptr access msm_ioctl_gem_submit()
by Cheng Yu 03 Jul '24

03 Jul '24

From: Akhil P Oommen <akhilpo(a)codeaurora.org> mainline inclusion from mainline-v5.16-rc4 commit 26d776fd0f79f093a5d0ce1a4c7c7a992bc3264c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SJ0 CVE: CVE-2021-47610 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix the below null pointer dereference in msm_ioctl_gem_submit(): 26545.260705: Call trace: 26545.263223: kref_put+0x1c/0x60 26545.266452: msm_ioctl_gem_submit+0x254/0x744 26545.270937: drm_ioctl_kernel+0xa8/0x124 26545.274976: drm_ioctl+0x21c/0x33c 26545.278478: drm_compat_ioctl+0xdc/0xf0 26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100 26545.287169: el0_svc_common+0xf8/0x250 26545.291025: do_el0_svc_compat+0x28/0x54 26545.295066: el0_svc_compat+0x10/0x1c 26545.298838: el0_sync_compat_handler+0xa8/0xcc 26545.303403: el0_sync_compat+0x188/0x1c0 26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008) 26545.318799: Kernel panic - not syncing: Oops: Fatal exception Signed-off-by: Akhil P Oommen <akhilpo(a)codeaurora.org> Link: https://lore.kernel.org/r/20211118154903.2.I3ae019673a0cc45d83a193a7858748d… Signed-off-by: Rob Clark <robdclark(a)chromium.org> Conflicts: drivers/gpu/drm/msm/msm_gem_submit.c [This is a conflict caused by commit 79341eb74c1f("drm/msm: Return ERR_PTR() from submit_create()") which is not merged.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/gpu/drm/msm/msm_gem_submit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index 18fee169b236..01679abd5487 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -477,6 +477,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, submit = submit_create(dev, gpu, queue, args->nr_bos, args->nr_cmds); if (!submit) { ret = -ENOMEM; + submit = NULL; goto out_unlock; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
by Zhang Zekun 03 Jul '24

03 Jul '24

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.10-rc2 commit dc21c6cc3d6986d938efbf95de62473982c98dec category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D8D CVE: CVE-2024-36286 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------------------------------------- syzbot reported that nf_reinject() could be called without rcu_read_lock() : WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK> Fixes: 9872bec773c2 ("[NETFILTER]: nfnetlink: use RCU for queue instances hash") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- net/netfilter/nfnetlink_queue.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c index cd496b074a71..67b05ea4bfe0 100644 --- a/net/netfilter/nfnetlink_queue.c +++ b/net/netfilter/nfnetlink_queue.c @@ -171,7 +171,9 @@ instance_destroy_rcu(struct rcu_head *head) struct nfqnl_instance *inst = container_of(head, struct nfqnl_instance, rcu); + rcu_read_lock(); nfqnl_flush(inst, NULL, 0); + rcu_read_unlock(); kfree(inst); module_put(THIS_MODULE); } -- 2.17.1

2 1

[PATCH v2 openEuler-1.0-LTS 0/2] Fix CVE-2024-38567
by Li Huafei 03 Jul '24

03 Jul '24

Alan Stern (1): USB: core: Add routines for endpoint checks in old drivers Nikita Zhandarovich (1): wifi: carl9170: add a proper sanity check for endpoints drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++ drivers/usb/core/usb.c | 76 +++++++++++++++++++++++++ include/linux/usb.h | 5 ++ 3 files changed, 113 insertions(+) -- 2.25.1

2 3

[PATCH OLK-6.6] net/hinic3: Add pcie device ID adaption for DPU_NIC card
by z00857956 03 Jul '24

03 Jul '24

From: zhoushuai <zhoushuai28(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA9G0T?from=project-issue CVE: NA -------------------------------- The pcie device ID of DPU_NIC card is 0x0224, need be added to nic_devID_list, otherwise card_node will be alloced for every PF. Signed-off-by: zhoushuai <zhoushuai28(a)huawei.com> --- drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c | 2 +- drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c index 40ff4738420e..93231ebac18e 100644 --- a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c @@ -48,7 +48,7 @@ static int get_nic_drv_version(void *buf_out, const u32 *out_size) } err = snprintf(ver_info->ver, sizeof(ver_info->ver), "%s %s", - HINIC3_NIC_DRV_VERSION, "2023-05-17_19:56:38"); + HINIC3_NIC_DRV_VERSION, "2024-07-03_09:33:00"); if (err < 0) return -EINVAL; diff --git a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h index bb7f5bb67ecb..7fd91117a0a3 100644 --- a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h +++ b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h @@ -21,7 +21,9 @@ #define ULD_LOCK_MAX_USLEEP_TIME 1000 #define HINIC3_IS_VF_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_VF) -#define HINIC3_IS_SPU_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_SPU) +#define HINIC3_IS_SPU_DEV(pdev) \ + (((pdev)->device == HINIC3_DEV_ID_SPU) || ((pdev)->device == HINIC3_DEV_ID_SDI_5_0_PF) || \ + (((pdev)->device == HINIC3_DEV_ID_DPU_PF))) enum { HINIC3_NOT_PROBE = 1, -- 2.43.0

2 1

[PATCH OLK-5.10] net/hinic3: Add pcie device ID adaption for DPU_NIC card
by z00857956 03 Jul '24

03 Jul '24

From: zhoushuai <zhoushuai28(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA9G0T?from=project-issue CVE: NA -------------------------------- The pcie device ID of DPU_NIC card is 0x0224, need be added to nic_devID_list, otherwise card_node will be alloced for every PF. Signed-off-by: zhoushuai <zhoushuai28(a)huawei.com> --- drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c | 2 +- drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c index fdf92ab66e3b..5863beebde39 100644 --- a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c @@ -48,7 +48,7 @@ static int get_nic_drv_version(void *buf_out, const u32 *out_size) } err = snprintf(ver_info->ver, sizeof(ver_info->ver), "%s %s", - HINIC3_NIC_DRV_VERSION, "2023-05-17_19:56:38"); + HINIC3_NIC_DRV_VERSION, "2024-07-03_09:33:00"); if (err < 0) return -EINVAL; diff --git a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h index 0b7bf8e18732..a327c4a4e4ac 100644 --- a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h +++ b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h @@ -21,7 +21,9 @@ #define ULD_LOCK_MAX_USLEEP_TIME 1000 #define HINIC3_IS_VF_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_VF) -#define HINIC3_IS_SPU_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_SPU) +#define HINIC3_IS_SPU_DEV(pdev) \ + (((pdev)->device == HINIC3_DEV_ID_SPU) || ((pdev)->device == HINIC3_DEV_ID_SDI_5_0_PF) || \ + (((pdev)->device == HINIC3_DEV_ID_DPU_PF))) enum { HINIC3_NOT_PROBE = 1, -- 2.43.0

2 1

[PATCH OLK-6.6] greybus: lights: check return of get_channel_from_mode
by liwei 03 Jul '24

03 Jul '24

From: Rui Miguel Silva <rmfrfs(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit a1ba19a1ae7cd1e324685ded4ab563e78fe68648 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D18 CVE: CVE-2024-38637 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Reported-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> Suggested-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> Suggested-by: Alex Elder <elder(a)ieee.org> Signed-off-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20240325221549.2185265-1-rmfrfs@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/staging/greybus/light.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index c6bd86a5335a..9999f8401699 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -147,6 +147,9 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) channel = get_channel_from_mode(channel->light, GB_CHANNEL_MODE_TORCH); + if (!channel) + return -EINVAL; + /* For not flash we need to convert brightness to intensity */ intensity = channel->intensity_uA.min + (channel->intensity_uA.step * channel->led->brightness); @@ -549,7 +552,10 @@ static int gb_lights_light_v4l2_register(struct gb_light *light) } channel_flash = get_channel_from_mode(light, GB_CHANNEL_MODE_FLASH); - WARN_ON(!channel_flash); + if (!channel_flash) { + dev_err(dev, "failed to get flash channel from mode\n"); + return -EINVAL; + } fled = &channel_flash->fled; -- 2.25.1

2 1

[PATCH OLK-5.10] greybus: lights: check return of get_channel_from_mode
by liwei 03 Jul '24

03 Jul '24

From: Rui Miguel Silva <rmfrfs(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit a1ba19a1ae7cd1e324685ded4ab563e78fe68648 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D18 CVE: CVE-2024-38637 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Reported-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> Suggested-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> Suggested-by: Alex Elder <elder(a)ieee.org> Signed-off-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20240325221549.2185265-1-rmfrfs@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/staging/greybus/light.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index d2672b65c3f4..4fa97ae08408 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -147,6 +147,9 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) channel = get_channel_from_mode(channel->light, GB_CHANNEL_MODE_TORCH); + if (!channel) + return -EINVAL; + /* For not flash we need to convert brightness to intensity */ intensity = channel->intensity_uA.min + (channel->intensity_uA.step * channel->led->brightness); @@ -550,7 +553,10 @@ static int gb_lights_light_v4l2_register(struct gb_light *light) } channel_flash = get_channel_from_mode(light, GB_CHANNEL_MODE_FLASH); - WARN_ON(!channel_flash); + if (!channel_flash) { + dev_err(dev, "failed to get flash channel from mode\n"); + return -EINVAL; + } fled = &channel_flash->fled; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] greybus: lights: check return of get_channel_from_mode
by liwei 03 Jul '24

03 Jul '24

From: Rui Miguel Silva <rmfrfs(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit a1ba19a1ae7cd1e324685ded4ab563e78fe68648 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D18 CVE: CVE-2024-38637 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Reported-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> Suggested-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> Suggested-by: Alex Elder <elder(a)ieee.org> Signed-off-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20240325221549.2185265-1-rmfrfs@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/staging/greybus/light.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index d2672b65c3f4..4fa97ae08408 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -147,6 +147,9 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) channel = get_channel_from_mode(channel->light, GB_CHANNEL_MODE_TORCH); + if (!channel) + return -EINVAL; + /* For not flash we need to convert brightness to intensity */ intensity = channel->intensity_uA.min + (channel->intensity_uA.step * channel->led->brightness); @@ -550,7 +553,10 @@ static int gb_lights_light_v4l2_register(struct gb_light *light) } channel_flash = get_channel_from_mode(light, GB_CHANNEL_MODE_FLASH); - WARN_ON(!channel_flash); + if (!channel_flash) { + dev_err(dev, "failed to get flash channel from mode\n"); + return -EINVAL; + } fled = &channel_flash->fled; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] greybus: lights: check return of get_channel_from_mode
by liwei 03 Jul '24

03 Jul '24

From: Rui Miguel Silva <rmfrfs(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit a1ba19a1ae7cd1e324685ded4ab563e78fe68648 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D18 CVE: CVE-2024-38637 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Reported-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> Suggested-by: Mikhail Lobanov <m.lobanov(a)rosalinux.ru> Suggested-by: Alex Elder <elder(a)ieee.org> Signed-off-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Link: https://lore.kernel.org/r/20240325221549.2185265-1-rmfrfs@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/staging/greybus/light.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c index 010ae1e9c7fb..0b6714dfcd9b 100644 --- a/drivers/staging/greybus/light.c +++ b/drivers/staging/greybus/light.c @@ -149,6 +149,9 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel) channel = get_channel_from_mode(channel->light, GB_CHANNEL_MODE_TORCH); + if (!channel) + return -EINVAL; + /* For not flash we need to convert brightness to intensity */ intensity = channel->intensity_uA.min + (channel->intensity_uA.step * channel->led->brightness); @@ -552,7 +555,10 @@ static int gb_lights_light_v4l2_register(struct gb_light *light) } channel_flash = get_channel_from_mode(light, GB_CHANNEL_MODE_FLASH); - WARN_ON(!channel_flash); + if (!channel_flash) { + dev_err(dev, "failed to get flash channel from mode\n"); + return -EINVAL; + } fled = &channel_flash->fled; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] crypto: bcm - Fix pointer arithmetic
by liwei 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> from mainline-v6.10-rc1 commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5T CVE: CVE-2024-38579 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/crypto/bcm/spu2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/bcm/spu2.c b/drivers/crypto/bcm/spu2.c index bf7ac621c591..0f6023347cc8 100644 --- a/drivers/crypto/bcm/spu2.c +++ b/drivers/crypto/bcm/spu2.c @@ -506,7 +506,7 @@ static void spu2_dump_omd(u8 *omd, u16 hash_key_len, u16 ciph_key_len, if (hash_iv_len) { packet_log(" Hash IV Length %u bytes\n", hash_iv_len); packet_dump(" hash IV: ", ptr, hash_iv_len); - ptr += ciph_key_len; + ptr += hash_iv_len; } if (ciph_iv_len) { -- 2.25.1

2 1

[PATCH OLK-5.10] drm: vc4: Fix possible null pointer dereference
by Ze Zuo 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v5.10.219 commit 2d9adecc88ab678785b581ab021f039372c324cb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGI CVE: CVE-2024-38546 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c534b63bede6cb987c2946ed4d0b0013a52c5ba7 ] In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240409075622.11783-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 7e8620838de9..a86b65d6a93e 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1253,6 +1253,8 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) index = 1; addr = of_get_address(dev->of_node, index, NULL, NULL); + if (!addr) + return -EINVAL; vc4_hdmi->audio.dma_data.addr = be32_to_cpup(addr) + mai_data->offset; vc4_hdmi->audio.dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; -- 2.25.1

2 1

[PATCH OLK-6.6] crypto: bcm - Fix pointer arithmetic
by liwei 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> mainline inclusion from mainline-v6.10-rc1 commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5T CVE: CVE-2024-38579 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/crypto/bcm/spu2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/bcm/spu2.c b/drivers/crypto/bcm/spu2.c index 07989bb8c220..3fdc64b5a65e 100644 --- a/drivers/crypto/bcm/spu2.c +++ b/drivers/crypto/bcm/spu2.c @@ -495,7 +495,7 @@ static void spu2_dump_omd(u8 *omd, u16 hash_key_len, u16 ciph_key_len, if (hash_iv_len) { packet_log(" Hash IV Length %u bytes\n", hash_iv_len); packet_dump(" hash IV: ", ptr, hash_iv_len); - ptr += ciph_key_len; + ptr += hash_iv_len; } if (ciph_iv_len) { -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm: vc4: Fix possible null pointer dereference
by Ze Zuo 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v5.10.219 commit 2d9adecc88ab678785b581ab021f039372c324cb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGI CVE: CVE-2024-38546 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c534b63bede6cb987c2946ed4d0b0013a52c5ba7 ] In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240409075622.11783-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 08175c3dd374..c68410e63c4f 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1252,6 +1252,8 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) index = 1; addr = of_get_address(dev->of_node, index, NULL, NULL); + if (!addr) + return -EINVAL; vc4_hdmi->audio.dma_data.addr = be32_to_cpup(addr) + mai_data->offset; vc4_hdmi->audio.dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; -- 2.25.1

2 1

[openeuler:OLK-6.6 7625/10534] clang: warning: no such include directory: 'drivers/infiniband/hw/hiroce3/include/mag'
by kernel test robot 03 Jul '24

03 Jul '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 986fcc8fdfd8e0bd6f40bcc824a260c61bfaff31 commit: 5bc8dbb5fdf565625b2eea4080dbd70bade992b8 [7625/10534] infiniband/hw/hiroce3: Add Huawei Intelligent Network Card RDMA Driver config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20240703/202407031126.xcsqeJZv-lkp@…) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 326ba38a991250a8587a399a260b0f7af2c9166a) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240703/202407031126.xcsqeJZv-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/202407031126.xcsqeJZv-lkp@intel.com/ All warnings (new ones prefixed by >>): >> clang: warning: no such include directory: 'drivers/infiniband/hw/hiroce3/include/mag' [-Wmissing-include-dirs] In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_common.c:6: In file included from drivers/net/ethernet/huawei/hinic3/hinic3_hw.h:10: In file included from drivers/net/ethernet/huawei/hinic3/hinic3_crm.h:7: In file included from include/linux/pci.h:1663: In file included from include/linux/dmapool.h:14: In file included from include/linux/scatterlist.h:8: In file included from include/linux/mm.h:2204: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_common.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:9:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 9 | #include "roce_ccf_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_ccf_format.h:720:9: note: previous '#pragma pack' directive that modifies alignment is here 720 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_common.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:15: drivers/infiniband/hw/hiroce3/include/rdma/roce_dif_format.h:9:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 9 | #include "roce_verbs_mr_attr.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_mr_attr.h:328:9: note: previous '#pragma pack' directive that modifies alignment is here 328 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_common.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:15:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 15 | #include "roce_dif_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_mr_attr.h:328:9: note: previous '#pragma pack' directive that modifies alignment is here 328 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_common.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 8 | #include "rdma_ext_ctx_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:377:9: note: previous '#pragma pack' directive that modifies alignment is here 377 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_common.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 7 | #include "rdma_context_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:5179:9: note: previous '#pragma pack' directive that modifies alignment is here 5179 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_common.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:8:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 8 | #include "roce_verbs_pub.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_pub.h:223:9: note: previous '#pragma pack' directive that modifies alignment is here 223 | #pragma pack() | ^ 11 warnings generated. -- >> clang: warning: no such include directory: 'drivers/infiniband/hw/hiroce3/include/mag' [-Wmissing-include-dirs] In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq.h:7: In file included from include/rdma/ib_verbs.h:15: In file included from include/linux/ethtool.h:18: In file included from include/linux/if_ether.h:19: In file included from include/linux/skbuff.h:17: In file included from include/linux/bvec.h:10: In file included from include/linux/highmem.h:8: In file included from include/linux/cacheflush.h:5: In file included from arch/arm64/include/asm/cacheflush.h:11: In file included from include/linux/kgdb.h:19: In file included from include/linux/kprobes.h:28: In file included from include/linux/ftrace.h:13: In file included from include/linux/kallsyms.h:13: In file included from include/linux/mm.h:2204: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq.h:13: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:9:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 9 | #include "roce_ccf_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_ccf_format.h:720:9: note: previous '#pragma pack' directive that modifies alignment is here 720 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq.h:13: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:15: drivers/infiniband/hw/hiroce3/include/rdma/roce_dif_format.h:9:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 9 | #include "roce_verbs_mr_attr.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_mr_attr.h:328:9: note: previous '#pragma pack' directive that modifies alignment is here 328 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq.h:13: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:15:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 15 | #include "roce_dif_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_mr_attr.h:328:9: note: previous '#pragma pack' directive that modifies alignment is here 328 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq.h:13: drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 8 | #include "rdma_ext_ctx_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:377:9: note: previous '#pragma pack' directive that modifies alignment is here 377 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: drivers/infiniband/hw/hiroce3/cq/roce_cq.h:13:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 13 | #include "rdma_context_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:5179:9: note: previous '#pragma pack' directive that modifies alignment is here 5179 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq.h:15: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:8:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 8 | #include "roce_verbs_pub.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_pub.h:223:9: note: previous '#pragma pack' directive that modifies alignment is here 223 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq.h:15: drivers/infiniband/hw/hiroce3/roce.h:30:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 30 | #include "roce_verbs_cmd.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_pub.h:223:9: note: previous '#pragma pack' directive that modifies alignment is here 223 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_create.c:4: drivers/infiniband/hw/hiroce3/cq/roce_cq.h:15:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] -- >> clang: warning: no such include directory: 'drivers/infiniband/hw/hiroce3/include/mag' [-Wmissing-include-dirs] In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:6: In file included from drivers/net/ethernet/huawei/hinic3/hinic3_hw.h:10: In file included from drivers/net/ethernet/huawei/hinic3/hinic3_crm.h:7: In file included from include/linux/pci.h:1663: In file included from include/linux/dmapool.h:14: In file included from include/linux/scatterlist.h:8: In file included from include/linux/mm.h:2204: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:9:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 9 | #include "roce_ccf_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_ccf_format.h:720:9: note: previous '#pragma pack' directive that modifies alignment is here 720 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:15: drivers/infiniband/hw/hiroce3/include/rdma/roce_dif_format.h:9:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 9 | #include "roce_verbs_mr_attr.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_mr_attr.h:328:9: note: previous '#pragma pack' directive that modifies alignment is here 328 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:15:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 15 | #include "roce_dif_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_mr_attr.h:328:9: note: previous '#pragma pack' directive that modifies alignment is here 328 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 8 | #include "rdma_ext_ctx_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:377:9: note: previous '#pragma pack' directive that modifies alignment is here 377 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 7 | #include "rdma_context_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:5179:9: note: previous '#pragma pack' directive that modifies alignment is here 5179 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:8: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:8:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 8 | #include "roce_verbs_pub.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_pub.h:223:9: note: previous '#pragma pack' directive that modifies alignment is here 223 | #pragma pack() | ^ drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:63:5: warning: no previous prototype for function 'roce3_cq_hw2sw' [-Wmissing-prototypes] 63 | int roce3_cq_hw2sw(struct roce3_device *rdev, struct roce3_cq *cq) | ^ drivers/infiniband/hw/hiroce3/cq/roce_cq_destroy.c:63:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 63 | int roce3_cq_hw2sw(struct roce3_device *rdev, struct roce3_cq *cq) | ^ | static 12 warnings generated. -- >> clang: warning: no such include directory: 'drivers/infiniband/hw/hiroce3/include/mag' [-Wmissing-include-dirs] In file included from drivers/infiniband/hw/hiroce3/roce_main.c:4: In file included from include/net/ipv6.h:12: In file included from include/linux/ipv6.h:100: In file included from include/linux/tcp.h:17: In file included from include/linux/skbuff.h:17: In file included from include/linux/bvec.h:10: In file included from include/linux/highmem.h:8: In file included from include/linux/cacheflush.h:5: In file included from arch/arm64/include/asm/cacheflush.h:11: In file included from include/linux/kgdb.h:19: In file included from include/linux/kprobes.h:28: In file included from include/linux/ftrace.h:13: In file included from include/linux/kallsyms.h:13: In file included from include/linux/mm.h:2204: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/infiniband/hw/hiroce3/roce_main.c:26: In file included from drivers/infiniband/hw/hiroce3/roce_event.h:20: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:9:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 9 | #include "roce_ccf_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_ccf_format.h:720:9: note: previous '#pragma pack' directive that modifies alignment is here 720 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/roce_main.c:26: In file included from drivers/infiniband/hw/hiroce3/roce_event.h:20: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:15: drivers/infiniband/hw/hiroce3/include/rdma/roce_dif_format.h:9:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 9 | #include "roce_verbs_mr_attr.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_mr_attr.h:328:9: note: previous '#pragma pack' directive that modifies alignment is here 328 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/roce_main.c:26: In file included from drivers/infiniband/hw/hiroce3/roce_event.h:20: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: In file included from drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8: drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:15:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 15 | #include "roce_dif_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_mr_attr.h:328:9: note: previous '#pragma pack' directive that modifies alignment is here 328 | #pragma pack() | ^ In file included from drivers/infiniband/hw/hiroce3/roce_main.c:26: In file included from drivers/infiniband/hw/hiroce3/roce_event.h:20: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: In file included from drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7: drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:8:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 8 | #include "rdma_ext_ctx_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/rdma_ext_ctx_format.h:377:9: note: previous '#pragma pack' directive that modifies alignment is here 377 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/roce_main.c:26: In file included from drivers/infiniband/hw/hiroce3/roce_event.h:20: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:7:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 7 | #include "rdma_context_format.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/rdma_context_format.h:5179:9: note: previous '#pragma pack' directive that modifies alignment is here 5179 | #pragma pack(0) | ^ In file included from drivers/infiniband/hw/hiroce3/roce_main.c:26: In file included from drivers/infiniband/hw/hiroce3/roce_event.h:20: In file included from drivers/infiniband/hw/hiroce3/roce.h:30: drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_cmd.h:8:10: warning: the current #pragma pack alignment value is modified in the included file [-Wpragma-pack] 8 | #include "roce_verbs_pub.h" | ^ drivers/infiniband/hw/hiroce3/include/rdma/roce_verbs_pub.h:223:9: note: previous '#pragma pack' directive that modifies alignment is here 223 | #pragma pack() | ^ drivers/infiniband/hw/hiroce3/roce_main.c:1256:6: warning: no previous prototype for function 'roce3_need_proc_link_event' [-Wmissing-prototypes] .. -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 0/1] cgroup/cpuset: Make cpuset hotplug processing synchronous
by Chen Ridong 03 Jul '24

03 Jul '24

*** BLURB HERE *** Waiman Long (1): cgroup/cpuset: Make cpuset hotplug processing synchronous include/linux/cpuset.h | 3 -- kernel/cgroup/cpuset.c | 103 ++++++++++++++++++++++------------------- kernel/cpu.c | 48 ------------------- kernel/power/process.c | 2 - 4 files changed, 55 insertions(+), 101 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6] crypto: bcm - Fix pointer arithmetic
by liwei 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> mainline inclusion from mainline-v6.10-rc1 commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5T CVE: CVE-2024-38579 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/crypto/bcm/spu2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/bcm/spu2.c b/drivers/crypto/bcm/spu2.c index 07989bb8c220..3fdc64b5a65e 100644 --- a/drivers/crypto/bcm/spu2.c +++ b/drivers/crypto/bcm/spu2.c @@ -495,7 +495,7 @@ static void spu2_dump_omd(u8 *omd, u16 hash_key_len, u16 ciph_key_len, if (hash_iv_len) { packet_log(" Hash IV Length %u bytes\n", hash_iv_len); packet_dump(" hash IV: ", ptr, hash_iv_len); - ptr += ciph_key_len; + ptr += hash_iv_len; } if (ciph_iv_len) { -- 2.25.1

2 1

[PATCH OLK-5.10] net/hinic3: Add pcie device ID adaption for DPU_NIC card
by z00857956 03 Jul '24

03 Jul '24

From: zhoushuai <zhoushuai28(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA9G0T?from=project-issue CVE: NA -------------------------------- The pcie device ID of DPU_NIC card is 0x0224, need be added to nic_devID_list, otherwise card_node will be alloced for every PF. Signed-off-by: zhoushuai <zhoushuai28(a)huawei.com> --- drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c | 2 +- drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c index fdf92ab66e3b..5863beebde39 100644 --- a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c @@ -48,7 +48,7 @@ static int get_nic_drv_version(void *buf_out, const u32 *out_size) } err = snprintf(ver_info->ver, sizeof(ver_info->ver), "%s %s", - HINIC3_NIC_DRV_VERSION, "2023-05-17_19:56:38"); + HINIC3_NIC_DRV_VERSION, "2024-07-03_09:33:00"); if (err < 0) return -EINVAL; diff --git a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h index 0b7bf8e18732..fa758460e587 100644 --- a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h +++ b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h @@ -21,7 +21,9 @@ #define ULD_LOCK_MAX_USLEEP_TIME 1000 #define HINIC3_IS_VF_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_VF) -#define HINIC3_IS_SPU_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_SPU) +#define HINIC3_IS_SPU_DEV(pdev) \ + (((pdev)->device == HINIC3_DEV_ID_SPU) || ((pdev)->device == HINIC3_DEV_ID_SDI_5_0_PF) || \ + (((pdev)->device == HINIC3_DEV_ID_DPU_PF))) enum { HINIC3_NOT_PROBE = 1, -- 2.43.0

2 1

[PATCH OLK-6.6 0/1] cgroup/cpuset: Make cpuset hotplug processing synchronous
by Chen Ridong 03 Jul '24

03 Jul '24

*** BLURB HERE *** Waiman Long (1): cgroup/cpuset: Make cpuset hotplug processing synchronous include/linux/cpuset.h | 3 -- kernel/cgroup/cpuset.c | 103 ++++++++++++++++++++++------------------- kernel/cpu.c | 48 ------------------- kernel/power/process.c | 2 - 4 files changed, 55 insertions(+), 101 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10] crypto: bcm - Fix pointer arithmetic
by liwei 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> mainline inclusion from mainline-v6.10-rc1 commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5T CVE: CVE-2024-38579 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/crypto/bcm/spu2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/bcm/spu2.c b/drivers/crypto/bcm/spu2.c index c860ffb0b4c3..670d439f204c 100644 --- a/drivers/crypto/bcm/spu2.c +++ b/drivers/crypto/bcm/spu2.c @@ -495,7 +495,7 @@ static void spu2_dump_omd(u8 *omd, u16 hash_key_len, u16 ciph_key_len, if (hash_iv_len) { packet_log(" Hash IV Length %u bytes\n", hash_iv_len); packet_dump(" hash IV: ", ptr, hash_iv_len); - ptr += ciph_key_len; + ptr += hash_iv_len; } if (ciph_iv_len) { -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] ax25: Fix reference count leak issue of net_device
by Zhengchao Shao 03 Jul '24

03 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit 36e56b1b002bb26440403053f19f9e1a8bc075b2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SG4 CVE: CVE-2024-38554 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak. In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/7ce3b23a40d9084657ba1125432f0ecc380cbc80.17152470… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/ax25_dev.c [The conflict occurs because the commit a968c799eb1d("ax25: merge repeat codes in ax25_dev_device_down()") and a7d6e36b9ad0("ax25: Use kernel universal linked list to implement ax25_dev_list") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ax25/ax25_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c index 55a611f7239b..68a417cee39c 100644 --- a/net/ax25/ax25_dev.c +++ b/net/ax25/ax25_dev.c @@ -141,6 +141,7 @@ void ax25_dev_device_down(struct net_device *dev) } spin_unlock_bh(&ax25_dev_lock); dev->ax25_ptr = NULL; + dev_put(dev); ax25_dev_put(ax25_dev); } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ax25: Fix reference count leak issue of net_device
by Zhengchao Shao 03 Jul '24

03 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit 36e56b1b002bb26440403053f19f9e1a8bc075b2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SG4 CVE: CVE-2024-38554 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak. In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/7ce3b23a40d9084657ba1125432f0ecc380cbc80.17152470… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/ax25_dev.c [The conflict occurs because the commit a968c799eb1d("ax25: merge repeat codes in ax25_dev_device_down()") and a7d6e36b9ad0("ax25: Use kernel universal linked list to implement ax25_dev_list") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ax25/ax25_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c index d1d8d8a21ddd..f68f42c083c8 100644 --- a/net/ax25/ax25_dev.c +++ b/net/ax25/ax25_dev.c @@ -138,6 +138,7 @@ void ax25_dev_device_down(struct net_device *dev) } spin_unlock_bh(&ax25_dev_lock); dev->ax25_ptr = NULL; + dev_put(dev); ax25_dev_put(ax25_dev); } -- 2.34.1

2 1

[PATCH OLK-5.10] ax25: Fix reference count leak issue of net_device
by Zhengchao Shao 03 Jul '24

03 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit 36e56b1b002bb26440403053f19f9e1a8bc075b2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SG4 CVE: CVE-2024-38554 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak. In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/7ce3b23a40d9084657ba1125432f0ecc380cbc80.17152470… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/ax25_dev.c [The conflict occurs because the commit a968c799eb1d("ax25: merge repeat codes in ax25_dev_device_down()") and a7d6e36b9ad0("ax25: Use kernel universal linked list to implement ax25_dev_list") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ax25/ax25_dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c index d1d8d8a21ddd..f68f42c083c8 100644 --- a/net/ax25/ax25_dev.c +++ b/net/ax25/ax25_dev.c @@ -138,6 +138,7 @@ void ax25_dev_device_down(struct net_device *dev) } spin_unlock_bh(&ax25_dev_lock); dev->ax25_ptr = NULL; + dev_put(dev); ax25_dev_put(ax25_dev); } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] crypto: bcm - Fix pointer arithmetic
by liwei 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> mainline inclusion from mainline-v6.10-rc1 commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5T CVE: CVE-2024-38579 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: dengquan <dengquan9(a)huawei.com> --- drivers/crypto/bcm/spu2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/bcm/spu2.c b/drivers/crypto/bcm/spu2.c index c860ffb0b4c3..670d439f204c 100644 --- a/drivers/crypto/bcm/spu2.c +++ b/drivers/crypto/bcm/spu2.c @@ -495,7 +495,7 @@ static void spu2_dump_omd(u8 *omd, u16 hash_key_len, u16 ciph_key_len, if (hash_iv_len) { packet_log(" Hash IV Length %u bytes\n", hash_iv_len); packet_dump(" hash IV: ", ptr, hash_iv_len); - ptr += ciph_key_len; + ptr += hash_iv_len; } if (ciph_iv_len) { -- 2.25.1

2 1

[PATCH OLK-6.6] net/hinic3: Add pcie device ID adaption for DPU_NIC card
by z00857956 03 Jul '24

03 Jul '24

From: zhoushuai <zhoushuai28(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA9G0T?from=project-issue CVE: NA -------------------------------- The pcie device ID of DPU_NIC card is 0x0224, need be added to nic_devID_list, otherwise card_node will be alloced for every PF. Signed-off-by: zhoushuai <zhoushuai28(a)huawei.com> --- drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c | 2 +- drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c index 40ff4738420e..93231ebac18e 100644 --- a/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_dbg.c @@ -48,7 +48,7 @@ static int get_nic_drv_version(void *buf_out, const u32 *out_size) } err = snprintf(ver_info->ver, sizeof(ver_info->ver), "%s %s", - HINIC3_NIC_DRV_VERSION, "2023-05-17_19:56:38"); + HINIC3_NIC_DRV_VERSION, "2024-07-03_09:33:00"); if (err < 0) return -EINVAL; diff --git a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h index bb7f5bb67ecb..02898a85e7b7 100644 --- a/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h +++ b/drivers/net/ethernet/huawei/hinic3/hw/hinic3_dev_mgmt.h @@ -21,7 +21,9 @@ #define ULD_LOCK_MAX_USLEEP_TIME 1000 #define HINIC3_IS_VF_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_VF) -#define HINIC3_IS_SPU_DEV(pdev) ((pdev)->device == HINIC3_DEV_ID_SPU) +#define HINIC3_IS_SPU_DEV(pdev) \ + (((pdev)->device == HINIC3_DEV_ID_SPU) || ((pdev)->device == HINIC3_DEV_ID_SDI_5_0_PF) || \ + (((pdev)->device == HINIC3_DEV_ID_DPU_PF))) enum { HINIC3_NOT_PROBE = 1, -- 2.43.0

2 1

[PATCH OLK-6.6] tls: fix missing memory barrier in tls_init
by Liu Jian 03 Jul '24

03 Jul '24

From: "Dae R. Jeong" <threeearcat(a)gmail.com> stable inclusion from stable-v6.6.33 commit ab67c2fd3d070a21914d0c31319d3858ab4e199c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D88 CVE: CVE-2024-36489 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 91e61dd7a0af660408e87372d8330ceb218be302 ] In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot. Fixes: d5bee7374b68 ("net/tls: Annotate access to sk_prot with READ_ONCE/WRITE_ONCE") Signed-off-by: Yewon Choi <woni9911(a)gmail.com> Signed-off-by: Dae R. Jeong <threeearcat(a)gmail.com> Link: https://lore.kernel.org/netdev/ZU4OJG56g2V9z_H7@dragonet/T/ Link: https://lore.kernel.org/r/Zkx4vjSFp0mfpjQ2@libra05 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/tls/tls_main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index e97fcb502115..0a67b93a52ec 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -814,9 +814,17 @@ struct tls_context *tls_ctx_create(struct sock *sk) return NULL; mutex_init(&ctx->tx_lock); - rcu_assign_pointer(icsk->icsk_ulp_data, ctx); ctx->sk_proto = READ_ONCE(sk->sk_prot); ctx->sk = sk; + /* Release semantic of rcu_assign_pointer() ensures that + * ctx->sk_proto is visible before changing sk->sk_prot in + * update_sk_prot(), and prevents reading uninitialized value in + * tls_{getsockopt, setsockopt}. Note that we do not need a + * read barrier in tls_{getsockopt,setsockopt} as there is an + * address dependency between sk->sk_proto->{getsockopt,setsockopt} + * and ctx->sk_proto. + */ + rcu_assign_pointer(icsk->icsk_ulp_data, ctx); return ctx; } -- 2.34.1

2 1

[PATCH OLK-6.6] wifi: nl80211: Avoid address calculations via out of bounds array indexing
by Liu Jian 03 Jul '24

03 Jul '24

From: Kees Cook <keescook(a)chromium.org> stable inclusion from stable-v6.6.33 commit ed74398642fcb19f6ff385c35a7d512c6663e17b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SBS CVE: CVE-2024-38562 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 838c7b8f1f278404d9d684c34a8cb26dc41aaaa1 ] Before request->channels[] can be used, request->n_channels must be set. Additionally, address calculations for memory after the "channels" array need to be calculated from the allocation base ("request") rather than via the first "out of bounds" index of "channels", otherwise run-time bounds checking will throw a warning. Reported-by: Nathan Chancellor <nathan(a)kernel.org> Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Signed-off-by: Kees Cook <keescook(a)chromium.org> Tested-by: Nathan Chancellor <nathan(a)kernel.org> Link: https://msgid.link/20240424220057.work.819-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/wireless/nl80211.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index c4f08f7eb741..8f8f077e6cd4 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -9153,6 +9153,7 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info) struct wiphy *wiphy; int err, tmp, n_ssids = 0, n_channels, i; size_t ie_len, size; + size_t ssids_offset, ie_offset; wiphy = &rdev->wiphy; @@ -9198,21 +9199,20 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info) return -EINVAL; size = struct_size(request, channels, n_channels); + ssids_offset = size; size = size_add(size, array_size(sizeof(*request->ssids), n_ssids)); + ie_offset = size; size = size_add(size, ie_len); request = kzalloc(size, GFP_KERNEL); if (!request) return -ENOMEM; + request->n_channels = n_channels; if (n_ssids) - request->ssids = (void *)&request->channels[n_channels]; + request->ssids = (void *)request + ssids_offset; request->n_ssids = n_ssids; - if (ie_len) { - if (n_ssids) - request->ie = (void *)(request->ssids + n_ssids); - else - request->ie = (void *)(request->channels + n_channels); - } + if (ie_len) + request->ie = (void *)request + ie_offset; i = 0; if (scan_freqs) { -- 2.34.1

2 1

[PATCH OLK-6.6] ax25: Fix reference count leak issue of net_device
by Zhengchao Shao 03 Jul '24

03 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> stable inclusion from stable-v6.6.33 commit 965d940fb7414b310a22666503d2af69459c981b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SG4 CVE: CVE-2024-38554 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 36e56b1b002bb26440403053f19f9e1a8bc075b2 ] There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak. In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/7ce3b23a40d9084657ba1125432f0ecc380cbc80.17152470… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: net/ax25/ax25_dev.c [The conflict occurs because the commit a7d6e36b9ad0("ax25: Use kernel universal linked list to implement ax25_dev_list") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ax25/ax25_dev.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c index 282ec581c072..6f4ccb735653 100644 --- a/net/ax25/ax25_dev.c +++ b/net/ax25/ax25_dev.c @@ -128,10 +128,6 @@ void ax25_dev_device_down(struct net_device *dev) s = s->next; } - spin_unlock_bh(&ax25_dev_lock); - dev->ax25_ptr = NULL; - ax25_dev_put(ax25_dev); - return; unlock_put: spin_unlock_bh(&ax25_dev_lock); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] ftrace: Fix rcu warn in ftrace_location()
by Zheng Yejian 03 Jul '24

03 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAA3U5 CVE: NA --------------------------- Lockdep report that: WARNING: suspicious RCU usage ./include/linux/rcupdate.h:625 rcu_read_lock() used illegally while idle! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 2, debug_locks = 1 RCU used illegally from extended quiescent state! 1 lock held by swapper/0/0: #0: 000000003f648ecc (rcu_read_lock){....}, at: ftrace_location_range+0x0/0x400 kernel/trace/ftrace.c:1326 [...] Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x125/0x1ae lib/dump_stack.c:117 rcu_read_lock include/linux/rcupdate.h:624 [inline] ftrace_location_range+0x2e4/0x400 kernel/trace/ftrace.c:1613 ftrace_int3_handler+0x47/0x220 arch/x86/kernel/ftrace.c:304 do_int3+0x1d2/0x260 arch/x86/kernel/traps.c:592 int3+0x33/0x40 arch/x86/entry/entry_64.S:1170 [...] default_idle_call+0x3c/0x60 kernel/sched/idle.c:95 cpuidle_idle_call kernel/sched/idle.c:155 [inline] do_idle+0x28a/0x380 kernel/sched/idle.c:257 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:363 start_kernel+0x8bc/0x8fb init/main.c:744 secondary_startup_64+0xb7/0xc0 arch/x86/kernel/head_64.S:243 When function tracer is enabling, an 'int3' will be put at the fentry location of traced function, and before the fentry location being fully replaced as ftrace caller, any calls to the traced function will first redirect to call ftrace caller through ftrace_int3_handler(). When the traced function is called by idle task and rcu_read_lock() is indirectly called in ftrace_int3_handler(), then lockdep will warn that is illegal. RCU lock is not needed when ftrace_location() is called by ftrace_int3_handler() because that is an atomic context, so add in_atomic() check before hold or release RCU lock. Fixes: 85b642bd0701 ("ftrace: Fix possible use-after-free issue in ftrace_location()") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/ftrace.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 6704150cb655..ad4440da5b78 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1581,7 +1581,12 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) key.ip = start; key.flags = end; /* overload flags, as it is unsigned long */ - rcu_read_lock(); + /* + * It is in atomic context when called from ftrace_int3_handler(), + * in this case rcu lock is not needed. + */ + if (!in_atomic()) + rcu_read_lock(); for (pg = ftrace_pages_start; pg; pg = pg->next) { if (pg->index == 0 || end < pg->records[0].ip || @@ -1595,7 +1600,8 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) break; } } - rcu_read_unlock(); + if (!in_atomic()) + rcu_read_unlock(); return ip; } -- 2.25.1

2 1

[PATCH OLK-6.6 0/7] CVE-2024-38622
by Yongqiang Liu 03 Jul '24

03 Jul '24

Aleksandr Mishin (1): drm/msm/dpu: Add callback function pointer check before its call Dmitry Baryshkov (6): drm/msm/dpu: remove irq_idx argument from IRQ callbacks drm/msm/dpu: extract dpu_core_irq_is_valid() helper drm/msm/dpu: add helper to get IRQ-related data drm/msm/dpu: make the irq table size static drm/msm/dpu: stop using raw IRQ indices in the kernel output drm/msm/dpu: make error messages at dpu_core_irq_register_callback() more sensible drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 30 ++-- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 2 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 4 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 16 +-- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 131 +++++++++++------- .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 18 ++- 8 files changed, 119 insertions(+), 92 deletions(-) -- 2.34.1

2 8

[PATCH OLK-6.6] tls: fix missing memory barrier in tls_init
by Liu Jian 03 Jul '24

03 Jul '24

From: "Dae R. Jeong" <threeearcat(a)gmail.com> stable inclusion from stable-v6.6.33 commit ab67c2fd3d070a21914d0c31319d3858ab4e199c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D88 CVE: CVE-2024-36489 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 91e61dd7a0af660408e87372d8330ceb218be302 ] In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot. Fixes: d5bee7374b68 ("net/tls: Annotate access to sk_prot with READ_ONCE/WRITE_ONCE") Signed-off-by: Yewon Choi <woni9911(a)gmail.com> Signed-off-by: Dae R. Jeong <threeearcat(a)gmail.com> Link: https://lore.kernel.org/netdev/ZU4OJG56g2V9z_H7@dragonet/T/ Link: https://lore.kernel.org/r/Zkx4vjSFp0mfpjQ2@libra05 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/tls/tls_main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index e97fcb502115..0a67b93a52ec 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -814,9 +814,17 @@ struct tls_context *tls_ctx_create(struct sock *sk) return NULL; mutex_init(&ctx->tx_lock); - rcu_assign_pointer(icsk->icsk_ulp_data, ctx); ctx->sk_proto = READ_ONCE(sk->sk_prot); ctx->sk = sk; + /* Release semantic of rcu_assign_pointer() ensures that + * ctx->sk_proto is visible before changing sk->sk_prot in + * update_sk_prot(), and prevents reading uninitialized value in + * tls_{getsockopt, setsockopt}. Note that we do not need a + * read barrier in tls_{getsockopt,setsockopt} as there is an + * address dependency between sk->sk_proto->{getsockopt,setsockopt} + * and ctx->sk_proto. + */ + rcu_assign_pointer(icsk->icsk_ulp_data, ctx); return ctx; } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] tls: fix missing memory barrier in tls_init
by Liu Jian 03 Jul '24

03 Jul '24

From: "Dae R. Jeong" <threeearcat(a)gmail.com> stable inclusion from stable-v5.10.219 commit d72e126e9a36d3d33889829df8fc90100bb0e071 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D88 CVE: CVE-2024-36489 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 91e61dd7a0af660408e87372d8330ceb218be302 ] In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot. Fixes: d5bee7374b68 ("net/tls: Annotate access to sk_prot with READ_ONCE/WRITE_ONCE") Signed-off-by: Yewon Choi <woni9911(a)gmail.com> Signed-off-by: Dae R. Jeong <threeearcat(a)gmail.com> Link: https://lore.kernel.org/netdev/ZU4OJG56g2V9z_H7@dragonet/T/ Link: https://lore.kernel.org/r/Zkx4vjSFp0mfpjQ2@libra05 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/tls/tls_main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index 9d2254b2879d..ed30ab0bf1b8 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -674,9 +674,17 @@ struct tls_context *tls_ctx_create(struct sock *sk) return NULL; mutex_init(&ctx->tx_lock); - rcu_assign_pointer(icsk->icsk_ulp_data, ctx); ctx->sk_proto = READ_ONCE(sk->sk_prot); ctx->sk = sk; + /* Release semantic of rcu_assign_pointer() ensures that + * ctx->sk_proto is visible before changing sk->sk_prot in + * update_sk_prot(), and prevents reading uninitialized value in + * tls_{getsockopt, setsockopt}. Note that we do not need a + * read barrier in tls_{getsockopt,setsockopt} as there is an + * address dependency between sk->sk_proto->{getsockopt,setsockopt} + * and ctx->sk_proto. + */ + rcu_assign_pointer(icsk->icsk_ulp_data, ctx); return ctx; } -- 2.34.1

2 1

[PATCH OLK-5.10] tls: fix missing memory barrier in tls_init
by Liu Jian 03 Jul '24

03 Jul '24

From: "Dae R. Jeong" <threeearcat(a)gmail.com> stable inclusion from stable-v5.10.219 commit d72e126e9a36d3d33889829df8fc90100bb0e071 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D88 CVE: CVE-2024-36489 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 91e61dd7a0af660408e87372d8330ceb218be302 ] In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot. Fixes: d5bee7374b68 ("net/tls: Annotate access to sk_prot with READ_ONCE/WRITE_ONCE") Signed-off-by: Yewon Choi <woni9911(a)gmail.com> Signed-off-by: Dae R. Jeong <threeearcat(a)gmail.com> Link: https://lore.kernel.org/netdev/ZU4OJG56g2V9z_H7@dragonet/T/ Link: https://lore.kernel.org/r/Zkx4vjSFp0mfpjQ2@libra05 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/tls/tls_main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index b82c54cc3daf..3d6a4685ed60 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -708,9 +708,17 @@ struct tls_context *tls_ctx_create(struct sock *sk) return NULL; mutex_init(&ctx->tx_lock); - rcu_assign_pointer(icsk->icsk_ulp_data, ctx); ctx->sk_proto = READ_ONCE(sk->sk_prot); ctx->sk = sk; + /* Release semantic of rcu_assign_pointer() ensures that + * ctx->sk_proto is visible before changing sk->sk_prot in + * update_sk_prot(), and prevents reading uninitialized value in + * tls_{getsockopt, setsockopt}. Note that we do not need a + * read barrier in tls_{getsockopt,setsockopt} as there is an + * address dependency between sk->sk_proto->{getsockopt,setsockopt} + * and ctx->sk_proto. + */ + rcu_assign_pointer(icsk->icsk_ulp_data, ctx); return ctx; } -- 2.34.1

2 1

[PATCH v3 openEuler-22.03-LTS-SP1 0/2] Fix CVE-2024-38567
by Li Huafei 03 Jul '24

03 Jul '24

Alan Stern (1): USB: core: Add routines for endpoint checks in old drivers Nikita Zhandarovich (1): wifi: carl9170: add a proper sanity check for endpoints drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++ drivers/usb/core/usb.c | 76 +++++++++++++++++++++++++ include/linux/usb.h | 5 ++ 3 files changed, 113 insertions(+) -- 2.25.1

2 3

openEuler Kernel SIG双周例会
by openEuler conference 03 Jul '24

03 Jul '24

您好！ Kernel 邀请您参加 2024-07-05 14:00 召开的WeLink会议(自动录制) 会议主题：openEuler Kernel SIG双周例会会议内容： 1. 进展update 2. 议题征集中（新增议题可回复本邮件申请，或直接填写至会议纪要看板申报）会议链接：https://meeting.huaweicloud.com:36443/#/j/980862324 会议纪要：https://etherpad.openeuler.org/p/Kernel-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! Kernel invites you to attend the WeLink conference(auto recording) will be held at 2024-07-05 14:00, The subject of the conference is openEuler Kernel SIG双周例会, Summary: 1. 进展update 2. 议题征集中（新增议题可回复本邮件申请，或直接填写至会议纪要看板申报） You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/980862324. Add topics at https://etherpad.openeuler.org/p/Kernel-meetings. More information: https://www.openeuler.org/en/

1 0

[PATCH openEuler-1.0-LTS] nilfs2: fix potential kernel bug due to lack of writeback flag waiting
by dinglongwei 02 Jul '24

02 Jul '24

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> stable inclusion from stable-v6.1.95 commit 271dcd977ccda8c7a26e360425ae7b4db7d2ecc0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AE5 CVE: CVE-2024-37078 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a4ca369ca221bb7e06c725792ac107f0e48e82e7 upstream. Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state. Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state. Link: https://lkml.kernel.org/r/20240530141556.4411-1-konishi.ryusuke@gmail.com Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- fs/nilfs2/segment.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 808fb628577d..53f2d69fabbd 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -1658,6 +1658,7 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) if (bh->b_page != bd_page) { if (bd_page) { lock_page(bd_page); + wait_on_page_writeback(bd_page); clear_page_dirty_for_io(bd_page); set_page_writeback(bd_page); unlock_page(bd_page); @@ -1671,6 +1672,7 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) if (bh == segbuf->sb_super_root) { if (bh->b_page != bd_page) { lock_page(bd_page); + wait_on_page_writeback(bd_page); clear_page_dirty_for_io(bd_page); set_page_writeback(bd_page); unlock_page(bd_page); @@ -1687,6 +1689,7 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) } if (bd_page) { lock_page(bd_page); + wait_on_page_writeback(bd_page); clear_page_dirty_for_io(bd_page); set_page_writeback(bd_page); unlock_page(bd_page); -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/1] fix uaf when proc_cpuset_show
by Chen Ridong 02 Jul '24

02 Jul '24

*** BLURB HERE *** Chen Ridong (1): cgroup: fix uaf when proc_cpuset_show kernel/cgroup/cpuset.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
by Zheng Zucheng 02 Jul '24

02 Jul '24

From: Nicholas Piggin <npiggin(a)gmail.com> stable inclusion from stable-v5.10.54 commit e14ef1095387f764d95614d3ec9e4d07c82a3533 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4H1 CVE: CVE-2021-47296 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit bc4188a2f56e821ea057aca6bf444e138d06c252 ] vcpu_put is not called if the user copy fails. This can result in preempt notifier corruption and crashes, among other issues. Fixes: b3cebfe8c1ca ("KVM: PPC: Move vcpu_load/vcpu_put down to each ioctl case in kvm_arch_vcpu_ioctl") Reported-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20210716024310.164448-2-npiggin@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Acked-by: Weilong Chen <chenweilong(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- arch/powerpc/kvm/powerpc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index ee89f6fbea86..b9df096bfae9 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -1994,9 +1994,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp, { struct kvm_enable_cap cap; r = -EFAULT; - vcpu_load(vcpu); if (copy_from_user(&cap, argp, sizeof(cap))) goto out; + vcpu_load(vcpu); r = kvm_vcpu_ioctl_enable_cap(vcpu, &cap); vcpu_put(vcpu); break; @@ -2020,9 +2020,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp, case KVM_DIRTY_TLB: { struct kvm_dirty_tlb dirty; r = -EFAULT; - vcpu_load(vcpu); if (copy_from_user(&dirty, argp, sizeof(dirty))) goto out; + vcpu_load(vcpu); r = kvm_vcpu_ioctl_dirty_tlb(vcpu, &dirty); vcpu_put(vcpu); break; -- 2.34.1

2 1

[PATCH OLK-5.10 v2 0/6] CVE-2024-38586
by Liu Jian 02 Jul '24

02 Jul '24

CVE-2024-38586 Heiner Kallweit (5): r8169: remove unneeded memory barrier in rtl_tx r8169: use READ_ONCE in rtl_tx_slots_avail r8169: improve rtl_tx r8169: improve rtl8169_start_xmit r8169: remove nr_frags argument from rtl_tx_slots_avail Ken Milmore (1): r8169: Fix possible ring buffer corruption on fragmented Tx packets. drivers/net/ethernet/realtek/r8169_main.c | 44 ++++++++++------------- 1 file changed, 19 insertions(+), 25 deletions(-) -- 2.34.1

2 7

[PATCH openEuler-22.03-LTS-SP1 v2 0/6] CVE-2024-38586
by Liu Jian 02 Jul '24

02 Jul '24

CVE-2024-38586 Heiner Kallweit (5): r8169: remove unneeded memory barrier in rtl_tx r8169: use READ_ONCE in rtl_tx_slots_avail r8169: improve rtl_tx r8169: improve rtl8169_start_xmit r8169: remove nr_frags argument from rtl_tx_slots_avail Ken Milmore (1): r8169: Fix possible ring buffer corruption on fragmented Tx packets. drivers/net/ethernet/realtek/r8169_main.c | 44 ++++++++++------------- 1 file changed, 19 insertions(+), 25 deletions(-) -- 2.34.1

2 7

[PATCH openEuler-1.0-LTS] nfc: fix segfault in nfc_genl_dump_devices_done
by Hui Tang 02 Jul '24

02 Jul '24

From: Tadeusz Struk <tadeusz.struk(a)linaro.org> stable inclusion from stable-v4.19.222 commit 2a8845b9603c545fddd17862282dc4c4ce0971e3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SIZ CVE: CVE-2021-47612 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit fd79a0cbf0b2e34bcc45b13acf962e2032a82203 upstream. When kmalloc in nfc_genl_dump_devices() fails then nfc_genl_dump_devices_done() segfaults as below KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x80 Call Trace: <TASK> class_dev_iter_exit+0x15/0x20 nfc_genl_dump_devices_done+0x3b/0x50 genl_lock_done+0x84/0xd0 netlink_sock_destruct+0x8f/0x270 __sk_destruct+0x64/0x3b0 sk_destruct+0xa8/0xd0 __sk_free+0x2e8/0x3d0 sk_free+0x51/0x90 netlink_sock_destruct_work+0x1c/0x20 process_one_work+0x411/0x710 worker_thread+0x6fd/0xa80 Link: https://syzkaller.appspot.com/bug?id=fc0fa5a53db9edd261d56e74325419faf18bd0… Reported-by: syzbot+f9f76f4a0766420b4a02(a)syzkaller.appspotmail.com Signed-off-by: Tadeusz Struk <tadeusz.struk(a)linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> Link: https://lore.kernel.org/r/20211208182742.340542-1-tadeusz.struk@linaro.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- net/nfc/netlink.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c index 26f7703a8b62..9220bf8c2efb 100644 --- a/net/nfc/netlink.c +++ b/net/nfc/netlink.c @@ -651,8 +651,10 @@ static int nfc_genl_dump_devices_done(struct netlink_callback *cb) { struct class_dev_iter *iter = (struct class_dev_iter *) cb->args[0]; - nfc_device_iter_exit(iter); - kfree(iter); + if (iter) { + nfc_device_iter_exit(iter); + kfree(iter); + } return 0; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] mac80211: validate extended element ID is present
by Hui Tang 02 Jul '24

02 Jul '24

From: Johannes Berg <johannes.berg(a)intel.com> stable inclusion from stable-v4.19.222 commit 03029bb044ccee60adbc93e70713f3ae58abc3a1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SIX CVE: CVE-2021-47611 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit 768c0b19b50665e337c96858aa2b7928d6dcf756 upstream. Before attempting to parse an extended element, verify that the extended element ID is present. Fixes: 41cbb0f5a295 ("mac80211: add support for HE") Reported-by: syzbot+59bdff68edce82e393b6(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20211211201023.f30a1b128c07.I5cacc176da94ba316877… Cc: stable(a)vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- net/mac80211/util.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/mac80211/util.c b/net/mac80211/util.c index f101a6460b44..b8f43009409c 100644 --- a/net/mac80211/util.c +++ b/net/mac80211/util.c @@ -1096,6 +1096,8 @@ u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action, elems->max_idle_period_ie = (void *)pos; break; case WLAN_EID_EXTENSION: + if (!elen) + break; if (pos[0] == WLAN_EID_EXT_HE_MU_EDCA && elen >= (sizeof(*elems->mu_edca_param_set) + 1)) { elems->mu_edca_param_set = (void *)&pos[1]; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] ecryptfs: Fix buffer size for tag 66 packet
by Hui Tang 02 Jul '24

02 Jul '24

From: Brian Kubisiak <brian(a)kubisiak.com> stable inclusion from stable-v4.19.316 commit 1c125b9287e58f364d82174efb167414b92b11f1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S9H CVE: CVE-2024-38578 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 85a6a1aff08ec9f5b929d345d066e2830e8818e5 ] The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and write_tag_66_packet() will write up to 3 bytes past the end of the buffer. Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer. This fixes the below kasan slab-out-of-bounds bug: BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181 CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x4c/0x70 print_report+0xc5/0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? kasan_complete_mode_report_info+0x44/0x210 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 __asan_store1+0x62/0x80 ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10 ? __alloc_pages+0x2e2/0x540 ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d] ? dentry_open+0x8f/0xd0 ecryptfs_write_metadata+0x30a/0x550 ? __pfx_ecryptfs_write_metadata+0x10/0x10 ? ecryptfs_get_lower_file+0x6b/0x190 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 ? __pfx_path_openat+0x10/0x10 do_filp_open+0x15e/0x290 ? __pfx_do_filp_open+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? _raw_spin_lock+0x86/0xf0 ? __pfx__raw_spin_lock+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? alloc_fd+0xf4/0x330 do_sys_openat2+0x122/0x160 ? __pfx_do_sys_openat2+0x10/0x10 __x64_sys_openat+0xef/0x170 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f00a703fd67 Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 </TASK> Allocated by task 181: kasan_save_stack+0x2f/0x60 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x25/0x40 __kasan_kmalloc+0xc5/0xd0 __kmalloc+0x66/0x160 ecryptfs_generate_key_packet_set+0x6d2/0xde0 ecryptfs_write_metadata+0x30a/0x550 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 do_filp_open+0x15e/0x290 do_sys_openat2+0x122/0x160 __x64_sys_openat+0xef/0x170 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fixes: dddfa461fc89 ("[PATCH] eCryptfs: Public key; packet management") Signed-off-by: Brian Kubisiak <brian(a)kubisiak.com> Link: https://lore.kernel.org/r/5j2q56p6qkhezva6b2yuqfrsurmvrrqtxxzrnp3wqu7xrz22i… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- fs/ecryptfs/keystore.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c index e74fe84d0886..e573705a8b97 100644 --- a/fs/ecryptfs/keystore.c +++ b/fs/ecryptfs/keystore.c @@ -314,9 +314,11 @@ write_tag_66_packet(char *signature, u8 cipher_code, * | Key Identifier Size | 1 or 2 bytes | * | Key Identifier | arbitrary | * | File Encryption Key Size | 1 or 2 bytes | + * | Cipher Code | 1 byte | * | File Encryption Key | arbitrary | + * | Checksum | 2 bytes | */ - data_len = (5 + ECRYPTFS_SIG_SIZE_HEX + crypt_stat->key_size); + data_len = (8 + ECRYPTFS_SIG_SIZE_HEX + crypt_stat->key_size); *packet = kmalloc(data_len, GFP_KERNEL); message = *packet; if (!message) { -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] ALSA: timer: Set lower bound of start tick time
by Hui Tang 02 Jul '24

02 Jul '24

From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v4.19.316 commit 68396c825c43664b20a3a1ba546844deb2b4e48f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S6Y CVE: CVE-2024-38618 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit 4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e upstream. Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow. Reported-by: syzbot+43120c2af6ca2938cc38(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> [ backport note: the error handling is changed, as the original commit is based on the recent cleanup with guard() in commit beb45974dd49 -- tiwai ] Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Hui Tang <tanghui20(a)huawei.com> --- sound/core/timer.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index b5dc51030316..abf04f016ab2 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -528,6 +528,16 @@ static int snd_timer_start1(struct snd_timer_instance *timeri, goto unlock; } + /* check the actual time for the start tick; + * bail out as error if it's way too low (< 100us) + */ + if (start) { + if ((u64)snd_timer_hw_resolution(timer) * ticks < 100000) { + result = -EINVAL; + goto unlock; + } + } + if (start) timeri->ticks = timeri->cticks = ticks; else if (!timeri->cticks) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
by Cai Xinchen 02 Jul '24

02 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.219 commit 75c87e2ac6149abf44bdde0dd6d541763ddb0dff category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEB CVE: CVE-2024-39467 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 20faaf30e55522bba2b56d9c46689233205d7717 upstream. syzbot reports a kernel bug as below: F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4 ================================================================== BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline] BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076 CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline] f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838 __do_sys_ioctl fs/ioctl.c:902 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is we missed to do sanity check on i_xattr_nid during f2fs_iget(), so that in fiemap() path, current_nat_addr() will access nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering kasan bug report, fix it. Reported-and-tested-by: syzbot+3694e283cf5c40df6d14(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/00000000000094036c0616e72a1d@googl… Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- fs/f2fs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index 87752550f78c..aeafd8b73cbf 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -326,6 +326,12 @@ static bool sanity_check_inode(struct inode *inode, struct page *node_page) } } + if (fi->i_xattr_nid && f2fs_check_nid_range(sbi, fi->i_xattr_nid)) { + f2fs_warn(sbi, "%s: inode (ino=%lx) has corrupted i_xattr_nid: %u, run fsck to fix.", + __func__, inode->i_ino, fi->i_xattr_nid); + return false; + } + return true; } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] RDMA/hns: Modify the print level of CQE error
by Wang Hai 02 Jul '24

02 Jul '24

From: Chengchang Tang <tangchengchang(a)huawei.com> stable inclusion from stable-v5.10.219 commit 45b31be4dd22827903df15c548b97b416790139b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8B CVE: CVE-2024-38590 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 349e859952285ab9689779fb46de163f13f18f43 ] Too much print may lead to a panic in kernel. Change ibdev_err() to ibdev_err_ratelimited(), and change the printing level of cqe dump to debug level. Fixes: 7c044adca272 ("RDMA/hns: Simplify the cqe code of poll cq") Signed-off-by: Chengchang Tang <tangchengchang(a)huawei.com> Signed-off-by: Junxian Huang <huangjunxian6(a)hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-11-huangjunxian6@hisilicon.… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/infiniband/hw/hns/hns_roce_hw_v2.c [Only the context is different, and no code is modified.] Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c index 6e53864938c6..fa958ea9c569 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -4040,8 +4040,9 @@ static void get_cqe_status(struct hns_roce_dev *hr_dev, struct hns_roce_qp *qp, wc->status == IB_WC_WR_FLUSH_ERR)) return; - ibdev_err(&hr_dev->ib_dev, "error cqe status 0x%x:\n", cqe_status); - print_hex_dump(KERN_ERR, "", DUMP_PREFIX_NONE, 16, 4, cqe, + ibdev_err_ratelimited(&hr_dev->ib_dev, "error cqe status 0x%x:\n", + cqe_status); + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE, 16, 4, cqe, cq->cqe_size, false); wc->vendor_err = hr_reg_read(cqe, CQE_SUB_STATUS); -- 2.17.1

2 1

[PATCH OLK-6.6] f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
by Cai Xinchen 02 Jul '24

02 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.6.34 commit be0155202e431f3007778568a72432c68f8946ba category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEB CVE: CVE-2024-39467 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 20faaf30e55522bba2b56d9c46689233205d7717 upstream. syzbot reports a kernel bug as below: F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4 ================================================================== BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline] BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076 CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline] f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838 __do_sys_ioctl fs/ioctl.c:902 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is we missed to do sanity check on i_xattr_nid during f2fs_iget(), so that in fiemap() path, current_nat_addr() will access nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering kasan bug report, fix it. Reported-and-tested-by: syzbot+3694e283cf5c40df6d14(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/00000000000094036c0616e72a1d@googl… Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- fs/f2fs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index dd61449f05b8..ab2eecd986ec 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -361,6 +361,12 @@ static bool sanity_check_inode(struct inode *inode, struct page *node_page) return false; } + if (fi->i_xattr_nid && f2fs_check_nid_range(sbi, fi->i_xattr_nid)) { + f2fs_warn(sbi, "%s: inode (ino=%lx) has corrupted i_xattr_nid: %u, run fsck to fix.", + __func__, inode->i_ino, fi->i_xattr_nid); + return false; + } + return true; } -- 2.34.1

2 1

[PATCH v3 openEuler-22.03-LTS-SP1 0/2] Fix CVE-2024-38567
by Li Huafei 02 Jul '24

02 Jul '24

Alan Stern (1): USB: core: Add routines for endpoint checks in old drivers Nikita Zhandarovich (1): wifi: carl9170: add a proper sanity check for endpoints drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++ drivers/usb/core/usb.c | 76 +++++++++++++++++++++++++ include/linux/usb.h | 5 ++ 3 files changed, 113 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS] phonet: fix rtm_phonet_notify() skb allocation
by Wang Wensheng 02 Jul '24

02 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.314 commit ec1f71c05caeba0f814df77e0f511d8b4618623a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U4L2 CVE: CVE-2024-36946 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d8cac8568618dcb8a51af3db1103e8d4cc4aeea7 ] fill_route() stores three components in the skb: - struct rtmsg - RTA_DST (u8) - RTA_OIF (u32) Therefore, rtm_phonet_notify() should use NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(1) + nla_total_size(4) Fixes: f062f41d0657 ("Phonet: routing table Netlink interface") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Rémi Denis-Courmont <courmisch(a)gmail.com> Link: https://lore.kernel.org/r/20240502161700.1804476-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/phonet/pn_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c index 871eaf2cb85e..5e50f9ea7484 100644 --- a/net/phonet/pn_netlink.c +++ b/net/phonet/pn_netlink.c @@ -206,7 +206,7 @@ void rtm_phonet_notify(int event, struct net_device *dev, u8 dst) struct sk_buff *skb; int err = -ENOBUFS; - skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct ifaddrmsg)) + + skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(1) + nla_total_size(4), GFP_KERNEL); if (skb == NULL) goto errout; -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
by Zheng Zucheng 02 Jul '24

02 Jul '24

From: Nicholas Piggin <npiggin(a)gmail.com> stable inclusion from stable-v5.10.54 commit e14ef1095387f764d95614d3ec9e4d07c82a3533 bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4H1 CVE: CVE-2021-47296 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit bc4188a2f56e821ea057aca6bf444e138d06c252 ] vcpu_put is not called if the user copy fails. This can result in preempt notifier corruption and crashes, among other issues. Fixes: b3cebfe8c1ca ("KVM: PPC: Move vcpu_load/vcpu_put down to each ioctl case in kvm_arch_vcpu_ioctl") Reported-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20210716024310.164448-2-npiggin@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Acked-by: Weilong Chen <chenweilong(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- arch/powerpc/kvm/powerpc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index ee89f6fbea86..b9df096bfae9 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -1994,9 +1994,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp, { struct kvm_enable_cap cap; r = -EFAULT; - vcpu_load(vcpu); if (copy_from_user(&cap, argp, sizeof(cap))) goto out; + vcpu_load(vcpu); r = kvm_vcpu_ioctl_enable_cap(vcpu, &cap); vcpu_put(vcpu); break; @@ -2020,9 +2020,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp, case KVM_DIRTY_TLB: { struct kvm_dirty_tlb dirty; r = -EFAULT; - vcpu_load(vcpu); if (copy_from_user(&dirty, argp, sizeof(dirty))) goto out; + vcpu_load(vcpu); r = kvm_vcpu_ioctl_dirty_tlb(vcpu, &dirty); vcpu_put(vcpu); break; -- 2.34.1

2 1

[PATCH OLK-5.10 0/1] fix uaf when proc_cpuset_show
by Chen Ridong 02 Jul '24

02 Jul '24

*** BLURB HERE *** Chen Ridong (1): cgroup: fix uaf when proc_cpuset_show kernel/cgroup/cpuset.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) -- 2.34.1

2 2

[PATCH OLK-5.10] f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
by Cai Xinchen 02 Jul '24

02 Jul '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.219 commit 75c87e2ac6149abf44bdde0dd6d541763ddb0dff category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEB CVE: CVE-2024-39467 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 20faaf30e55522bba2b56d9c46689233205d7717 upstream. syzbot reports a kernel bug as below: F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4 ================================================================== BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline] BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076 CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline] f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838 __do_sys_ioctl fs/ioctl.c:902 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is we missed to do sanity check on i_xattr_nid during f2fs_iget(), so that in fiemap() path, current_nat_addr() will access nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering kasan bug report, fix it. Reported-and-tested-by: syzbot+3694e283cf5c40df6d14(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/00000000000094036c0616e72a1d@googl… Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- fs/f2fs/inode.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index 87752550f78c..aeafd8b73cbf 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -326,6 +326,12 @@ static bool sanity_check_inode(struct inode *inode, struct page *node_page) } } + if (fi->i_xattr_nid && f2fs_check_nid_range(sbi, fi->i_xattr_nid)) { + f2fs_warn(sbi, "%s: inode (ino=%lx) has corrupted i_xattr_nid: %u, run fsck to fix.", + __func__, inode->i_ino, fi->i_xattr_nid); + return false; + } + return true; } -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] CVE-2024-38582
by Yifan Qiao 02 Jul '24

02 Jul '24

Ryusuke Konishi (2): nilfs2: fix unexpected freezing of nilfs_segctor_sync() nilfs2: fix potential hang in nilfs_detach_log_writer() fs/nilfs2/segment.c | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-38582
by Yifan Qiao 02 Jul '24

02 Jul '24

Ryusuke Konishi (2): nilfs2: fix unexpected freezing of nilfs_segctor_sync() nilfs2: fix potential hang in nilfs_detach_log_writer() fs/nilfs2/segment.c | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) -- 2.39.2

2 3

[PATCH OLK-5.10 0/2] CVE-2024-38582
by Yifan Qiao 02 Jul '24

02 Jul '24

Ryusuke Konishi (2): nilfs2: fix unexpected freezing of nilfs_segctor_sync() nilfs2: fix potential hang in nilfs_detach_log_writer() fs/nilfs2/segment.c | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-22.03-LTS-SP1] ipv6: sr: fix invalid unregister error path
by Dong Chenchen 02 Jul '24

02 Jul '24

From: Hangbin Liu <liuhangbin(a)gmail.com> stable inclusion from stable-v5.10.219 commit 00e6335329f23ac6cf3105931691674e28bc598c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHW CVE: CVE-2024-38612 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 160e9d2752181fcf18c662e74022d77d3164cd45 ] The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. Fixes: 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support") Reported-by: Guillaume Nault <gnault(a)redhat.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240509131812.1662197-4-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ipv6/seg6.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c index d59eef2f41c6..327e231021e3 100644 --- a/net/ipv6/seg6.c +++ b/net/ipv6/seg6.c @@ -494,6 +494,8 @@ int __init seg6_init(void) #endif #ifdef CONFIG_IPV6_SEG6_LWTUNNEL out_unregister_genl: +#endif +#if IS_ENABLED(CONFIG_IPV6_SEG6_LWTUNNEL) || IS_ENABLED(CONFIG_IPV6_SEG6_HMAC) genl_unregister_family(&seg6_genl_family); #endif out_unregister_pernet: -- 2.25.1

2 1

[PATCH OLK-5.10] ipv6: sr: fix invalid unregister error path
by Dong Chenchen 02 Jul '24

02 Jul '24

From: Hangbin Liu <liuhangbin(a)gmail.com> stable inclusion from stable-v5.10.219 commit 00e6335329f23ac6cf3105931691674e28bc598c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHW CVE: CVE-2024-38612 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 160e9d2752181fcf18c662e74022d77d3164cd45 ] The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. Fixes: 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support") Reported-by: Guillaume Nault <gnault(a)redhat.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240509131812.1662197-4-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ipv6/seg6.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c index d59eef2f41c6..327e231021e3 100644 --- a/net/ipv6/seg6.c +++ b/net/ipv6/seg6.c @@ -494,6 +494,8 @@ int __init seg6_init(void) #endif #ifdef CONFIG_IPV6_SEG6_LWTUNNEL out_unregister_genl: +#endif +#if IS_ENABLED(CONFIG_IPV6_SEG6_LWTUNNEL) || IS_ENABLED(CONFIG_IPV6_SEG6_HMAC) genl_unregister_family(&seg6_genl_family); #endif out_unregister_pernet: -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] ipv6: sr: fix invalid unregister error path
by Dong Chenchen 02 Jul '24

02 Jul '24

From: Hangbin Liu <liuhangbin(a)gmail.com> stable inclusion from stable-v4.19.316 commit 10610575a3ac2a702bf5c57aa931beaf847949c7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHW CVE: CVE-2024-38612 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 160e9d2752181fcf18c662e74022d77d3164cd45 ] The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. Fixes: 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support") Reported-by: Guillaume Nault <gnault(a)redhat.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240509131812.1662197-4-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/ipv6/seg6.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c index 4bd601c96434..001566dcc8ce 100644 --- a/net/ipv6/seg6.c +++ b/net/ipv6/seg6.c @@ -484,6 +484,8 @@ int __init seg6_init(void) #endif #ifdef CONFIG_IPV6_SEG6_LWTUNNEL out_unregister_genl: +#endif +#if IS_ENABLED(CONFIG_IPV6_SEG6_LWTUNNEL) || IS_ENABLED(CONFIG_IPV6_SEG6_HMAC) genl_unregister_family(&seg6_genl_family); #endif out_unregister_pernet: -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ice: Do not use WQ_MEM_RECLAIM flag for workqueue
by Yu Liao 02 Jul '24

02 Jul '24

From: Anirudh Venkataramanan <anirudh.venkataramanan(a)intel.com> stable inclusion from stable-v5.10.168 commit 1ad4112c9fcf0bc08222b2b1614fba52ffd12255 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4N2 CVE: CVE-2023-52743 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------- [ Upstream commit 4d159f7884f78b1aacb99b4fc37d1e3cb1194e39 ] When both ice and the irdma driver are loaded, a warning in check_flush_dependency is being triggered. This is due to ice driver workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one is not. According to kernel documentation, this flag should be set if the workqueue will be involved in the kernel's memory reclamation flow. Since it is not, there is no need for the ice driver's WQ to have this flag set so remove it. Example trace: [ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0 [ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel _rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1 0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_ core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ +0.000161] [last unloaded: bonding] [ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1 [ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020 [ +0.000003] Workqueue: ice ice_service_task [ice] [ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0 [ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08 9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06 [ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282 [ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000 [ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80 [ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112 [ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000 [ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400 [ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000 [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0 [ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000002] PKRU: 55555554 [ +0.000003] Call Trace: [ +0.000002] <TASK> [ +0.000003] __flush_workqueue+0x203/0x840 [ +0.000006] ? mutex_unlock+0x84/0xd0 [ +0.000008] ? __pfx_mutex_unlock+0x10/0x10 [ +0.000004] ? __pfx___flush_workqueue+0x10/0x10 [ +0.000006] ? mutex_lock+0xa3/0xf0 [ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core] [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core] [ +0.000094] ib_unregister_device+0x25/0x30 [ib_core] [ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma] [ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma] [ +0.000059] ? up_write+0x5c/0x90 [ +0.000005] irdma_remove+0x36/0x90 [irdma] [ +0.000062] auxiliary_bus_remove+0x32/0x50 [ +0.000007] device_release_driver_internal+0xfa/0x1c0 [ +0.000005] bus_remove_device+0x18a/0x260 [ +0.000007] device_del+0x2e5/0x650 [ +0.000005] ? __pfx_device_del+0x10/0x10 [ +0.000003] ? mutex_unlock+0x84/0xd0 [ +0.000004] ? __pfx_mutex_unlock+0x10/0x10 [ +0.000004] ? _raw_spin_unlock+0x18/0x40 [ +0.000005] ice_unplug_aux_dev+0x52/0x70 [ice] [ +0.000160] ice_service_task+0x1309/0x14f0 [ice] [ +0.000134] ? __pfx___schedule+0x10/0x10 [ +0.000006] process_one_work+0x3b1/0x6c0 [ +0.000008] worker_thread+0x69/0x670 [ +0.000005] ? __kthread_parkme+0xec/0x110 [ +0.000007] ? __pfx_worker_thread+0x10/0x10 [ +0.000005] kthread+0x17f/0x1b0 [ +0.000005] ? __pfx_kthread+0x10/0x10 [ +0.000004] ret_from_fork+0x29/0x50 [ +0.000009] </TASK> Fixes: 940b61af02f4 ("ice: Initialize PF and setup miscellaneous interrupt") Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan(a)intel.com> Signed-off-by: Marcin Szycik <marcin.szycik(a)linux.intel.com> Tested-by: Jakub Andrysiak <jakub.andrysiak(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: zhaoxiaoqiang11 <zhaoxiaoqiang11(a)jd.com> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c index ba104db155c8..a3e315174ff5 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -4853,7 +4853,7 @@ static int __init ice_module_init(void) pr_info("%s\n", ice_driver_string); pr_info("%s\n", ice_copyright); - ice_wq = alloc_workqueue("%s", WQ_MEM_RECLAIM, 0, KBUILD_MODNAME); + ice_wq = alloc_workqueue("%s", 0, 0, KBUILD_MODNAME); if (!ice_wq) { pr_err("Failed to create workqueue\n"); return -ENOMEM; -- 2.33.0

2 1

[PATCH openEuler-22.03-LTS-SP1 0/4] fix CVE-2022-48721
by Zhengchao Shao 02 Jul '24

02 Jul '24

Fix CVE-2022-48721. Wen Gu (4): net/smc: Forward wakeup to smc socket waitqueue after fallback net/smc: Avoid overwriting the copies of clcsock callback functions net/smc: Only save the original clcsock callback functions net/smc: Fix slab-out-of-bounds issue in fallback net/smc/af_smc.c | 193 +++++++++++++++++++++++++++++++++++++++----- net/smc/smc.h | 49 ++++++++++- net/smc/smc_close.c | 5 +- 3 files changed, 227 insertions(+), 20 deletions(-) -- 2.34.1

2 5

[PATCH openEuler-1.0-LTS] usb: fix various gadgets null ptr deref on 10gbps cabling.
by Zheng Zucheng 02 Jul '24

02 Jul '24

From: Maciej Żenczykowski <maze(a)google.com> stable inclusion from stable-v5.10.44 commit 4b289a0f3033f465b4fd51ba995251a7867a2aa2 bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4K4 CVE: CVE-2021-47270 -------------------------------- commit 90c4d05780d47e14a50e11a7f17373104cd47d25 upstream. This avoids a null pointer dereference in f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} by simply reusing the 5gbps config for 10gbps. Fixes: eaef50c76057 ("usb: gadget: Update usb_assign_descriptors for SuperSpeedPlus") Cc: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Felipe Balbi <balbi(a)kernel.org> Cc: Gustavo A. R. Silva <gustavoars(a)kernel.org> Cc: Lorenzo Colitti <lorenzo(a)google.com> Cc: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Michael R Sweet <msweet(a)msweet.org> Cc: Mike Christie <michael.christie(a)oracle.com> Cc: Pawel Laszczak <pawell(a)cadence.com> Cc: Peter Chen <peter.chen(a)nxp.com> Cc: Sudhakar Panneerselvam <sudhakar.panneerselvam(a)oracle.com> Cc: Wei Ming Chen <jj251510319013(a)gmail.com> Cc: Will McVicker <willmcvicker(a)google.com> Cc: Zqiang <qiang.zhang(a)windriver.com> Reviewed-By: Lorenzo Colitti <lorenzo(a)google.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Maciej Żenczykowski <maze(a)google.com> Link: https://lore.kernel.org/r/20210608044141.3898496-1-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Acked-by: Weilong Chen <chenweilong(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/usb/gadget/function/f_ecm.c | 2 +- drivers/usb/gadget/function/f_eem.c | 2 +- drivers/usb/gadget/function/f_hid.c | 3 ++- drivers/usb/gadget/function/f_loopback.c | 2 +- drivers/usb/gadget/function/f_printer.c | 3 ++- drivers/usb/gadget/function/f_rndis.c | 2 +- drivers/usb/gadget/function/f_serial.c | 2 +- drivers/usb/gadget/function/f_sourcesink.c | 3 ++- drivers/usb/gadget/function/f_subset.c | 2 +- drivers/usb/gadget/function/f_tcm.c | 3 ++- 10 files changed, 14 insertions(+), 10 deletions(-) diff --git a/drivers/usb/gadget/function/f_ecm.c b/drivers/usb/gadget/function/f_ecm.c index 460d5d7c984f..fc4419f0bf74 100644 --- a/drivers/usb/gadget/function/f_ecm.c +++ b/drivers/usb/gadget/function/f_ecm.c @@ -788,7 +788,7 @@ ecm_bind(struct usb_configuration *c, struct usb_function *f) fs_ecm_notify_desc.bEndpointAddress; status = usb_assign_descriptors(f, ecm_fs_function, ecm_hs_function, - ecm_ss_function, NULL); + ecm_ss_function, ecm_ss_function); if (status) goto fail; diff --git a/drivers/usb/gadget/function/f_eem.c b/drivers/usb/gadget/function/f_eem.c index c13befa31110..3f56e1ce4e0e 100644 --- a/drivers/usb/gadget/function/f_eem.c +++ b/drivers/usb/gadget/function/f_eem.c @@ -305,7 +305,7 @@ static int eem_bind(struct usb_configuration *c, struct usb_function *f) eem_ss_out_desc.bEndpointAddress = eem_fs_out_desc.bEndpointAddress; status = usb_assign_descriptors(f, eem_fs_function, eem_hs_function, - eem_ss_function, NULL); + eem_ss_function, eem_ss_function); if (status) goto fail; diff --git a/drivers/usb/gadget/function/f_hid.c b/drivers/usb/gadget/function/f_hid.c index f3816a5c861e..0586229ac83d 100644 --- a/drivers/usb/gadget/function/f_hid.c +++ b/drivers/usb/gadget/function/f_hid.c @@ -808,7 +808,8 @@ static int hidg_bind(struct usb_configuration *c, struct usb_function *f) hidg_fs_out_ep_desc.bEndpointAddress; status = usb_assign_descriptors(f, hidg_fs_descriptors, - hidg_hs_descriptors, hidg_ss_descriptors, NULL); + hidg_hs_descriptors, hidg_ss_descriptors, + hidg_ss_descriptors); if (status) goto fail; diff --git a/drivers/usb/gadget/function/f_loopback.c b/drivers/usb/gadget/function/f_loopback.c index 1803646b3678..90215a81c178 100644 --- a/drivers/usb/gadget/function/f_loopback.c +++ b/drivers/usb/gadget/function/f_loopback.c @@ -207,7 +207,7 @@ static int loopback_bind(struct usb_configuration *c, struct usb_function *f) ss_loop_sink_desc.bEndpointAddress = fs_loop_sink_desc.bEndpointAddress; ret = usb_assign_descriptors(f, fs_loopback_descs, hs_loopback_descs, - ss_loopback_descs, NULL); + ss_loopback_descs, ss_loopback_descs); if (ret) return ret; diff --git a/drivers/usb/gadget/function/f_printer.c b/drivers/usb/gadget/function/f_printer.c index 8ed1295d7e35..32de1f5343d0 100644 --- a/drivers/usb/gadget/function/f_printer.c +++ b/drivers/usb/gadget/function/f_printer.c @@ -1063,7 +1063,8 @@ static int printer_func_bind(struct usb_configuration *c, ss_ep_out_desc.bEndpointAddress = fs_ep_out_desc.bEndpointAddress; ret = usb_assign_descriptors(f, fs_printer_function, - hs_printer_function, ss_printer_function, NULL); + hs_printer_function, ss_printer_function, + ss_printer_function); if (ret) return ret; diff --git a/drivers/usb/gadget/function/f_rndis.c b/drivers/usb/gadget/function/f_rndis.c index 0d8e4a364ca6..8b09dfcadf89 100644 --- a/drivers/usb/gadget/function/f_rndis.c +++ b/drivers/usb/gadget/function/f_rndis.c @@ -787,7 +787,7 @@ rndis_bind(struct usb_configuration *c, struct usb_function *f) ss_notify_desc.bEndpointAddress = fs_notify_desc.bEndpointAddress; status = usb_assign_descriptors(f, eth_fs_function, eth_hs_function, - eth_ss_function, NULL); + eth_ss_function, eth_ss_function); if (status) goto fail; diff --git a/drivers/usb/gadget/function/f_serial.c b/drivers/usb/gadget/function/f_serial.c index c860f30a0ea2..6db973d0c252 100644 --- a/drivers/usb/gadget/function/f_serial.c +++ b/drivers/usb/gadget/function/f_serial.c @@ -233,7 +233,7 @@ static int gser_bind(struct usb_configuration *c, struct usb_function *f) gser_ss_out_desc.bEndpointAddress = gser_fs_out_desc.bEndpointAddress; status = usb_assign_descriptors(f, gser_fs_function, gser_hs_function, - gser_ss_function, NULL); + gser_ss_function, gser_ss_function); if (status) goto fail; dev_dbg(&cdev->gadget->dev, "generic ttyGS%d: %s speed IN/%s OUT/%s\n", diff --git a/drivers/usb/gadget/function/f_sourcesink.c b/drivers/usb/gadget/function/f_sourcesink.c index ed68a4860b7d..282737e4609c 100644 --- a/drivers/usb/gadget/function/f_sourcesink.c +++ b/drivers/usb/gadget/function/f_sourcesink.c @@ -431,7 +431,8 @@ sourcesink_bind(struct usb_configuration *c, struct usb_function *f) ss_iso_sink_desc.bEndpointAddress = fs_iso_sink_desc.bEndpointAddress; ret = usb_assign_descriptors(f, fs_source_sink_descs, - hs_source_sink_descs, ss_source_sink_descs, NULL); + hs_source_sink_descs, ss_source_sink_descs, + ss_source_sink_descs); if (ret) return ret; diff --git a/drivers/usb/gadget/function/f_subset.c b/drivers/usb/gadget/function/f_subset.c index 4d945254905d..51c1cae162d9 100644 --- a/drivers/usb/gadget/function/f_subset.c +++ b/drivers/usb/gadget/function/f_subset.c @@ -358,7 +358,7 @@ geth_bind(struct usb_configuration *c, struct usb_function *f) fs_subset_out_desc.bEndpointAddress; status = usb_assign_descriptors(f, fs_eth_function, hs_eth_function, - ss_eth_function, NULL); + ss_eth_function, ss_eth_function); if (status) goto fail; diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c index 106988a6661a..bc714dc48152 100644 --- a/drivers/usb/gadget/function/f_tcm.c +++ b/drivers/usb/gadget/function/f_tcm.c @@ -2070,7 +2070,8 @@ static int tcm_bind(struct usb_configuration *c, struct usb_function *f) uasp_fs_cmd_desc.bEndpointAddress = uasp_ss_cmd_desc.bEndpointAddress; ret = usb_assign_descriptors(f, uasp_fs_function_desc, - uasp_hs_function_desc, uasp_ss_function_desc, NULL); + uasp_hs_function_desc, uasp_ss_function_desc, + uasp_ss_function_desc); if (ret) goto ep_fail; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-38582
by Yifan Qiao 02 Jul '24

02 Jul '24

Ryusuke Konishi (2): nilfs2: fix unexpected freezing of nilfs_segctor_sync() nilfs2: fix potential hang in nilfs_detach_log_writer() fs/nilfs2/segment.c | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-) -- 2.39.2

2 3

[PATCH OLK-6.6] drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails
by Xiongfeng Wang 02 Jul '24

02 Jul '24

From: Konrad Dybcio <konrad.dybcio(a)linaro.org> mainline inclusion from mainline-v6.10-rc1 commit 46d4efcccc688cbacdd70a238bedca510acaa8e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D2C CVE: CVE-2024-38390 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Fixes: 76efc2453d0e ("drm/msm/gpu: Fix crash during system suspend after unbind") Signed-off-by: Konrad Dybcio <konrad.dybcio(a)linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/588919/ Signed-off-by: Rob Clark <robdclark(a)chromium.org> Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 522ca7fe6762..3664c1476a83 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -2343,7 +2343,8 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev) ret = a6xx_set_supported_hw(&pdev->dev, config->info); if (ret) { - a6xx_destroy(&(a6xx_gpu->base.base)); + a6xx_llc_slices_destroy(a6xx_gpu); + kfree(a6xx_gpu); return ERR_PTR(ret); } -- 2.20.1

2 1

[PATCH OLK-6.6] ACPI: APEI: Skip initialization of GHES_ASSIST structures for Machine Check Architecture
by Xiongfeng Wang 02 Jul '24

02 Jul '24

From: Avadhut Naik <avadhut.naik(a)amd.com> mainline inclusion from mainline-v6.8-rc6 commit 8ec7071385508822892cabc2c0cb74333859407a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9JNPZ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- To support GHES_ASSIST on Machine Check Architecture (MCA) error sources, a set of GHES structures is provided by the system firmware for each MCA error source. Each of these sets consists of a GHES structure for each MCA bank on each logical CPU, with all structures of a set sharing a common Related Source ID, equal to the Source ID of one of the MCA error source structures.[1] On SOCs with large core counts, this typically equates to tens of thousands of GHES_ASSIST structures for MCA under "/sys/bus/platform/drivers/GHES". Support for GHES_ASSIST however, hasn't been implemented in the kernel. As such, the information provided through these structures is not consumed by Linux. Moreover, these GHES_ASSIST structures for MCA, which are supposed to provide supplemental information in context of an error reported by hardware, are setup as independent error sources by the kernel during HEST initialization. Additionally, if the Type field of the Notification structure, associated with these GHES_ASSIST structures for MCA, is set to Polled, the kernel sets up a timer for each individual structure. The duration of the timer is derived from the Poll Interval field of the Notification structure. On SOCs with high core counts, this will result in tens of thousands of timers expiring periodically causing unnecessary preemptions and wastage of CPU cycles. The problem will particularly intensify if Poll Interval duration is not sufficiently high. Since GHES_ASSIST support is not present in kernel, skip initialization of GHES_ASSIST structures for MCA to eliminate their performance impact. [1] ACPI specification 6.5, section 18.7 Signed-off-by: Avadhut Naik <avadhut.naik(a)amd.com> Reviewed-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Reviewed-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> --- drivers/acpi/apei/hest.c | 51 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c index 6aef1ee5e1bd..20d757687e3d 100644 --- a/drivers/acpi/apei/hest.c +++ b/drivers/acpi/apei/hest.c @@ -37,6 +37,20 @@ EXPORT_SYMBOL_GPL(hest_disable); static struct acpi_table_hest *__read_mostly hest_tab; +/* + * Since GHES_ASSIST is not supported, skip initialization of GHES_ASSIST + * structures for MCA. + * During HEST parsing, detected MCA error sources are cached from early + * table entries so that the Flags and Source Id fields from these cached + * values are then referred to in later table entries to determine if the + * encountered GHES_ASSIST structure should be initialized. + */ +static struct { + struct acpi_hest_ia_corrected *cmc; + struct acpi_hest_ia_machine_check *mc; + struct acpi_hest_ia_deferred_check *dmc; +} mces; + static const int hest_esrc_len_tab[ACPI_HEST_TYPE_RESERVED] = { [ACPI_HEST_TYPE_IA32_CHECK] = -1, /* need further calculation */ [ACPI_HEST_TYPE_IA32_CORRECTED_CHECK] = -1, @@ -70,22 +84,54 @@ static int hest_esrc_len(struct acpi_hest_header *hest_hdr) cmc = (struct acpi_hest_ia_corrected *)hest_hdr; len = sizeof(*cmc) + cmc->num_hardware_banks * sizeof(struct acpi_hest_ia_error_bank); + mces.cmc = cmc; } else if (hest_type == ACPI_HEST_TYPE_IA32_CHECK) { struct acpi_hest_ia_machine_check *mc; mc = (struct acpi_hest_ia_machine_check *)hest_hdr; len = sizeof(*mc) + mc->num_hardware_banks * sizeof(struct acpi_hest_ia_error_bank); + mces.mc = mc; } else if (hest_type == ACPI_HEST_TYPE_IA32_DEFERRED_CHECK) { struct acpi_hest_ia_deferred_check *mc; mc = (struct acpi_hest_ia_deferred_check *)hest_hdr; len = sizeof(*mc) + mc->num_hardware_banks * sizeof(struct acpi_hest_ia_error_bank); + mces.dmc = mc; } BUG_ON(len == -1); return len; }; +/* + * GHES and GHESv2 structures share the same format, starting from + * Source Id and ending in Error Status Block Length (inclusive). + */ +static bool is_ghes_assist_struct(struct acpi_hest_header *hest_hdr) +{ + struct acpi_hest_generic *ghes; + u16 related_source_id; + + if (hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR && + hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR_V2) + return false; + + ghes = (struct acpi_hest_generic *)hest_hdr; + related_source_id = ghes->related_source_id; + + if (mces.cmc && mces.cmc->flags & ACPI_HEST_GHES_ASSIST && + related_source_id == mces.cmc->header.source_id) + return true; + if (mces.mc && mces.mc->flags & ACPI_HEST_GHES_ASSIST && + related_source_id == mces.mc->header.source_id) + return true; + if (mces.dmc && mces.dmc->flags & ACPI_HEST_GHES_ASSIST && + related_source_id == mces.dmc->header.source_id) + return true; + + return false; +} + typedef int (*apei_hest_func_t)(struct acpi_hest_header *hest_hdr, void *data); static int apei_hest_parse(apei_hest_func_t func, void *data) @@ -114,6 +160,11 @@ static int apei_hest_parse(apei_hest_func_t func, void *data) return -EINVAL; } + if (is_ghes_assist_struct(hest_hdr)) { + hest_hdr = (void *)hest_hdr + len; + continue; + } + rc = func(hest_hdr, data); if (rc) return rc; -- 2.20.1

2 1

[PATCH openEuler-1.0-LTS] KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
by Zheng Zucheng 02 Jul '24

02 Jul '24

From: Nicholas Piggin <npiggin(a)gmail.com> stable inclusion from stable-v5.10.54 commit e14ef1095387f764d95614d3ec9e4d07c82a3533 bugzilla: 175586 https://gitee.com/openeuler/kernel/issues/I4DVDU CVE: CVE-2021-47296 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit bc4188a2f56e821ea057aca6bf444e138d06c252 ] vcpu_put is not called if the user copy fails. This can result in preempt notifier corruption and crashes, among other issues. Fixes: b3cebfe8c1ca ("KVM: PPC: Move vcpu_load/vcpu_put down to each ioctl case in kvm_arch_vcpu_ioctl") Reported-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/20210716024310.164448-2-npiggin@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Acked-by: Weilong Chen <chenweilong(a)huawei.com> Signed-off-by: Chen Jun <chenjun102(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- arch/powerpc/kvm/powerpc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index ee89f6fbea86..b9df096bfae9 100644 --- a/arch/powerpc/kvm/powerpc.c +++ b/arch/powerpc/kvm/powerpc.c @@ -1994,9 +1994,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp, { struct kvm_enable_cap cap; r = -EFAULT; - vcpu_load(vcpu); if (copy_from_user(&cap, argp, sizeof(cap))) goto out; + vcpu_load(vcpu); r = kvm_vcpu_ioctl_enable_cap(vcpu, &cap); vcpu_put(vcpu); break; @@ -2020,9 +2020,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp, case KVM_DIRTY_TLB: { struct kvm_dirty_tlb dirty; r = -EFAULT; - vcpu_load(vcpu); if (copy_from_user(&dirty, argp, sizeof(dirty))) goto out; + vcpu_load(vcpu); r = kvm_vcpu_ioctl_dirty_tlb(vcpu, &dirty); vcpu_put(vcpu); break; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] stm class: Fix a double free in stm_register_device()
by Wang Wensheng 02 Jul '24

02 Jul '24

From: Dan Carpenter <dan.carpenter(a)linaro.org> stable inclusion from stable-v4.19.316 commit 6cc30ef8eb6d8f8d6df43152264bbf8835d99931 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D3T CVE: CVE-2024-38627 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3df463865ba42b8f88a590326f4c9ea17a1ce459 ] The put_device(&stm->dev) call will trigger stm_device_release() which frees "stm" so the vfree(stm) on the next line is a double free. Fixes: 389b6699a2aa ("stm class: Fix stm device initialization order") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Reviewed-by: Amelie Delaunay <amelie.delaunay(a)foss.st.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Link: https://lore.kernel.org/r/20240429130119.1518073-2-alexander.shishkin@linux… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hwtracing/stm/core.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c index eeba421dc823..9bb85d20934a 100644 --- a/drivers/hwtracing/stm/core.c +++ b/drivers/hwtracing/stm/core.c @@ -701,8 +701,11 @@ int stm_register_device(struct device *parent, struct stm_data *stm_data, return -ENOMEM; stm->major = register_chrdev(0, stm_data->name, &stm_fops); - if (stm->major < 0) - goto err_free; + if (stm->major < 0) { + err = stm->major; + vfree(stm); + return err; + } device_initialize(&stm->dev); stm->dev.devt = MKDEV(stm->major, 0); @@ -746,10 +749,8 @@ int stm_register_device(struct device *parent, struct stm_data *stm_data, err_device: unregister_chrdev(stm->major, stm_data->name); - /* matches device_initialize() above */ + /* calls stm_device_release() */ put_device(&stm->dev); -err_free: - vfree(stm); return err; } -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] m68k: Fix spinlock race in kernel thread creation
by Wang Wensheng 02 Jul '24

02 Jul '24

From: Michael Schmitz <schmitzmic(a)gmail.com> stable inclusion from stable-v4.19.316 commit 2a8d1d95302c7d52c6ac8fa5cb4a6948ae0d3a14 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SFZ CVE: CVE-2024-38613 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit da89ce46f02470ef08f0f580755d14d547da59ed ] Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch. This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register. The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()). A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck. As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit. Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). Disable interrupts temporarily when switching the tasks' register sets in resume(). Note that a simple oriw 0x700,%sr after restoring sr is not enough here - this leaves enough of a race for the 'spinlock recursion' warning to still be observed. Tested on ARAnyM and qemu (Quadra 800 emulation). Fixes: 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") Reported-by: Guenter Roeck <linux(a)roeck-us.net> Closes: https://lore.kernel.org/all/07811b26-677c-4d05-aeb4-996cd880b789@roeck-us.n… Signed-off-by: Michael Schmitz <schmitzmic(a)gmail.com> Tested-by: Guenter Roeck <linux(a)roeck-us.net> Reviewed-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Link: https://lore.kernel.org/r/20240411033631.16335-1-schmitzmic@gmail.com Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/m68k/kernel/entry.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S index 97cd3ea5f10b..f834a403e4d5 100644 --- a/arch/m68k/kernel/entry.S +++ b/arch/m68k/kernel/entry.S @@ -422,7 +422,9 @@ resume: movec %a0,%dfc /* restore status register */ - movew %a1@(TASK_THREAD+THREAD_SR),%sr + movew %a1@(TASK_THREAD+THREAD_SR),%d0 + oriw #0x0700,%d0 + movew %d0,%sr rts -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] phonet: fix rtm_phonet_notify() skb allocation
by Wang Wensheng 02 Jul '24

02 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.314 commit ec1f71c05caeba0f814df77e0f511d8b4618623a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D3T CVE: CVE-2024-36946 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d8cac8568618dcb8a51af3db1103e8d4cc4aeea7 ] fill_route() stores three components in the skb: - struct rtmsg - RTA_DST (u8) - RTA_OIF (u32) Therefore, rtm_phonet_notify() should use NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(1) + nla_total_size(4) Fixes: f062f41d0657 ("Phonet: routing table Netlink interface") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Rémi Denis-Courmont <courmisch(a)gmail.com> Link: https://lore.kernel.org/r/20240502161700.1804476-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- net/phonet/pn_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c index 871eaf2cb85e..5e50f9ea7484 100644 --- a/net/phonet/pn_netlink.c +++ b/net/phonet/pn_netlink.c @@ -206,7 +206,7 @@ void rtm_phonet_notify(int event, struct net_device *dev, u8 dst) struct sk_buff *skb; int err = -ENOBUFS; - skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct ifaddrmsg)) + + skb = nlmsg_new(NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(1) + nla_total_size(4), GFP_KERNEL); if (skb == NULL) goto errout; -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS 0/1] fix uaf when proc_cpuset_show
by Chen Ridong 02 Jul '24

02 Jul '24

*** BLURB HERE *** Chen Ridong (1): cgroup: fix uaf when proc_cpuset_show kernel/cgroup/cpuset.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS 0/1] fix uaf when proc_cpuset_show
by Chen Ridong 02 Jul '24

02 Jul '24

*** BLURB HERE *** Chen Ridong (1): cgroup: fix uaf when proc_cpuset_show kernel/cgroup/cpuset.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) -- 2.34.1

2 2

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

02 Jul '24

Fixing CVE-2024-38597 Jakub Kicinski (1): eth: sungem: remove .ndo_poll_controller to avoid deadlocks Wei Fang (1): net: fec: remove .ndo_poll_controller to avoid deadlocks drivers/net/ethernet/freescale/fec_main.c | 26 ----------------------- drivers/net/ethernet/sun/sungem.c | 14 ------------ 2 files changed, 40 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS v2] net/nfc/rawsock.c: fix a permission check bug
by Wang Hai 02 Jul '24

02 Jul '24

From: Jeimon <jjjinmeng.zhou(a)gmail.com> stable inclusion from stable-v4.19.195 commit ec72482564ff99c6832d33610d9f8ab7ecc81b6d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4JW CVE: CVE-2021-47285 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8ab78863e9eff11910e1ac8bcf478060c29b379e ] The function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net->user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable(). Signed-off-by: Jeimon <jjjinmeng.zhou(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- v1->v2: change msg net/nfc/rawsock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/nfc/rawsock.c b/net/nfc/rawsock.c index b927730d9ab0..8f8bb0263827 100644 --- a/net/nfc/rawsock.c +++ b/net/nfc/rawsock.c @@ -345,7 +345,7 @@ static int rawsock_create(struct net *net, struct socket *sock, return -ESOCKTNOSUPPORT; if (sock->type == SOCK_RAW) { - if (!capable(CAP_NET_RAW)) + if (!ns_capable(net->user_ns, CAP_NET_RAW)) return -EPERM; sock->ops = &rawsock_raw_ops; } else { -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] net/nfc/rawsock.c: fix a permission check bug
by Wang Hai 02 Jul '24

02 Jul '24

From: Jeimon <jjjinmeng.zhou(a)gmail.com> stable inclusion from stable-v4.19.195 commit 1e5cab50208c8fb7351b798cb1d569debfeb994a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4JW CVE: CVE-2021-47285 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8ab78863e9eff11910e1ac8bcf478060c29b379e ] The function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net->user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable(). Signed-off-by: Jeimon <jjjinmeng.zhou(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- net/nfc/rawsock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/nfc/rawsock.c b/net/nfc/rawsock.c index b927730d9ab0..8f8bb0263827 100644 --- a/net/nfc/rawsock.c +++ b/net/nfc/rawsock.c @@ -345,7 +345,7 @@ static int rawsock_create(struct net *net, struct socket *sock, return -ESOCKTNOSUPPORT; if (sock->type == SOCK_RAW) { - if (!capable(CAP_NET_RAW)) + if (!ns_capable(net->user_ns, CAP_NET_RAW)) return -EPERM; sock->ops = &rawsock_raw_ops; } else { -- 2.17.1

2 1

[PATCH v2 openEuler-1.0-LTS 0/2] Fix CVE-2024-38567
by Li Huafei 02 Jul '24

02 Jul '24

Alan Stern (1): USB: core: Add routines for endpoint checks in old drivers Nikita Zhandarovich (1): wifi: carl9170: add a proper sanity check for endpoints drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++ drivers/usb/core/usb.c | 76 +++++++++++++++++++++++++ include/linux/usb.h | 5 ++ 3 files changed, 113 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-22.03-LTS-SP1] r8169: Fix possible ring buffer corruption on fragmented Tx packets.
by Liu Jian 02 Jul '24

02 Jul '24

From: Ken Milmore <ken.milmore(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit c71e3a5cffd5309d7f84444df03d5b72600cc417 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SF4 CVE: CVE-2024-38586 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied. Fixes: 9020845fb5d6 ("r8169: improve rtl8169_start_xmit") Cc: stable(a)vger.kernel.org Signed-off-by: Ken Milmore <ken.milmore(a)gmail.com> Reviewed-by: Heiner Kallweit <hkallweit1(a)gmail.com> Link: https://lore.kernel.org/r/27ead18b-c23d-4f49-a020-1fc482c5ac95@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: drivers/net/ethernet/realtek/r8169_main.c [We did not backport bd4bdeb4f2902.] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/realtek/r8169_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index d3fd77fa64ea..8eaae9081467 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -4276,11 +4276,11 @@ static void rtl8169_doorbell(struct rtl8169_private *tp) static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev) { - unsigned int frags = skb_shinfo(skb)->nr_frags; struct rtl8169_private *tp = netdev_priv(dev); unsigned int entry = tp->cur_tx % NUM_TX_DESC; struct TxDesc *txd_first, *txd_last; bool stop_queue, door_bell; + unsigned int frags; u32 opts[2]; txd_first = tp->TxDescArray + entry; @@ -4306,6 +4306,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb, entry, false))) goto err_dma_0; + frags = skb_shinfo(skb)->nr_frags; if (frags) { if (rtl8169_xmit_frags(tp, skb, opts, entry)) goto err_dma_1; -- 2.34.1

2 1

[PATCH OLK-6.6] r8169: Fix possible ring buffer corruption on fragmented Tx packets.
by Liu Jian 02 Jul '24

02 Jul '24

From: Ken Milmore <ken.milmore(a)gmail.com> stable inclusion from stable-v6.6.33 commit 68222d7b4b72aa321135cd453dac37f00ec41fd1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SF4 CVE: CVE-2024-38586 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit c71e3a5cffd5309d7f84444df03d5b72600cc417 upstream. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied. Fixes: 9020845fb5d6 ("r8169: improve rtl8169_start_xmit") Cc: stable(a)vger.kernel.org Signed-off-by: Ken Milmore <ken.milmore(a)gmail.com> Reviewed-by: Heiner Kallweit <hkallweit1(a)gmail.com> Link: https://lore.kernel.org/r/27ead18b-c23d-4f49-a020-1fc482c5ac95@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/realtek/r8169_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index e6f1da66c450..58e131c7b4e4 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -4246,11 +4246,11 @@ static void rtl8169_doorbell(struct rtl8169_private *tp) static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev) { - unsigned int frags = skb_shinfo(skb)->nr_frags; struct rtl8169_private *tp = netdev_priv(dev); unsigned int entry = tp->cur_tx % NUM_TX_DESC; struct TxDesc *txd_first, *txd_last; bool stop_queue, door_bell; + unsigned int frags; u32 opts[2]; if (unlikely(!rtl_tx_slots_avail(tp))) { @@ -4273,6 +4273,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb, txd_first = tp->TxDescArray + entry; + frags = skb_shinfo(skb)->nr_frags; if (frags) { if (rtl8169_xmit_frags(tp, skb, opts, entry)) goto err_dma_1; -- 2.34.1

2 1

[PATCH OLK-5.10] r8169: Fix possible ring buffer corruption on fragmented Tx packets.
by Liu Jian 02 Jul '24

02 Jul '24

From: Ken Milmore <ken.milmore(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit c71e3a5cffd5309d7f84444df03d5b72600cc417 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SF4 CVE: CVE-2024-38586 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied. Fixes: 9020845fb5d6 ("r8169: improve rtl8169_start_xmit") Cc: stable(a)vger.kernel.org Signed-off-by: Ken Milmore <ken.milmore(a)gmail.com> Reviewed-by: Heiner Kallweit <hkallweit1(a)gmail.com> Link: https://lore.kernel.org/r/27ead18b-c23d-4f49-a020-1fc482c5ac95@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: drivers/net/ethernet/realtek/r8169_main.c [We did not backport bd4bdeb4f2902.] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/realtek/r8169_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c index 5f42debd0de9..5cfe0d77ade2 100644 --- a/drivers/net/ethernet/realtek/r8169_main.c +++ b/drivers/net/ethernet/realtek/r8169_main.c @@ -4285,11 +4285,11 @@ static void rtl8169_doorbell(struct rtl8169_private *tp) static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev) { - unsigned int frags = skb_shinfo(skb)->nr_frags; struct rtl8169_private *tp = netdev_priv(dev); unsigned int entry = tp->cur_tx % NUM_TX_DESC; struct TxDesc *txd_first, *txd_last; bool stop_queue, door_bell; + unsigned int frags; u32 opts[2]; txd_first = tp->TxDescArray + entry; @@ -4315,6 +4315,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb, entry, false))) goto err_dma_0; + frags = skb_shinfo(skb)->nr_frags; if (frags) { if (rtl8169_xmit_frags(tp, skb, opts, entry)) goto err_dma_1; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] mac80211: track only QoS data frames for admission control
by Dong Chenchen 02 Jul '24

02 Jul '24

From: Johannes Berg <johannes.berg(a)intel.com> stable inclusion from stable-v4.19.222 commit 69f054d6642c8f6173724ce17e7ee3ff66b8f682 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH2 CVE: CVE-2021-47602 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d5e568c3a4ec2ddd23e7dc5ad5b0c64e4f22981a ] For admission control, obviously all of that only works for QoS data frames, otherwise we cannot even access the QoS field in the header. Syzbot reported (see below) an uninitialized value here due to a status of a non-QoS nullfunc packet, which isn't even long enough to contain the QoS header. Fix this to only do anything for QoS data packets. Reported-by: syzbot+614e82b88a1a4973e534(a)syzkaller.appspotmail.com Fixes: 02219b3abca5 ("mac80211: add WMM admission control support") Link: https://lore.kernel.org/r/20211122124737.dad29e65902a.Ieb04587afacb27c14e0d… Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/mlme.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index b0667467337d..373bdc1d035b 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -2346,11 +2346,18 @@ static void ieee80211_sta_tx_wmm_ac_notify(struct ieee80211_sub_if_data *sdata, u16 tx_time) { struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; - u16 tid = ieee80211_get_tid(hdr); - int ac = ieee80211_ac_from_tid(tid); - struct ieee80211_sta_tx_tspec *tx_tspec = &ifmgd->tx_tspec[ac]; + u16 tid; + int ac; + struct ieee80211_sta_tx_tspec *tx_tspec; unsigned long now = jiffies; + if (!ieee80211_is_data_qos(hdr->frame_control)) + return; + + tid = ieee80211_get_tid(hdr); + ac = ieee80211_ac_from_tid(tid); + tx_tspec = &ifmgd->tx_tspec[ac]; + if (likely(!tx_tspec->admitted_time)) return; -- 2.25.1

2 1

[PATCH v2 OLK-5.10] wifi: carl9170: add a proper sanity check for endpoints
by Li Huafei 02 Jul '24

02 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit 8650725bb0a48b206d5a8ddad3a7488f9a5985b7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5Z CVE: CVE-2024-38567 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0 ] Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1 Reported-and-tested-by: syzbot+0ae4804973be759fa420(a)syzkaller.appspotmail.com Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Acked-By: Christian Lamparter <chunkeey(a)gmail.com> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240422183355.3785-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c index e4eb666c6eea..a5265997b576 100644 --- a/drivers/net/wireless/ath/carl9170/usb.c +++ b/drivers/net/wireless/ath/carl9170/usb.c @@ -1069,6 +1069,38 @@ static int carl9170_usb_probe(struct usb_interface *intf, ar->usb_ep_cmd_is_bulk = true; } + /* Verify that all expected endpoints are present */ + if (ar->usb_ep_cmd_is_bulk) { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } else { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } + + if (err) { + carl9170_free(ar); + return err; + } + usb_set_intfdata(intf, ar); SET_IEEE80211_DEV(ar->hw, &intf->dev); -- 2.25.1

2 1

[PATCH v2 openEuler-22.03-LTS-SP1] wifi: carl9170: add a proper sanity check for endpoints
by Li Huafei 02 Jul '24

02 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit 8650725bb0a48b206d5a8ddad3a7488f9a5985b7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5Z CVE: CVE-2024-38567 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0 ] Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1 Reported-and-tested-by: syzbot+0ae4804973be759fa420(a)syzkaller.appspotmail.com Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Acked-By: Christian Lamparter <chunkeey(a)gmail.com> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240422183355.3785-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c index e4eb666c6eea..a5265997b576 100644 --- a/drivers/net/wireless/ath/carl9170/usb.c +++ b/drivers/net/wireless/ath/carl9170/usb.c @@ -1069,6 +1069,38 @@ static int carl9170_usb_probe(struct usb_interface *intf, ar->usb_ep_cmd_is_bulk = true; } + /* Verify that all expected endpoints are present */ + if (ar->usb_ep_cmd_is_bulk) { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } else { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } + + if (err) { + carl9170_free(ar); + return err; + } + usb_set_intfdata(intf, ar); SET_IEEE80211_DEV(ar->hw, &intf->dev); -- 2.25.1

2 1

[PATCH v2 OLK-6.6] wifi: carl9170: add a proper sanity check for endpoints
by Li Huafei 02 Jul '24

02 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v6.6.33 commit 62eb07923f3693d55b0c2d9a5a4f1ad72cb6b8fd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5Z CVE: CVE-2024-38567 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0 ] Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1 Reported-and-tested-by: syzbot+0ae4804973be759fa420(a)syzkaller.appspotmail.com Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Acked-By: Christian Lamparter <chunkeey(a)gmail.com> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240422183355.3785-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c index e4eb666c6eea..a5265997b576 100644 --- a/drivers/net/wireless/ath/carl9170/usb.c +++ b/drivers/net/wireless/ath/carl9170/usb.c @@ -1069,6 +1069,38 @@ static int carl9170_usb_probe(struct usb_interface *intf, ar->usb_ep_cmd_is_bulk = true; } + /* Verify that all expected endpoints are present */ + if (ar->usb_ep_cmd_is_bulk) { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } else { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } + + if (err) { + carl9170_free(ar); + return err; + } + usb_set_intfdata(intf, ar); SET_IEEE80211_DEV(ar->hw, &intf->dev); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] wifi: carl9170: add a proper sanity check for endpoints
by Li Huafei 02 Jul '24

02 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v4.19.316 commit eb0f2fc3ff5806cc572cd9055ce7c52a01e97645 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5Z CVE: CVE-2024-38567 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- stable inclusion from stable-v4.19.316 commit eb0f2fc3ff5806cc572cd9055ce7c52a01e97645 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5Z CVE: CVE-2024-3856 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0 ] Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1 Reported-and-tested-by: syzbot+0ae4804973be759fa420(a)syzkaller.appspotmail.com Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Acked-By: Christian Lamparter <chunkeey(a)gmail.com> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240422183355.3785-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c index 99f1897a775d..738f43b17e95 100644 --- a/drivers/net/wireless/ath/carl9170/usb.c +++ b/drivers/net/wireless/ath/carl9170/usb.c @@ -1069,6 +1069,38 @@ static int carl9170_usb_probe(struct usb_interface *intf, ar->usb_ep_cmd_is_bulk = true; } + /* Verify that all expected endpoints are present */ + if (ar->usb_ep_cmd_is_bulk) { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } else { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } + + if (err) { + carl9170_free(ar); + return err; + } + usb_set_intfdata(intf, ar); SET_IEEE80211_DEV(ar->hw, &intf->dev); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] wifi: carl9170: add a proper sanity check for endpoints
by Li Huafei 02 Jul '24

02 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit 8650725bb0a48b206d5a8ddad3a7488f9a5985b7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5Z CVE: CVE-2024-3856 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0 ] Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1 Reported-and-tested-by: syzbot+0ae4804973be759fa420(a)syzkaller.appspotmail.com Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Acked-By: Christian Lamparter <chunkeey(a)gmail.com> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240422183355.3785-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c index e4eb666c6eea..a5265997b576 100644 --- a/drivers/net/wireless/ath/carl9170/usb.c +++ b/drivers/net/wireless/ath/carl9170/usb.c @@ -1069,6 +1069,38 @@ static int carl9170_usb_probe(struct usb_interface *intf, ar->usb_ep_cmd_is_bulk = true; } + /* Verify that all expected endpoints are present */ + if (ar->usb_ep_cmd_is_bulk) { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } else { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } + + if (err) { + carl9170_free(ar); + return err; + } + usb_set_intfdata(intf, ar); SET_IEEE80211_DEV(ar->hw, &intf->dev); -- 2.25.1

2 1

[PATCH OLK-5.10] wifi: carl9170: add a proper sanity check for endpoints
by Li Huafei 02 Jul '24

02 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v5.10.219 commit 8650725bb0a48b206d5a8ddad3a7488f9a5985b7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5Z CVE: CVE-2024-3856 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0 ] Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1 Reported-and-tested-by: syzbot+0ae4804973be759fa420(a)syzkaller.appspotmail.com Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Acked-By: Christian Lamparter <chunkeey(a)gmail.com> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240422183355.3785-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- drivers/net/wireless/ath/carl9170/usb.c | 32 +++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c index e4eb666c6eea..a5265997b576 100644 --- a/drivers/net/wireless/ath/carl9170/usb.c +++ b/drivers/net/wireless/ath/carl9170/usb.c @@ -1069,6 +1069,38 @@ static int carl9170_usb_probe(struct usb_interface *intf, ar->usb_ep_cmd_is_bulk = true; } + /* Verify that all expected endpoints are present */ + if (ar->usb_ep_cmd_is_bulk) { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } else { + u8 bulk_ep_addr[] = { + AR9170_USB_EP_RX | USB_DIR_IN, + AR9170_USB_EP_TX | USB_DIR_OUT, + 0}; + u8 int_ep_addr[] = { + AR9170_USB_EP_IRQ | USB_DIR_IN, + AR9170_USB_EP_CMD | USB_DIR_OUT, + 0}; + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) + err = -ENODEV; + } + + if (err) { + carl9170_free(ar); + return err; + } + usb_set_intfdata(intf, ar); SET_IEEE80211_DEV(ar->hw, &intf->dev); -- 2.25.1

2 1