- Kernel - mailweb.openeuler.org

[PATCH openEuler-5.10-LTS 00/10] Backport 5.10.117 LTS
by Zheng Zengkai 09 Aug '22

09 Aug '22

d1ac096f8869 mm: userfaultfd: fix missing cache flush in mcopy_atomic_pte() and _mcopy_atomic() c6cbf5431a62 mm: hugetlb: fix missing cache flush in copy_huge_page_from_user() 308ff6a6e768 mm: fix missing cache flush for all tail pages of compound page 185fa5984d7a Bluetooth: Fix the creation of hdev->name 9ff4a6b80642 arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL dfb55dcf9d39 nfp: bpf: silence bitwise vs. logical OR warning f89f76f4b0e7 drm/amd/display/dc/gpio/gpio_service: Pass around correct dce{version, environment} types efd1429fa99b block: drbd: drbd_nl: Make conversion to 'enum drbd_ret_code' explicit a71658c7db0b regulator: consumer: Add missing stubs to regulator/consumer.h 7648f42d1a62 MIPS: Use address-of operator on section symbols Total patches: 10 Dmitry Osipenko (1): regulator: consumer: Add missing stubs to regulator/consumer.h Itay Iellin (1): Bluetooth: Fix the creation of hdev->name Lee Jones (2): block: drbd: drbd_nl: Make conversion to 'enum drbd_ret_code' explicit drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types Mike Rapoport (1): arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL Muchun Song (3): mm: fix missing cache flush for all tail pages of compound page mm: hugetlb: fix missing cache flush in copy_huge_page_from_user() mm: userfaultfd: fix missing cache flush in mcopy_atomic_pte() and __mcopy_atomic() Nathan Chancellor (2): MIPS: Use address-of operator on section symbols nfp: bpf: silence bitwise vs. logical OR warning Documentation/vm/memory-model.rst | 3 +- arch/arm/Kconfig | 8 ++--- arch/arm/mach-bcm/Kconfig | 1 - arch/arm/mach-davinci/Kconfig | 1 - arch/arm/mach-exynos/Kconfig | 1 - arch/arm/mach-highbank/Kconfig | 1 - arch/arm/mach-omap2/Kconfig | 1 - arch/arm/mach-s5pv210/Kconfig | 1 - arch/arm/mach-tango/Kconfig | 1 - arch/mips/bmips/setup.c | 2 +- arch/mips/lantiq/prom.c | 2 +- arch/mips/pic32/pic32mzda/init.c | 2 +- arch/mips/ralink/of.c | 2 +- drivers/block/drbd/drbd_nl.c | 13 +++++--- .../drm/amd/display/dc/gpio/gpio_service.c | 12 +++---- .../display/include/gpio_service_interface.h | 4 +-- drivers/net/ethernet/netronome/nfp/nfp_asm.c | 4 +-- fs/proc/kcore.c | 2 -- include/linux/mmzone.h | 31 ------------------- include/linux/regulator/consumer.h | 30 ++++++++++++++++++ include/net/bluetooth/hci_core.h | 3 ++ mm/memory.c | 2 ++ mm/migrate.c | 7 +++-- mm/mmzone.c | 14 --------- mm/userfaultfd.c | 3 ++ mm/vmstat.c | 4 --- net/bluetooth/hci_core.c | 6 ++-- 27 files changed, 71 insertions(+), 90 deletions(-) -- 2.20.1

1 10

[PATCH openEuler-5.10-LTS 1/6] coresight: etm4x: Workaround CPU hung bug on HiSilicon ETM
by Zheng Zengkai 09 Aug '22

09 Aug '22

From: Junhao He <hejunhao3(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5EZY2 ------------------------------------------------------------------ In FIFO mode, when the state of sink buffer is full, the sink device will continuously backpressures the ETM, so that the ETM cannot switch to the idle state. In this case, the WFx instruction cannot be executed because the CPU detects that the ETM is not in the idle state which that will cause CPU hung. We workaround this issue on HiSilicon ETM by setting bit 13 of TRCAUXCTLR which is used to indicate that the ETM is in the idle state. The call trace is shown below: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 10-...0: (1 ticks this GP) idle=5b6/1/0x4000000000000000 softirq=12309/12318 fqs=114196 (detected by 67, t=330041 jiffies, g=309253, q=453663) Task dump for CPU 10: task:ksoftirqd/10 state:R running task stack: 0 pid: 64 ppid: 2 flags:0x0000000a Call trace: __switch_to+0xbc/0xfc irqtime_account_irq+0x58/0xc4 __do_softirq+0x6c/0x358 run_ksoftirqd+0x68/0x90 smpboot_thread_fn+0x15c/0x1a0 kthread+0x108/0x13c ret_from_fork+0x10/0x18 watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [bash:133345] ... Call trace: smp_call_function_single+0x178/0x190 etm4_disable_sysfs+0x74/0xfc [coresight_etm4x] etm4_disable+0x6c/0x70 [coresight_etm4x] coresight_disable_source+0x7c/0xa0 [coresight] coresight_disable+0x6c/0x13c [coresight] enable_source_store+0x88/0xa0 [coresight] dev_attr_store+0x20/0x34 sysfs_kf_write+0x4c/0x5c kernfs_fop_write_iter+0x130/0x1c0 new_sync_write+0xec/0x18c vfs_write+0x214/0x2ac ksys_write+0x70/0xfc __arm64_sys_write+0x24/0x30 el0_svc_common.constprop.0+0x7c/0x1bc do_el0_svc+0x2c/0x94 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 Signed-off-by: Qi Liu <liuqi115(a)huawei.com> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> Reviewed-by: Jay Fang <f.fangjian(a)huawei.com> Acked-by: Xie XiuQi <xiexiuqi(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- .../coresight/coresight-etm4x-core.c | 37 +++++++++++++++---- drivers/hwtracing/coresight/coresight-etm4x.h | 1 + 2 files changed, 30 insertions(+), 8 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index d4d9c8bb88ca..881da29cbd5a 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -116,8 +116,10 @@ struct etm4_enable_arg { #define HISI_HIP08_CORE_COMMIT_LVL_1 0b01 #define HISI_HIP08_CORE_COMMIT_REG sys_reg(3, 1, 15, 2, 5) +#define HISI_HIP08_AUXCTRL_CHICKEN_BIT BIT(13) + struct etm4_arch_features { - void (*arch_callback)(bool enable); + void (*arch_callback)(void *info); }; static bool etm4_hisi_match_pid(unsigned int id) @@ -125,8 +127,9 @@ static bool etm4_hisi_match_pid(unsigned int id) return (id & ETM4_AMBA_MASK) == HISI_HIP08_AMBA_ID; } -static void etm4_hisi_config_core_commit(bool enable) +static void etm4_hisi_config_core_commit(void *info) { + bool enable = *(bool *)info; u8 commit = enable ? HISI_HIP08_CORE_COMMIT_LVL_1 : HISI_HIP08_CORE_COMMIT_FULL; u64 val; @@ -143,48 +146,67 @@ static void etm4_hisi_config_core_commit(bool enable) write_sysreg_s(val, HISI_HIP08_CORE_COMMIT_REG); } +static void etm4_hisi_config_auxctrlr(void *info) +{ + struct etmv4_drvdata *drvdata = info; + + /* Switch the ETM to idle state */ + writel_relaxed(HISI_HIP08_AUXCTRL_CHICKEN_BIT, drvdata->base + TRCAUXCTLR); +} + static struct etm4_arch_features etm4_features[] = { [ETM4_IMPDEF_HISI_CORE_COMMIT] = { .arch_callback = etm4_hisi_config_core_commit, }, + [ETM4_IMPDEF_HISI_SET_AUXCTRLR] = { + .arch_callback = etm4_hisi_config_auxctrlr, + }, {}, }; static void etm4_enable_arch_specific(struct etmv4_drvdata *drvdata) { struct etm4_arch_features *ftr; + bool enable = true; int bit; for_each_set_bit(bit, drvdata->arch_features, ETM4_IMPDEF_FEATURE_MAX) { ftr = &etm4_features[bit]; - if (ftr->arch_callback) - ftr->arch_callback(true); + if (bit == ETM4_IMPDEF_HISI_CORE_COMMIT && ftr->arch_callback) + ftr->arch_callback(&enable); + + if (bit == ETM4_IMPDEF_HISI_SET_AUXCTRLR && ftr->arch_callback) + ftr->arch_callback(drvdata); } } static void etm4_disable_arch_specific(struct etmv4_drvdata *drvdata) { struct etm4_arch_features *ftr; + bool enable = false; int bit; for_each_set_bit(bit, drvdata->arch_features, ETM4_IMPDEF_FEATURE_MAX) { ftr = &etm4_features[bit]; - if (ftr->arch_callback) - ftr->arch_callback(false); + if (bit == ETM4_IMPDEF_HISI_CORE_COMMIT && ftr->arch_callback) + ftr->arch_callback(&enable); } } static void etm4_check_arch_features(struct etmv4_drvdata *drvdata, unsigned int id) { - if (etm4_hisi_match_pid(id)) + if (etm4_hisi_match_pid(id)) { set_bit(ETM4_IMPDEF_HISI_CORE_COMMIT, drvdata->arch_features); + set_bit(ETM4_IMPDEF_HISI_SET_AUXCTRLR, drvdata->arch_features); + } } #else static void etm4_enable_arch_specific(struct etmv4_drvdata *drvdata) { + writel_relaxed(0x0, drvdata->base + TRCAUXCTLR); } static void etm4_disable_arch_specific(struct etmv4_drvdata *drvdata) @@ -223,7 +245,6 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) writel_relaxed(config->pe_sel, drvdata->base + TRCPROCSELR); writel_relaxed(config->cfg, drvdata->base + TRCCONFIGR); /* nothing specific implemented */ - writel_relaxed(0x0, drvdata->base + TRCAUXCTLR); writel_relaxed(config->eventctrl0, drvdata->base + TRCEVENTCTL0R); writel_relaxed(config->eventctrl1, drvdata->base + TRCEVENTCTL1R); if (drvdata->stallctl) diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h index 3dd3e0633328..ef9d7365c2da 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x.h +++ b/drivers/hwtracing/coresight/coresight-etm4x.h @@ -206,6 +206,7 @@ enum etm_impdef_type { ETM4_IMPDEF_HISI_CORE_COMMIT, + ETM4_IMPDEF_HISI_SET_AUXCTRLR, ETM4_IMPDEF_FEATURE_MAX, }; -- 2.20.1

1 5

[PATCH openEuler-1.0-LTS 1/7] x86/unwind/orc: Change REG_SP_INDIRECT
by Yongqiang Liu 09 Aug '22

09 Aug '22

From: Peter Zijlstra <peterz(a)infradead.org> mainline inclusion from mainline-v5.12-rc1 commit 87ccc826bf1c9e5ab4c2f649b404e02c63e47622 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5LCHG CVE: NA -------------------------------- Currently REG_SP_INDIRECT is unused but means (%rsp + offset), change it to mean (%rsp) + offset. The reason is that we're going to swizzle stack in the middle of a C function with non-trivial stack footprint. This means that when the unwinder finds the ToS, it needs to dereference it (%rsp) and then add the offset to the next frame, resulting in: (%rsp) + offset This is somewhat unfortunate, since REG_BP_INDIRECT is used (by DRAP) and thus needs to retain the current (%rbp + offset). Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Miroslav Benes <mbenes(a)suse.cz> Acked-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Reviewed-by: Zhang Jianhua <chris.zjh(a)huawei.com> Reviewed-by: Liao Chang <liaochang1(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- arch/x86/kernel/unwind_orc.c | 5 ++++- tools/objtool/orc_dump.c | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c index bafe953f5d7f..eea8ec5eca3b 100644 --- a/arch/x86/kernel/unwind_orc.c +++ b/arch/x86/kernel/unwind_orc.c @@ -450,7 +450,7 @@ bool unwind_next_frame(struct unwind_state *state) break; case ORC_REG_SP_INDIRECT: - sp = state->sp + orc->sp_offset; + sp = state->sp; indirect = true; break; @@ -500,6 +500,9 @@ bool unwind_next_frame(struct unwind_state *state) if (indirect) { if (!deref_stack_reg(state, sp, &sp)) goto err; + + if (orc->sp_reg == ORC_REG_SP_INDIRECT) + sp += orc->sp_offset; } /* Find IP, SP and possibly regs: */ diff --git a/tools/objtool/orc_dump.c b/tools/objtool/orc_dump.c index faa444270ee3..ba28830aace2 100644 --- a/tools/objtool/orc_dump.c +++ b/tools/objtool/orc_dump.c @@ -64,7 +64,7 @@ static void print_reg(unsigned int reg, int offset) if (reg == ORC_REG_BP_INDIRECT) printf("(bp%+d)", offset); else if (reg == ORC_REG_SP_INDIRECT) - printf("(sp%+d)", offset); + printf("(sp)%+d", offset); else if (reg == ORC_REG_UNDEFINED) printf("(und)"); else -- 2.25.1

1 6

[PATCH openEuler-1.0-LTS] netfilter: nf_queue: do not allow packet truncation below transport header offset
by Yongqiang Liu 09 Aug '22

09 Aug '22

From: Florian Westphal <fw(a)strlen.de> mainline inclusion from mainline-v5.19-rc3 commit 99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5J9R4 CVE: CVE-2022-36946 -------------------------------- Domingo Dirutigliano and Nicola Guerrera report kernel panic when sending nf_queue verdict with 1-byte nfta_payload attribute. The IP/IPv6 stack pulls the IP(v6) header from the packet after the input hook. If user truncates the packet below the header size, this skb_pull() will result in a malformed skb (skb->len < 0). Fixes: 7af4cc3fa158 ("[NETFILTER]: Add "nfnetlink_queue" netfilter queue handler over nfnetlink") Reported-by: Domingo Dirutigliano <pwnzer0tt1(a)proton.me> Signed-off-by: Florian Westphal <fw(a)strlen.de> Reviewed-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- net/netfilter/nfnetlink_queue.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c index a5aff2834bd6..cd496b074a71 100644 --- a/net/netfilter/nfnetlink_queue.c +++ b/net/netfilter/nfnetlink_queue.c @@ -850,11 +850,16 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum) } static int -nfqnl_mangle(void *data, int data_len, struct nf_queue_entry *e, int diff) +nfqnl_mangle(void *data, unsigned int data_len, struct nf_queue_entry *e, int diff) { struct sk_buff *nskb; if (diff < 0) { + unsigned int min_len = skb_transport_offset(e->skb); + + if (data_len < min_len) + return -EINVAL; + if (pskb_trim(e->skb, data_len)) return -ENOMEM; } else if (diff > 0) { -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] openvswitch: fix OOB access in reserve_sfa_size()
by Yongqiang Liu 08 Aug '22

08 Aug '22

From: Paolo Valerio <pvalerio(a)redhat.com> stable inclusion from stable-v4.19.240 commit bbbf059337f9a74285c1cf088ff85ee92d149e64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5KKF2 CVE: CVE-2022-2639 ------------------------------------------------- commit cefa91b2332d7009bc0be5d951d6cbbf349f90f8 upstream. Given a sufficiently large number of actions, while copying and reserving memory for a new action of a new flow, if next_offset is greater than MAX_ACTIONS_BUFSIZE, the function reserve_sfa_size() does not return -EMSGSIZE as expected, but it allocates MAX_ACTIONS_BUFSIZE bytes increasing actions_len by req_size. This can then lead to an OOB write access, especially when further actions need to be copied. Fix it by rearranging the flow action size check. KASAN splat below: ================================================================== BUG: KASAN: slab-out-of-bounds in reserve_sfa_size+0x1ba/0x380 [openvswitch] Write of size 65360 at addr ffff888147e4001c by task handler15/836 CPU: 1 PID: 836 Comm: handler15 Not tainted 5.18.0-rc1+ #27 ... Call Trace: <TASK> dump_stack_lvl+0x45/0x5a print_report.cold+0x5e/0x5db ? __lock_text_start+0x8/0x8 ? reserve_sfa_size+0x1ba/0x380 [openvswitch] kasan_report+0xb5/0x130 ? reserve_sfa_size+0x1ba/0x380 [openvswitch] kasan_check_range+0xf5/0x1d0 memcpy+0x39/0x60 reserve_sfa_size+0x1ba/0x380 [openvswitch] __add_action+0x24/0x120 [openvswitch] ovs_nla_add_action+0xe/0x20 [openvswitch] ovs_ct_copy_action+0x29d/0x1130 [openvswitch] ? __kernel_text_address+0xe/0x30 ? unwind_get_return_address+0x56/0xa0 ? create_prof_cpu_mask+0x20/0x20 ? ovs_ct_verify+0xf0/0xf0 [openvswitch] ? prep_compound_page+0x198/0x2a0 ? __kasan_check_byte+0x10/0x40 ? kasan_unpoison+0x40/0x70 ? ksize+0x44/0x60 ? reserve_sfa_size+0x75/0x380 [openvswitch] __ovs_nla_copy_actions+0xc26/0x2070 [openvswitch] ? __zone_watermark_ok+0x420/0x420 ? validate_set.constprop.0+0xc90/0xc90 [openvswitch] ? __alloc_pages+0x1a9/0x3e0 ? __alloc_pages_slowpath.constprop.0+0x1da0/0x1da0 ? unwind_next_frame+0x991/0x1e40 ? __mod_node_page_state+0x99/0x120 ? __mod_lruvec_page_state+0x2e3/0x470 ? __kasan_kmalloc_large+0x90/0xe0 ovs_nla_copy_actions+0x1b4/0x2c0 [openvswitch] ovs_flow_cmd_new+0x3cd/0xb10 [openvswitch] ... Cc: stable(a)vger.kernel.org Fixes: f28cd2af22a0 ("openvswitch: fix flow actions reallocation") Signed-off-by: Paolo Valerio <pvalerio(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Wei <luwei32(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- net/openvswitch/flow_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c index eab5e8eaddaa..217c64fbc659 100644 --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -2316,7 +2316,7 @@ static struct nlattr *reserve_sfa_size(struct sw_flow_actions **sfa, new_acts_size = max(next_offset + req_size, ksize(*sfa) * 2); if (new_acts_size > MAX_ACTIONS_BUFSIZE) { - if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) { + if ((next_offset + req_size) > MAX_ACTIONS_BUFSIZE) { OVS_NLERR(log, "Flow action size exceeds max %u", MAX_ACTIONS_BUFSIZE); return ERR_PTR(-EMSGSIZE); -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] dm thin: use refcount_t for thin_c reference counting
by Yongqiang Liu 08 Aug '22

08 Aug '22

From: John Pittman <jpittman(a)redhat.com> mainline inclusion from mainline-v4.20-rc1 commit 22d4c291f58752d14efb8a185b772a3fc3e947d2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5KSEX CVE: NA -------------------------------- The API surrounding refcount_t should be used in place of atomic_t when variables are being used as reference counters. It can potentially prevent reference counter overflows and use-after-free conditions. In the dm thin layer, one such example is tc->refcount. Change this from the atomic_t API to the refcount_t API to prevent mentioned conditions. Signed-off-by: John Pittman <jpittman(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> Signed-off-by: Luo Meng <luomeng12(a)huawei.com> Reviewed-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- drivers/md/dm-thin.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c index 2b6dd7a275eb..e352aa3fdfb0 100644 --- a/drivers/md/dm-thin.c +++ b/drivers/md/dm-thin.c @@ -355,7 +355,7 @@ struct thin_c { * Ensures the thin is not destroyed until the worker has finished * iterating the active_thins list. */ - atomic_t refcount; + refcount_t refcount; struct completion can_destroy; }; @@ -4100,12 +4100,12 @@ static struct target_type pool_target = { *--------------------------------------------------------------*/ static void thin_get(struct thin_c *tc) { - atomic_inc(&tc->refcount); + refcount_inc(&tc->refcount); } static void thin_put(struct thin_c *tc) { - if (atomic_dec_and_test(&tc->refcount)) + if (refcount_dec_and_test(&tc->refcount)) complete(&tc->can_destroy); } @@ -4255,7 +4255,7 @@ static int thin_ctr(struct dm_target *ti, unsigned argc, char **argv) r = -EINVAL; goto bad; } - atomic_set(&tc->refcount, 1); + refcount_set(&tc->refcount, 1); init_completion(&tc->can_destroy); list_add_tail_rcu(&tc->list, &tc->pool->active_thins); spin_unlock_irqrestore(&tc->pool->lock, flags); -- 2.25.1

1 0

Kernel SIG 申报议题：英特尔Sapphire Rapids平台PMU新特性
by Jason Zeng 08 Aug '22

08 Aug '22

议题：英特尔Sapphire Rapids平台PMU新特性简介：主要介绍一下英特尔的新一代Sapphire Rapids平台上的PMU新特性，以及Linux的支持情况。

1 0

[PATCH openEuler-1.0-LTS 01/29] ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()
by Yongqiang Liu 08 Aug '22

08 Aug '22

From: Sergey Shtylyov <s.shtylyov(a)omp.ru> stable inclusion from stable-4.19.249 commit a810bd5af06977a847d1f202b22d7defd5c62497 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP CVE: NA -------------------------------- [ Upstream commit bf476fe22aa1851bab4728e0c49025a6a0bea307 ] In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Signed-off-by: Sergey Shtylyov <s.shtylyov(a)omp.ru> Signed-off-by: Damien Le Moal <damien.lemoal(a)opensource.wdc.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- drivers/ata/libata-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 290ff99bf1d8..0bcdc5261480 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -6240,7 +6240,7 @@ struct ata_host *ata_host_alloc_pinfo(struct device *dev, const struct ata_port_info * const * ppi, int n_ports) { - const struct ata_port_info *pi; + const struct ata_port_info *pi = &ata_dummy_port_info; struct ata_host *host; int i, j; @@ -6248,7 +6248,7 @@ struct ata_host *ata_host_alloc_pinfo(struct device *dev, if (!host) return NULL; - for (i = 0, j = 0, pi = NULL; i < host->n_ports; i++) { + for (i = 0, j = 0; i < host->n_ports; i++) { struct ata_port *ap = host->ports[i]; if (ppi[j]) -- 2.25.1

1 28

[PATCH openEuler-1.0-LTS] ipv6/addrconf: fix a null-ptr-deref bug for ip6_ptr
by Yongqiang Liu 05 Aug '22

05 Aug '22

From: Ziyang Xuan <william.xuanziyang(a)huawei.com> mainline inclusion from mainline-v5.19 commit 85f0173df35e5462d89947135a6a5599c6c3ef6f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5JW9C CVE: NA ------------------------------- Change net device's MTU to smaller than IPV6_MIN_MTU or unregister device while matching route. That may trigger null-ptr-deref bug for ip6_ptr probability as following. ========================================================= BUG: KASAN: null-ptr-deref in find_match.part.0+0x70/0x134 Read of size 4 at addr 0000000000000308 by task ping6/263 CPU: 2 PID: 263 Comm: ping6 Not tainted 5.19.0-rc7+ #14 Call trace: dump_backtrace+0x1a8/0x230 show_stack+0x20/0x70 dump_stack_lvl+0x68/0x84 print_report+0xc4/0x120 kasan_report+0x84/0x120 __asan_load4+0x94/0xd0 find_match.part.0+0x70/0x134 __find_rr_leaf+0x408/0x470 fib6_table_lookup+0x264/0x540 ip6_pol_route+0xf4/0x260 ip6_pol_route_output+0x58/0x70 fib6_rule_lookup+0x1a8/0x330 ip6_route_output_flags_noref+0xd8/0x1a0 ip6_route_output_flags+0x58/0x160 ip6_dst_lookup_tail+0x5b4/0x85c ip6_dst_lookup_flow+0x98/0x120 rawv6_sendmsg+0x49c/0xc70 inet_sendmsg+0x68/0x94 Reproducer as following: Firstly, prepare conditions: $ip netns add ns1 $ip netns add ns2 $ip link add veth1 type veth peer name veth2 $ip link set veth1 netns ns1 $ip link set veth2 netns ns2 $ip netns exec ns1 ip -6 addr add 2001:0db8:0:f101::1/64 dev veth1 $ip netns exec ns2 ip -6 addr add 2001:0db8:0:f101::2/64 dev veth2 $ip netns exec ns1 ifconfig veth1 up $ip netns exec ns2 ifconfig veth2 up $ip netns exec ns1 ip -6 route add 2000::/64 dev veth1 metric 1 $ip netns exec ns2 ip -6 route add 2001::/64 dev veth2 metric 1 Secondly, execute the following two commands in two ssh windows respectively: $ip netns exec ns1 sh $while true; do ip -6 addr add 2001:0db8:0:f101::1/64 dev veth1; ip -6 route add 2000::/64 dev veth1 metric 1; ping6 2000::2; done $ip netns exec ns1 sh $while true; do ip link set veth1 mtu 1000; ip link set veth1 mtu 1500; sleep 5; done It is because ip6_ptr has been assigned to NULL in addrconf_ifdown() firstly, then ip6_ignore_linkdown() accesses ip6_ptr directly without NULL check. cpu0 cpu1 fib6_table_lookup __find_rr_leaf addrconf_notify [ NETDEV_CHANGEMTU ] addrconf_ifdown RCU_INIT_POINTER(dev->ip6_ptr, NULL) find_match ip6_ignore_linkdown So we can add NULL check for ip6_ptr before using in ip6_ignore_linkdown() to fix the null-ptr-deref bug. Fixes: dcd1f572954f ("net/ipv6: Remove fib6_idev") Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20220728013307.656257-1-william.xuanziyang@huawei… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: include/net/addrconf.h net/ipv6/route.c Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- net/ipv6/route.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 8efb03cc6f24..31c285d0f8c3 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -655,6 +655,9 @@ static inline bool fib6_ignore_linkdown(const struct fib6_info *f6i) if (dev) { const struct inet6_dev *idev = __in6_dev_get(dev); + if (unlikely(!idev)) + return true; + rc = !!idev->cnf.ignore_routes_with_linkdown; } -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] io_uring: add missing item types for various requests
by Yongqiang Liu 05 Aug '22

05 Aug '22

From: Jens Axboe <axboe(a)kernel.dk> stable inclusion from stable-v5.10.125 commit df3f3bb5059d20ef094d6b2f0256c4bf4127a859 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5IM3T CVE: CVE-2022-2327 -------------------------------- Any read/write should grab current->nsproxy, denoted by IO_WQ_WORK_FILES as it refers to current->files as well, and connect and recv/recvmsg, send/sendmsg should grab current->fs which is denoted by IO_WQ_WORK_FS. No upstream commit exists for this issue. Reported-by: Bing-Jhong Billy Jheng <billy(a)starlabs.sg> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: 1. read/write already grab current->nsproxy, thus don't modified read/write related ops. 2. 'work_flags' doesn't exist, io_op_def is using field 'needs_fs' to decide if 'current->fs' should be grabbed. Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- fs/io_uring.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/io_uring.c b/fs/io_uring.c index 8a96b7df4112..d4e430b51098 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -816,6 +816,7 @@ static const struct io_op_def io_op_defs[] = { .async_ctx = 1, .needs_mm = 1, .needs_file = 1, + .needs_fs = 1, .unbound_nonreg_file = 1, .pollout = 1, }, @@ -864,12 +865,14 @@ static const struct io_op_def io_op_defs[] = { [IORING_OP_SEND] = { .needs_mm = 1, .needs_file = 1, + .needs_fs = 1, .unbound_nonreg_file = 1, .pollout = 1, }, [IORING_OP_RECV] = { .needs_mm = 1, .needs_file = 1, + .needs_fs = 1, .unbound_nonreg_file = 1, .pollin = 1, .buffer_select = 1, -- 2.25.1

1 0