- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 v2] KVM: nVMX: Inject #GP, not #UD, if "generic" VMXON CR0/CR4 check fails
by 任敏敏(联通集团联通数字科技有限公司本部) 23 Apr '23

23 Apr '23

From: Sean Christopherson <seanjc(a)google.com> stable inclusion from stable-v5.10.163 commit 43dd254853aa274d356bb1d3ab01a8ca880b07b0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6XQ34 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 upstream Inject #GP for if VMXON is attempting with a CR0/CR4 that fails the generic "is CRx valid" check, but passes the CR4.VMXE check, and do the generic checks _after_ handling the post-VMXON VM-Fail. The CR4.VMXE check, and all other #UD cases, are special pre-conditions that are enforced prior to pivoting on the current VMX mode, i.e. occur before interception if VMXON is attempted in VMX non-root mode. All other CR0/CR4 checks generate #GP and effectively have lower priority than the post-VMXON check. Per the SDM: IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ... THEN #UD; ELSIF not in VMX operation THEN IF (CPL > 0) or (in A20M mode) or (the values of CR0 and CR4 are not supported in VMX operation) THEN #GP(0); ELSIF in VMX non-root operation THEN VMexit; ELSIF CPL > 0 THEN #GP(0); ELSE VMfail("VMXON executed in VMX root operation"); FI; which, if re-written without ELSIF, yields: IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ... THEN #UD IF in VMX non-root operation THEN VMexit; IF CPL > 0 THEN #GP(0) IF in VMX operation THEN VMfail("VMXON executed in VMX root operation"); IF (in A20M mode) or (the values of CR0 and CR4 are not supported in VMX operation) THEN #GP(0); Note, KVM unconditionally forwards VMXON VM-Exits that occur in L2 to L1, i.e. there is no need to check the vCPU is not in VMX non-root mode. Add a comment to explain why unconditionally forwarding such exits is functionally correct. Reported-by: Eric Li <ercli(a)ucdavis.edu> Fixes: c7d855c2aff2 ("KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4") Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Link: https://lore.kernel.org/r/20221006001956.329314-1-seanjc@google.com Signed-off-by: rminmin <renmm6(a)chinaunicom.cn> --- arch/x86/kvm/vmx/nested.c | 44 +++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 11 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 9003b14d72ca..40225b770942 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -4899,24 +4899,35 @@ static int handle_vmon(struct kvm_vcpu *vcpu) | FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX; /* - * Note, KVM cannot rely on hardware to perform the CR0/CR4 #UD checks - * that have higher priority than VM-Exit (see Intel SDM's pseudocode - * for VMXON), as KVM must load valid CR0/CR4 values into hardware while - * running the guest, i.e. KVM needs to check the _guest_ values. + * Manually check CR4.VMXE checks, KVM must force CR4.VMXE=1 to enter + * the guest and so cannot rely on hardware to perform the check, + * which has higher priority than VM-Exit (see Intel SDM's pseudocode + * for VMXON). * - * Rely on hardware for the other two pre-VM-Exit checks, !VM86 and - * !COMPATIBILITY modes. KVM may run the guest in VM86 to emulate Real - * Mode, but KVM will never take the guest out of those modes. + * Rely on hardware for the other pre-VM-Exit checks, CR0.PE=1, !VM86 + * and !COMPATIBILITY modes. For an unrestricted guest, KVM doesn't + * force any of the relevant guest state. For a restricted guest, KVM + * does force CR0.PE=1, but only to also force VM86 in order to emulate + * Real Mode, and so there's no need to check CR0.PE manually. */ - if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) || - !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) { + if (!kvm_read_cr4_bits(vcpu, X86_CR4_VMXE)) { kvm_queue_exception(vcpu, UD_VECTOR); return 1; } /* - * CPL=0 and all other checks that are lower priority than VM-Exit must - * be checked manually. + * The CPL is checked for "not in VMX operation" and for "in VMX root", + * and has higher priority than the VM-Fail due to being post-VMXON, + * i.e. VMXON #GPs outside of VMX non-root if CPL!=0. In VMX non-root, + * VMXON causes VM-Exit and KVM unconditionally forwards VMXON VM-Exits + * from L2 to L1, i.e. there's no need to check for the vCPU being in + * VMX non-root. + * + * Forwarding the VM-Exit unconditionally, i.e. without performing the + * #UD checks (see above), is functionally ok because KVM doesn't allow + * L1 to run L2 without CR4.VMXE=0, and because KVM never modifies L2's + * CR0 or CR4, i.e. it's L2's responsibility to emulate #UDs that are + * missed by hardware due to shadowing CR0 and/or CR4. */ if (vmx_get_cpl(vcpu)) { kvm_inject_gp(vcpu, 0); @@ -4926,6 +4937,17 @@ static int handle_vmon(struct kvm_vcpu *vcpu) if (vmx->nested.vmxon) return nested_vmx_fail(vcpu, VMXERR_VMXON_IN_VMX_ROOT_OPERATION); + /* + * Invalid CR0/CR4 generates #GP. These checks are performed if and + * only if the vCPU isn't already in VMX operation, i.e. effectively + * have lower priority than the VM-Fail above. + */ + if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) || + !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) { + kvm_inject_gp(vcpu, 0); + return 1; + } + if ((vmx->msr_ia32_feature_control & VMXON_NEEDED_FEATURES) != VMXON_NEEDED_FEATURES) { kvm_inject_gp(vcpu, 0); -- 2.33.0 Èç¹ûÄúŽíÎóœÓÊÕÁËžÃÓÊŒþ£¬ÇëÍš¹ýµç×ÓÓÊŒþÁ¢ŒŽÍšÖªÎÒÃÇ¡£Çë»ØžŽÓÊŒþµœ hqs-spmc@chinaunicom.cn£¬ŒŽ¿ÉÒÔÍË¶©ŽËÓÊŒþ¡£ÎÒÃÇœ«Á¢ŒŽœ«ÄúµÄÐÅÏ¢ŽÓÎÒÃÇµÄ·¢ËÍÄ¿ÂŒÖÐÉŸ³ý¡£ If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc(a)chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

1 0

[PATCH OLK-5.10] KVM: nVMX: Inject #GP, not #UD, if "generic" VMXON CR0/CR4 check fails
by 任敏敏(联通集团联通数字科技有限公司本部) 23 Apr '23

23 Apr '23

From: Sean Christopherson <seanjc(a)google.com> stable inclusion from stable-v6.2 commit 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6XQ34 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 upstream Inject #GP for if VMXON is attempting with a CR0/CR4 that fails the generic "is CRx valid" check, but passes the CR4.VMXE check, and do the generic checks _after_ handling the post-VMXON VM-Fail. The CR4.VMXE check, and all other #UD cases, are special pre-conditions that are enforced prior to pivoting on the current VMX mode, i.e. occur before interception if VMXON is attempted in VMX non-root mode. All other CR0/CR4 checks generate #GP and effectively have lower priority than the post-VMXON check. Per the SDM: IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ... THEN #UD; ELSIF not in VMX operation THEN IF (CPL > 0) or (in A20M mode) or (the values of CR0 and CR4 are not supported in VMX operation) THEN #GP(0); ELSIF in VMX non-root operation THEN VMexit; ELSIF CPL > 0 THEN #GP(0); ELSE VMfail("VMXON executed in VMX root operation"); FI; which, if re-written without ELSIF, yields: IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ... THEN #UD IF in VMX non-root operation THEN VMexit; IF CPL > 0 THEN #GP(0) IF in VMX operation THEN VMfail("VMXON executed in VMX root operation"); IF (in A20M mode) or (the values of CR0 and CR4 are not supported in VMX operation) THEN #GP(0); Note, KVM unconditionally forwards VMXON VM-Exits that occur in L2 to L1, i.e. there is no need to check the vCPU is not in VMX non-root mode. Add a comment to explain why unconditionally forwarding such exits is functionally correct. Reported-by: Eric Li <ercli(a)ucdavis.edu> Fixes: c7d855c2aff2 ("KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4") Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Link: https://lore.kernel.org/r/20221006001956.329314-1-seanjc@google.com Signed-off-by: rminmin <renmm6(a)chinaunicom.cn> --- arch/x86/kvm/vmx/nested.c | 44 +++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 11 deletions(-) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index 9003b14d72ca..40225b770942 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -4899,24 +4899,35 @@ static int handle_vmon(struct kvm_vcpu *vcpu) | FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX; /* - * Note, KVM cannot rely on hardware to perform the CR0/CR4 #UD checks - * that have higher priority than VM-Exit (see Intel SDM's pseudocode - * for VMXON), as KVM must load valid CR0/CR4 values into hardware while - * running the guest, i.e. KVM needs to check the _guest_ values. + * Manually check CR4.VMXE checks, KVM must force CR4.VMXE=1 to enter + * the guest and so cannot rely on hardware to perform the check, + * which has higher priority than VM-Exit (see Intel SDM's pseudocode + * for VMXON). * - * Rely on hardware for the other two pre-VM-Exit checks, !VM86 and - * !COMPATIBILITY modes. KVM may run the guest in VM86 to emulate Real - * Mode, but KVM will never take the guest out of those modes. + * Rely on hardware for the other pre-VM-Exit checks, CR0.PE=1, !VM86 + * and !COMPATIBILITY modes. For an unrestricted guest, KVM doesn't + * force any of the relevant guest state. For a restricted guest, KVM + * does force CR0.PE=1, but only to also force VM86 in order to emulate + * Real Mode, and so there's no need to check CR0.PE manually. */ - if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) || - !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) { + if (!kvm_read_cr4_bits(vcpu, X86_CR4_VMXE)) { kvm_queue_exception(vcpu, UD_VECTOR); return 1; } /* - * CPL=0 and all other checks that are lower priority than VM-Exit must - * be checked manually. + * The CPL is checked for "not in VMX operation" and for "in VMX root", + * and has higher priority than the VM-Fail due to being post-VMXON, + * i.e. VMXON #GPs outside of VMX non-root if CPL!=0. In VMX non-root, + * VMXON causes VM-Exit and KVM unconditionally forwards VMXON VM-Exits + * from L2 to L1, i.e. there's no need to check for the vCPU being in + * VMX non-root. + * + * Forwarding the VM-Exit unconditionally, i.e. without performing the + * #UD checks (see above), is functionally ok because KVM doesn't allow + * L1 to run L2 without CR4.VMXE=0, and because KVM never modifies L2's + * CR0 or CR4, i.e. it's L2's responsibility to emulate #UDs that are + * missed by hardware due to shadowing CR0 and/or CR4. */ if (vmx_get_cpl(vcpu)) { kvm_inject_gp(vcpu, 0); @@ -4926,6 +4937,17 @@ static int handle_vmon(struct kvm_vcpu *vcpu) if (vmx->nested.vmxon) return nested_vmx_fail(vcpu, VMXERR_VMXON_IN_VMX_ROOT_OPERATION); + /* + * Invalid CR0/CR4 generates #GP. These checks are performed if and + * only if the vCPU isn't already in VMX operation, i.e. effectively + * have lower priority than the VM-Fail above. + */ + if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) || + !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) { + kvm_inject_gp(vcpu, 0); + return 1; + } + if ((vmx->msr_ia32_feature_control & VMXON_NEEDED_FEATURES) != VMXON_NEEDED_FEATURES) { kvm_inject_gp(vcpu, 0); -- 2.33.0 Èç¹ûÄúŽíÎóœÓÊÕÁËžÃÓÊŒþ£¬ÇëÍš¹ýµç×ÓÓÊŒþÁ¢ŒŽÍšÖªÎÒÃÇ¡£Çë»ØžŽÓÊŒþµœ hqs-spmc@chinaunicom.cn£¬ŒŽ¿ÉÒÔÍË¶©ŽËÓÊŒþ¡£ÎÒÃÇœ«Á¢ŒŽœ«ÄúµÄÐÅÏ¢ŽÓÎÒÃÇµÄ·¢ËÍÄ¿ÂŒÖÐÉŸ³ý¡£ If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc(a)chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

2 1

Re: [openEuler-22.03-LTS,v1,0/6] Add perf metricgroup support for HiSilicon hip08 platform
by patchwork bot 23 Apr '23

23 Apr '23

your patch has been converted to a pull request, pull request link is: https://gitee.com/openeuler/kernel/pulls/609

1 0

[PATCH openEuler-22.03-LTS v1 0/6] Add perf metricgroup support for HiSilicon hip08 platform
by Wei Li 23 Apr '23

23 Apr '23

Add perf metricgroup support for HiSilicon hip08 platform, tested on Huawei D06 board. John Garry (6): perf metricgroup: Make find_metric() public with name change perf test: Handle metric reuse in pmu-events parsing test perf pmu: Add pmu_events_map__find() function to find the common PMU map for the system perf vendor events arm64: Add Hisi hip08 L1 metrics perf vendor events arm64: Add Hisi hip08 L2 metrics perf vendor events arm64: Add Hisi hip08 L3 metrics tools/perf/arch/arm64/util/Build | 1 + tools/perf/arch/arm64/util/pmu.c | 25 ++ .../arch/arm64/hisilicon/hip08/metrics.json | 233 ++++++++++++++++++ tools/perf/tests/pmu-events.c | 83 ++++++- tools/perf/util/metricgroup.c | 11 +- tools/perf/util/metricgroup.h | 3 +- tools/perf/util/pmu.c | 5 + tools/perf/util/pmu.h | 1 + tools/perf/util/s390-sample-raw.c | 4 +- 9 files changed, 356 insertions(+), 10 deletions(-) create mode 100644 tools/perf/arch/arm64/util/pmu.c create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json -- 2.25.1

1 6

[PATCH openEuler-1.0-LTS] audit: fix a memleak caused by auditing load module
by Yongqiang Liu 23 Apr '23

23 Apr '23

From: Li RongQing <lirongqing(a)baidu.com> mainline inclusion from mainline-v5.2-rc1 commit 95e0b46fcebd7dbf6850dee96046e4c4ddc7f69c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6X2LV CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- module.name will be allocated unconditionally when auditing load module, and audit_log_start() can fail with other reasons, or audit_log_exit maybe not called, caused module.name is not freed so free module.name in audit_free_context and __audit_syscall_exit unreferenced object 0xffff88af90837d20 (size 8): comm "modprobe", pid 1036, jiffies 4294704867 (age 3069.138s) hex dump (first 8 bytes): 69 78 67 62 65 00 ff ff ixgbe... backtrace: [<0000000008da28fe>] __audit_log_kern_module+0x33/0x80 [<00000000c1491e61>] load_module+0x64f/0x3850 [<000000007fc9ae3f>] __do_sys_init_module+0x218/0x250 [<0000000000d4a478>] do_syscall_64+0x117/0x400 [<000000004924ded8>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<000000007dc331dd>] 0xffffffffffffffff Fixes: ca86cad7380e3 ("audit: log module name on init_module") Signed-off-by: Zhang Yu <zhangyu31(a)baidu.com> Signed-off-by: Li RongQing <lirongqing(a)baidu.com> [PM: manual merge fixup in __audit_syscall_exit()] Signed-off-by: Paul Moore <paul(a)paul-moore.com> conflict: kernel/auditsc.c Signed-off-by: Yi Yang <yiyang13(a)huawei.com> Reviewed-by: cuigaosheng <cuigaosheng1(a)huawei.com> Reviewed-by: guozihua <guozihua(a)huawei.com> Reviewed-by: Wang Weiyang <wangweiyang2(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- kernel/auditsc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 1513873e23bd..57d30b75f7a2 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -881,6 +881,13 @@ static inline void audit_proctitle_free(struct audit_context *context) context->proctitle.len = 0; } +static inline void audit_free_module(struct audit_context *context) +{ + if (context->type == AUDIT_KERN_MODULE) { + kfree(context->module.name); + context->module.name = NULL; + } +} static inline void audit_free_names(struct audit_context *context) { struct audit_names *n, *next; @@ -964,6 +971,7 @@ int audit_alloc(struct task_struct *tsk) static inline void audit_free_context(struct audit_context *context) { + audit_free_module(context); audit_free_names(context); unroll_tree_refs(context, NULL, 0); free_tree_refs(context); @@ -1281,7 +1289,6 @@ static void show_special(struct audit_context *context, int *call_panic) audit_log_format(ab, "name="); if (context->module.name) { audit_log_untrustedstring(ab, context->module.name); - kfree(context->module.name); } else audit_log_format(ab, "(null)"); @@ -1583,6 +1590,7 @@ void __audit_syscall_exit(int success, long return_code) if (!list_empty(&context->killed_trees)) audit_kill_trees(&context->killed_trees); + audit_free_module(context); audit_free_names(context); unroll_tree_refs(context, NULL, 0); audit_free_aux(context); -- 2.25.1

1 0

[PATCH OLK-5.10 v1 0/6] Add perf metricgroup support for HiSilicon hip08 platform
by Wei Li 23 Apr '23

23 Apr '23

Add perf metricgroup support for HiSilicon hip08 platform, tested on Huawei D06 board. John Garry (6): perf metricgroup: Make find_metric() public with name change perf test: Handle metric reuse in pmu-events parsing test perf pmu: Add pmu_events_map__find() function to find the common PMU map for the system perf vendor events arm64: Add Hisi hip08 L1 metrics perf vendor events arm64: Add Hisi hip08 L2 metrics perf vendor events arm64: Add Hisi hip08 L3 metrics tools/perf/arch/arm64/util/Build | 1 + tools/perf/arch/arm64/util/pmu.c | 25 ++ .../arch/arm64/hisilicon/hip08/metrics.json | 233 ++++++++++++++++++ tools/perf/tests/pmu-events.c | 83 ++++++- tools/perf/util/metricgroup.c | 11 +- tools/perf/util/metricgroup.h | 3 +- tools/perf/util/pmu.c | 5 + tools/perf/util/pmu.h | 1 + tools/perf/util/s390-sample-raw.c | 4 +- 9 files changed, 356 insertions(+), 10 deletions(-) create mode 100644 tools/perf/arch/arm64/util/pmu.c create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json -- 2.25.1

2 7

Re: [PATCH v3] mm: oom: move memcg_print_bad_task() out of mem_cgroup_scan_tasks()
by Zheng Zengkai 22 Apr '23

22 Apr '23

在 2023/4/17 21:12, Kefeng Wang 写道: > + Zengkai > > Could you merge this patch? +zhangjialin Hi Kefeng and Kang Chen Is this patch same as the one in PR #582(https://gitee.com/openeuler/kernel/pulls/582) ? If so，let's tracking it via the gitee PR, Here are some notices about contribution to openEuler kernel: https://gitee.com/openeuler/kernel/issues/I6WKLA Thank you! > > On 2023/4/17 19:13, Kang Chen wrote: >> hulk inclusion >> category: bugfix >> bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NYW4 >> CVE: NA >> >> -------------------------------- >> >> raw call flow: >> >> oom_kill_process >> -> mem_cgroup_scan_tasks(.., .., message) >> -> memcg_print_bad_task(message, ..) >> >> message is "const char*" type, and incorrectly cast to >> "oom_control*" type in memcg_print_bad_task. > > a blank line, > >> Fix it by moving memcg_print_bad_task out of mem_cgroup_scan_tasks >> and call it in select_bad_process and dump_tasks. Furthermore, >> use struct oom_control* directly and remove the useless parm `ret`. >> > > Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> > >> Signed-off-by: Kang Chen <void0red(a)hust.edu.cn> >> --- >> v3 -> v2: use type `struct oom_control *` directly and fix bugs >> v2 -> v1: remove parm `ret` and create a memcg_print_bad_task stub >> >> mm/memcontrol.c | 16 +++++++++------- >> mm/oom_kill.c | 14 ++++++++------ >> 2 files changed, 17 insertions(+), 13 deletions(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 635cb8b65b86..6b4f70d090d6 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -1214,9 +1214,6 @@ int mem_cgroup_scan_tasks(struct mem_cgroup >> *memcg, >> break; >> } >> } >> -#ifdef CONFIG_MEMCG_QOS >> - memcg_print_bad_task(arg, ret); >> -#endif >> return ret; >> } >> @@ -4004,14 +4001,12 @@ bool memcg_low_priority_scan_tasks(int >> (*fn)(struct task_struct *, void *), >> return oc->chosen ? true : false; >> } >> -void memcg_print_bad_task(void *arg, int ret) >> +void memcg_print_bad_task(struct oom_control *oc) >> { >> - struct oom_control *oc = arg; >> - >> if (!static_branch_likely(&memcg_qos_stat_key)) >> return; >> - if (!ret && oc->chosen) { >> + if (oc->chosen) { >> struct mem_cgroup *memcg; >> memcg = mem_cgroup_from_task(oc->chosen); >> @@ -4042,6 +4037,13 @@ int sysctl_memcg_qos_handler(struct ctl_table >> *table, int write, >> return ret; >> } >> + >> +#else >> + >> +void memcg_print_bad_task(struct oom_control *oc) >> +{ >> +} >> + >> #endif >> #ifdef CONFIG_NUMA >> diff --git a/mm/oom_kill.c b/mm/oom_kill.c >> index 0f77eb4c6644..9d595265bbf5 100644 >> --- a/mm/oom_kill.c >> +++ b/mm/oom_kill.c >> @@ -408,9 +408,10 @@ static void select_bad_process(struct >> oom_control *oc) >> { >> oc->chosen_points = LONG_MIN; >> - if (is_memcg_oom(oc)) >> - mem_cgroup_scan_tasks(oc->memcg, oom_evaluate_task, oc); >> - else { >> + if (is_memcg_oom(oc)) { >> + if (!mem_cgroup_scan_tasks(oc->memcg, oom_evaluate_task, oc)) >> + memcg_print_bad_task(oc); >> + } else { >> struct task_struct *p; >> #ifdef CONFIG_MEMCG_QOS >> @@ -473,9 +474,10 @@ static void dump_tasks(struct oom_control *oc) >> pr_info("Tasks state (memory values in pages):\n"); >> pr_info("[ pid ] uid tgid total_vm rss pgtables_bytes >> swapents oom_score_adj name\n"); >> - if (is_memcg_oom(oc)) >> - mem_cgroup_scan_tasks(oc->memcg, dump_task, oc); >> - else { >> + if (is_memcg_oom(oc)) { >> + if (!mem_cgroup_scan_tasks(oc->memcg, dump_task, oc)) >> + memcg_print_bad_task(oc); >> + } else { >> struct task_struct *p; >> rcu_read_lock(); > . >

3 2

[PATCH openEuler-1.0-LTS 0/6] efi: fix crash due to EFI runtime service page faults
by Ding Hui 20 Apr '23

20 Apr '23

For both arm64 and x86, handle and recovery from page faults due to EFI runtime service, and disable subsequent invoking, we can avoid crash the whole system when running on buggy EFI firmware, and get log like this: kernel: [Firmware Bug]: Unable to handle paging request in EFI runtime service kernel: CPU: 54 PID: 8 Comm: kworker/u256:0 Kdump: loaded Tainted: G IOE 4.19.90-2112.8.0.0131.oe1.aarch64.debug #66 kernel: Hardware name: O.D.M FT-2500 Platform/T1DMFT-E4 , BIOS KL4.26.ODM.S.032.210904.R 09/04/21 13:28:40 kernel: Workqueue: efi_rts_wq efi_call_rts kernel: Call trace: kernel: dump_backtrace+0x0/0x170 kernel: show_stack+0x24/0x30 kernel: dump_stack+0xa4/0xe8 kernel: efi_runtime_fixup_exception+0x74/0x8c kernel: __do_kernel_fault+0x8c/0x150 kernel: do_page_fault+0x78/0x4c8 kernel: do_translation_fault+0xa8/0xbc kernel: do_mem_abort+0x50/0xe0 kernel: el1_da+0x20/0x94 kernel: 0x213f0c24 kernel: 0x213f0d64 kernel: 0x213f044c kernel: 0x213f04b4 kernel: 0x213f0178 kernel: 0x212e0664 kernel: __efi_rt_asm_wrapper+0x50/0x6c kernel: efi_call_rts+0x414/0x430 kernel: process_one_work+0x1f8/0x490 kernel: worker_thread+0x50/0x4b8 kernel: kthread+0x134/0x138 kernel: ret_from_fork+0x10/0x18 kernel: [Firmware Bug]: Synchronous exception occurred in EFI runtime service get_time() kernel: rtc-efi rtc-efi: can't read time kernel: efi: EFI Runtime Services are disabled! Anders Roxell (1): efi: Fix build error due to enum collision between efi.h and ima.h Ard Biesheuvel (1): arm64: efi: Recover from synchronous exceptions occurring in firmware Sai Praneeth (2): efi: Make efi_rts_work accessible to efi page fault handler efi/x86: Handle page faults occurring while running EFI runtime services Sami Tolvanen (1): arm64: efi: Restore register x18 if it was corrupted Waiman Long (1): efi: Fix debugobjects warning on 'efi_rts_work' arch/arm64/include/asm/efi.h | 9 ++ arch/arm64/kernel/efi-rt-wrapper.S | 46 +++++++++- arch/arm64/kernel/efi.c | 26 ++++++ arch/arm64/mm/fault.c | 4 + arch/x86/include/asm/efi.h | 1 + arch/x86/mm/fault.c | 9 ++ arch/x86/platform/efi/quirks.c | 78 +++++++++++++++++ drivers/firmware/efi/runtime-wrappers.c | 107 +++++++++--------------- include/linux/efi.h | 42 ++++++++++ 9 files changed, 252 insertions(+), 70 deletions(-) -- 2.17.1

1 6

[PATCH openEuler-1.0-LTS] iommu/arm-smmu-v3: Fix UAF when handle evt during iommu group removing
by Ding Hui 20 Apr '23

20 Apr '23

driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKM7 CVE: NA -------- A use-after-free issue like following: [ 2257.819189] arm-smmu-v3 arm-smmu-v3.4.auto: EVTQ overflow detected -- events lost [ 2257.819197] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received: [ 2257.819199] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000820000000010 [ 2257.819201] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000020000000000 [ 2257.819202] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7218 [ 2257.819206] iommu: Removing device 0000:82:00.0 from group 49 [ 2257.819207] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7000 [ 2257.819211] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received: [ 2257.819212] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000820000000010 [ 2257.819214] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000020000000000 [ 2257.819215] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea722c [ 2257.819216] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7000 [ 2257.819218] ================================================================== [ 2257.819228] BUG: KASAN: use-after-free in iommu_report_device_fault+0x520/0x5c0 [ 2257.819230] Read of size 8 at addr ffffa02c516c1320 by task irq/63-arm-smmu/483 [ 2257.819231] [ 2257.819235] CPU: 25 PID: 483 Comm: irq/63-arm-smmu Kdump: loaded Tainted: G OE 4.19.90-2205.3.0.0149.oe1.aarch64+debug #1 [ 2257.819236] Hardware name: Huawei S920S00/BC82AMDGK, BIOS 1.68 11/10/2020 [ 2257.819237] Call trace: [ 2257.819240] dump_backtrace+0x0/0x320 [ 2257.819242] show_stack+0x24/0x30 [ 2257.819246] dump_stack+0xdc/0x128 [ 2257.819251] print_address_description+0x68/0x278 [ 2257.819253] kasan_report+0x1e4/0x308 [ 2257.819254] __asan_report_load8_noabort+0x30/0x40 [ 2257.819257] iommu_report_device_fault+0x520/0x5c0 [ 2257.819260] arm_smmu_handle_evt+0x300/0x428 [ 2257.819261] arm_smmu_evtq_thread+0x27c/0x460 [ 2257.819264] irq_thread_fn+0x88/0x140 [ 2257.819266] irq_thread+0x190/0x318 [ 2257.819268] kthread+0x2a4/0x320 [ 2257.819270] ret_from_fork+0x10/0x18 [ 2257.819271] [ 2257.819273] Allocated by task 95166: [ 2257.819275] kasan_kmalloc+0xd0/0x178 [ 2257.819277] kmem_cache_alloc_trace+0x100/0x210 [ 2257.819279] iommu_group_add_device+0x254/0xe18 [ 2257.819280] iommu_group_get_for_dev+0x198/0x480 [ 2257.819282] arm_smmu_add_device+0x424/0x988 [ 2257.819284] iort_iommu_configure+0x33c/0x5b8 [ 2257.819287] acpi_dma_configure+0x9c/0xf8 [ 2257.819289] pci_dma_configure+0x124/0x158 [ 2257.819291] dma_configure+0x5c/0x80 [ 2257.819294] really_probe+0xcc/0x920 [ 2257.819296] driver_probe_device+0x224/0x308 [ 2257.819298] __device_attach_driver+0x154/0x260 [ 2257.819299] bus_for_each_drv+0xe4/0x178 [ 2257.819301] __device_attach+0x1bc/0x2a8 [ 2257.819302] device_attach+0x24/0x30 [ 2257.819304] pci_bus_add_device+0x7c/0xe8 [ 2257.819305] pci_bus_add_devices+0x70/0x168 [ 2257.819307] pci_bus_add_devices+0x114/0x168 [ 2257.819308] pci_rescan_bus+0x38/0x48 [ 2257.819310] bus_rescan_store+0xc4/0xe8 [ 2257.819312] bus_attr_store+0x70/0x98 [ 2257.819314] sysfs_kf_write+0x104/0x170 [ 2257.819316] kernfs_fop_write+0x23c/0x430 [ 2257.819319] __vfs_write+0x7c/0xe8 [ 2257.819320] vfs_write+0x12c/0x3d0 [ 2257.819321] ksys_write+0xd4/0x1d8 [ 2257.819322] __arm64_sys_write+0x70/0xa0 [ 2257.819325] el0_svc_common+0xfc/0x278 [ 2257.819327] el0_svc_handler+0x50/0xc0 [ 2257.819329] el0_svc+0x8/0x1b0 [ 2257.819329] [ 2257.819330] Freed by task 95166: [ 2257.819332] __kasan_slab_free+0x114/0x200 [ 2257.819334] kasan_slab_free+0x10/0x18 [ 2257.819335] kfree+0x80/0x1f0 [ 2257.819337] iommu_group_remove_device+0x27c/0x560 [ 2257.819338] arm_smmu_remove_device+0xe8/0x190 [ 2257.819339] iommu_bus_notifier+0x134/0x248 [ 2257.819342] notifier_call_chain+0xb0/0x140 [ 2257.819343] blocking_notifier_call_chain+0x6c/0xd8 [ 2257.819344] device_del+0x578/0x940 [ 2257.819346] pci_remove_bus_device+0x114/0x290 [ 2257.819347] pci_stop_and_remove_bus_device_locked+0x2c/0x40 [ 2257.819349] remove_store+0xdc/0xe8 [ 2257.819352] dev_attr_store+0x60/0x80 [ 2257.819353] sysfs_kf_write+0x104/0x170 [ 2257.819354] kernfs_fop_write+0x23c/0x430 [ 2257.819355] __vfs_write+0x7c/0xe8 [ 2257.819357] vfs_write+0x12c/0x3d0 [ 2257.819358] ksys_write+0xd4/0x1d8 [ 2257.819359] __arm64_sys_write+0x70/0xa0 [ 2257.819361] el0_svc_common+0xfc/0x278 [ 2257.819362] el0_svc_handler+0x50/0xc0 [ 2257.819364] el0_svc+0x8/0x1b0 [ 2257.819364] T0 T1 --------------------------------- --------------------------------- |- arm_smmu_evtq_thread |- arm_smmu_remove_device |- arm_smmu_handle_evt |- iommu_group_remove_device |- kfree(dev->iommu_param) |- arm_smmu_find_master |- iommu_report_device_fault |- arm_smmu_remove_master |- mutex_lock( \ &dev->iommu_param->lock) // UAF Reference upstream mainline commit 395ad89d11fd93f79a6b942e91fc409807a63c4b, move arm_smmu_remove_master() before iommu_group_remove_device(), and hold mutex to protect finding master and subsequent handling. Fixes: b525f0a6f9b0 ("iommu/arm-smmu-v3: Add stall support for platform devices") Signed-off-by: Ding Hui <dinghui(a)sangfor.com.cn> --- drivers/iommu/arm-smmu-v3.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index 3309ae6ebc0b..05cb92da6836 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -1742,7 +1742,8 @@ arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid) struct arm_smmu_stream *stream; struct arm_smmu_master_data *master = NULL; - mutex_lock(&smmu->streams_mutex); + lockdep_assert_held(&smmu->streams_mutex); + node = smmu->streams.rb_node; while (node) { stream = rb_entry(node, struct arm_smmu_stream, node); @@ -1755,7 +1756,6 @@ arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid) break; } } - mutex_unlock(&smmu->streams_mutex); return master; } @@ -1791,9 +1791,12 @@ static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt) if (evt[1] & EVTQ_1_S2) return -EFAULT; + mutex_lock(&smmu->streams_mutex); master = arm_smmu_find_master(smmu, sid); - if (!master) - return -EINVAL; + if (!master) { + ret = -EINVAL; + goto out_unlock; + } /* * The domain is valid until the fault returns, because detach() flushes @@ -1833,6 +1836,8 @@ static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt) arm_smmu_page_response(master->dev, &resp); } +out_unlock: + mutex_unlock(&smmu->streams_mutex); return ret; } @@ -2935,8 +2940,8 @@ static void arm_smmu_remove_device(struct device *dev) iopf_queue_remove_device(dev); if (master->ste.assigned) arm_smmu_detach_dev(dev); - iommu_group_remove_device(dev); arm_smmu_remove_master(smmu, master); + iommu_group_remove_device(dev); iommu_device_unlink(&smmu->iommu, dev); kfree(master); iommu_fwspec_free(dev); -- 2.17.1

1 0

ODD2023-Kernel SIG 开放工作会议
by openEuler conference 19 Apr '23

19 Apr '23

您好！ Kernel SIG 邀请您参加 2023-04-21 16:00 召开的Zoom会议(自动录制) 会议主题：ODD2023-Kernel SIG 开放工作会议会议内容： 1. 华中大网安学院内核贡献团队组建经验分享 2. 互联网领域的挑战与技术 3. ext4文件系统问题（一致性、稳定性）的挖掘和定位 4. 可编程内核技术落地场景分享和未来畅想欢迎继续申报议题~ 会议链接：https://us06web.zoom.us/j/88277699752?pwd=VTB3ZjhFR1pKd0syc3NpMDVDcVRvZz09 会议纪要：https://etherpad.openeuler.org/p/ODD2023_Kernel_SIG 温馨提醒：建议接入会议后修改参会人的姓名，也可以使用您在gitee.com的ID 更多资讯尽在：https://openeuler.org/zh/ Hello! openEuler Kernel SIG invites you to attend the Zoom conference(auto recording) will be held at 2023-04-21 16:00, The subject of the conference is ODD2023-Kernel SIG 开放工作会议, Summary: 1. 华中大网安学院内核贡献团队组建经验分享 2. 互联网领域的挑战与技术 3. ext4文件系统问题（一致性、稳定性）的挖掘和定位 4. 可编程内核技术落地场景分享和未来畅想欢迎继续申报议题~ You can join the meeting at https://us06web.zoom.us/j/88277699752?pwd=VTB3ZjhFR1pKd0syc3NpMDVDcVRvZz09. Add topics at https://etherpad.openeuler.org/p/ODD2023_Kernel_SIG. Note: You are advised to change the participant name after joining the conference or use your ID at gitee.com. More information: https://openeuler.org/en/

1 0

2024

2023

2022

2021

2020

2019

Kernel