mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 44 participants
  • 18676 discussions
[PATCH openEuler-1.0-LTS] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24
From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5IQ CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2
2 1
0 0
[openeuler:OLK-5.10] BUILD SUCCESS 93f42c5daddd692f4cc1f56387774d46e083147c
by kernel test robot 07 May '24

07 May '24
tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 93f42c5daddd692f4cc1f56387774d46e083147c !6798 media: ir_toy: fix a memleak in irtoy_tx Warning ids grouped by kconfigs: clang_recent_errors |-- arm64-allyesconfig | |-- Documentation-devicetree-bindings-arm-cpu.yaml:properties:capacity-dmips-mhz:ref-should-not-be-valid-under-const:ref | |-- Documentation-devicetree-bindings-arm-cpu.yaml:title:ARM-CPUs-bindings-should-not-be-valid-under-pattern:(-Bb-inding-Ss-chema) | |-- Documentation-devicetree-bindings-arm-cpus.yaml:examples:cpus-arm-pbha-performance-only-bits-arm-pbha-no-aliases-bits-ncpu-device_type-cpu-compatible-arm-cortex-a57-...-n-is-not-of-type-array | |-- Documentation-devicetree-bindings-arm-cpus.yaml:maintainers-is-a-required-property | |-- description:Display-controller-reference-clock-source-is-not-of-type-object-boolean | |-- description:Display-controller-reference-clock-source-is-too-short | |-- description:Offset-and-length-of-the-memory-mapped-registers-is-too-short | |-- items-is-not-one-of-type-description-dependencies-dependentRequired-dependentSchemas-properties-patternProperties-additionalProperties-unevaluatedProperties-deprecated-required-not-allOf-anyOf-oneOf-r | `-- minItems-is-not-one-of-type-description-dependencies-dependentRequired-dependentSchemas-properties-patternProperties-additionalProperties-unevaluatedProperties-deprecated-required-not-allOf-anyOf-oneO `-- x86_64-allnoconfig |-- Warning:openEuler-MAINTAINERS-references-a-file-that-doesn-t-exist:Documentation-networking-hinic3.rst `-- drivers-net-ethernet-mucse-rnpm-rnpm_common.h:linux-version.h-not-needed. elapsed time: 729m configs tested: 35 configs skipped: 149 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240507 clang arm64 randconfig-002-20240507 clang arm64 randconfig-003-20240507 clang arm64 randconfig-004-20240507 clang x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240507 clang x86_64 buildonly-randconfig-002-20240507 clang x86_64 buildonly-randconfig-003-20240507 clang x86_64 buildonly-randconfig-004-20240507 clang x86_64 buildonly-randconfig-005-20240507 clang x86_64 buildonly-randconfig-006-20240507 gcc x86_64 defconfig gcc x86_64 randconfig-001-20240507 gcc x86_64 randconfig-002-20240507 clang x86_64 randconfig-003-20240507 clang x86_64 randconfig-004-20240507 gcc x86_64 randconfig-005-20240507 gcc x86_64 randconfig-006-20240507 gcc x86_64 randconfig-011-20240507 gcc x86_64 randconfig-012-20240507 clang x86_64 randconfig-013-20240507 clang x86_64 randconfig-014-20240507 clang x86_64 randconfig-015-20240507 clang x86_64 randconfig-016-20240507 clang x86_64 randconfig-071-20240507 gcc x86_64 randconfig-072-20240507 gcc x86_64 randconfig-073-20240507 clang x86_64 randconfig-074-20240507 clang x86_64 randconfig-075-20240507 clang x86_64 randconfig-076-20240507 clang x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openEuler-1.0-LTS] nouveau: fix instmem race condition around ptr stores
by Yipeng Zou 07 May '24

07 May '24
From: Dave Airlie <airlied(a)redhat.com> stable inclusion from stable-v5.10 commit 13d76b2f443dc371842916dd8768009ff1594716 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9LK8M CVE: CVE-2024-26984 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit fff1386cc889d8fb4089d285f883f8cba62d82ce upstream. Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb. Cc: <stable(a)vger.kernel.org> Fixes: be55287aa5ba ("drm/nouveau/imem/nv50: embed nvkm_instobj directly into nv04_instobj") Signed-off-by: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Danilo Krummrich <dakr(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240411011510.2546857-1-airl… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c index db48a1daca0c..f8ca79eaa7f7 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c @@ -221,8 +221,11 @@ nv50_instobj_acquire(struct nvkm_memory *memory) void __iomem *map = NULL; /* Already mapped? */ - if (refcount_inc_not_zero(&iobj->maps)) + if (refcount_inc_not_zero(&iobj->maps)) { + /* read barrier match the wmb on refcount set */ + smp_rmb(); return iobj->map; + } /* Take the lock, and re-check that another thread hasn't * already mapped the object in the meantime. @@ -249,6 +252,8 @@ nv50_instobj_acquire(struct nvkm_memory *memory) iobj->base.memory.ptrs = &nv50_instobj_fast; else iobj->base.memory.ptrs = &nv50_instobj_slow; + /* barrier to ensure the ptrs are written before refcount is set */ + smp_wmb(); refcount_set(&iobj->maps, 1); } -- 2.34.1
1 0
0 0
[PATCH OLK-5.10] kprobes: Fix check for probe enabled in kill_kprobe()
by Pu Lehui 07 May '24

07 May '24
From: Li Huafei <lihuafei1(a)huawei.com> mainline inclusion from mainline-v6.2-rc1 commit 0c76ef3f26d5ef2ac2c21b47e7620cff35809fbb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MXH3 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be called always fails. This is because before that we set the KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always false. The disarm_kprobe_ftrace() call introduced by commit: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler") to fix the NULL pointer reference problem. When the probe is enabled, if we do not disarm it, this problem still exists. Fix it by putting the probe enabled check before setting the KPROBE_FLAG_GONE flag. Link: https://lore.kernel.org/all/20221126114316.201857-1-lihuafei1@huawei.com/ Fixes: 3031313eb3d54 ("kprobes: Fix to check probe enabled before disarm_kprobe_ftrace()") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/kprobes.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 6fd66a47b476..325a81f9c38f 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -2281,6 +2281,14 @@ static void kill_kprobe(struct kprobe *p) if (WARN_ON_ONCE(kprobe_gone(p))) return; + /* + * The module is going away. We should disarm the kprobe which + * is using ftrace, because ftrace framework is still available at + * MODULE_STATE_GOING notification. + */ + if (kprobe_ftrace(p) && !kprobe_disabled(p) && !kprobes_all_disarmed) + disarm_kprobe_ftrace(p); + p->flags |= KPROBE_FLAG_GONE; if (kprobe_aggrprobe(p)) { /* @@ -2297,14 +2305,6 @@ static void kill_kprobe(struct kprobe *p) * the original probed function (which will be freed soon) any more. */ arch_remove_kprobe(p); - - /* - * The module is going away. We should disarm the kprobe which - * is using ftrace, because ftrace framework is still available at - * MODULE_STATE_GOING notification. - */ - if (kprobe_ftrace(p) && !kprobe_disabled(p) && !kprobes_all_disarmed) - disarm_kprobe_ftrace(p); } /* Disable one kprobe */ -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24
From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: 189875 CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2
2 1
0 0
[PATCH OLK-5.10] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24
From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5IQ CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2
2 1
0 0
[PATCH OLK-6.6] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24
From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: 189875 CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2
2 1
0 0
[PATCH OLK-5.10] perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling
by Luo Gengkun 07 May '24

07 May '24
From: Ravi Bangoria <ravi.bangoria(a)amd.com> mainline inclusion from mainline-v6.1-rc6v6.1 commit baa014b9543c8e5e94f5d15b66abfe60750b8284 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MMNG Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- amd_pmu_enable_all() does: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK> amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu. Fixes: ada543459cab ("perf/x86/amd: Add AMD Fam19h Branch Sampling support") Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Signed-off-by: Ravi Bangoria <ravi.bangoria(a)amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20221114044029.373-1-ravi.bangoria@amd.com Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- arch/x86/events/amd/core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c index 2c082abb930b..3127519281f5 100644 --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -900,8 +900,7 @@ static int amd_pmu_handle_irq(struct pt_regs *regs) pmu_enabled = cpuc->enabled; cpuc->enabled = 0; - /* stop everything (includes BRS) */ - amd_pmu_disable_all(); + amd_brs_disable_all(); /* Drain BRS is in use (could be inactive) */ if (cpuc->lbr_users) @@ -912,7 +911,7 @@ static int amd_pmu_handle_irq(struct pt_regs *regs) cpuc->enabled = pmu_enabled; if (pmu_enabled) - amd_pmu_enable_all(0); + amd_brs_enable_all(); return amd_pmu_adjust_nmi_window(handled); } -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS] fat: fix uninitialized field in nostale filehandles
by Yifan Qiao 07 May '24

07 May '24
From: Jan Kara <jack(a)suse.cz> stable inclusion from stable-v6.8.3 commit cdd33d54e789d229d6d5007cbf3f53965ca1a5c6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5QJ CVE: CVE-2024-26973 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fde2497d2bc3a063d8af88b258dbadc86bd7b57c ] When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. Link: https://lkml.kernel.org/r/20240205122626.13701-1-jack@suse.cz Reported-by: syzbot+3ce5dea5b1539ff36769(a)syzkaller.appspotmail.com Fixes: ea3983ace6b7 ("fat: restructure export_operations") Signed-off-by: Jan Kara <jack(a)suse.cz> Acked-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/fat/nfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c index af191371c352..bab63eeaf9cb 100644 --- a/fs/fat/nfs.c +++ b/fs/fat/nfs.c @@ -130,6 +130,12 @@ fat_encode_fh_nostale(struct inode *inode, __u32 *fh, int *lenp, fid->parent_i_gen = parent->i_generation; type = FILEID_FAT_WITH_PARENT; *lenp = FAT_FID_SIZE_WITH_PARENT; + } else { + /* + * We need to initialize this field because the fh is actually + * 12 bytes long + */ + fid->parent_i_pos_hi = 0; } return type; -- 2.39.2
2 1
0 0
[PATCH OLK-5.10] fat: fix uninitialized field in nostale filehandles
by Yifan Qiao 07 May '24

07 May '24
From: Jan Kara <jack(a)suse.cz> stable inclusion from stable-v6.8.3 commit cdd33d54e789d229d6d5007cbf3f53965ca1a5c6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5QJ CVE: CVE-2024-26973 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fde2497d2bc3a063d8af88b258dbadc86bd7b57c ] When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. Link: https://lkml.kernel.org/r/20240205122626.13701-1-jack@suse.cz Reported-by: syzbot+3ce5dea5b1539ff36769(a)syzkaller.appspotmail.com Fixes: ea3983ace6b7 ("fat: restructure export_operations") Signed-off-by: Jan Kara <jack(a)suse.cz> Acked-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/fat/nfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c index af191371c352..bab63eeaf9cb 100644 --- a/fs/fat/nfs.c +++ b/fs/fat/nfs.c @@ -130,6 +130,12 @@ fat_encode_fh_nostale(struct inode *inode, __u32 *fh, int *lenp, fid->parent_i_gen = parent->i_generation; type = FILEID_FAT_WITH_PARENT; *lenp = FAT_FID_SIZE_WITH_PARENT; + } else { + /* + * We need to initialize this field because the fh is actually + * 12 bytes long + */ + fid->parent_i_pos_hi = 0; } return type; -- 2.39.2
2 1
0 0
  • ← Newer
  • 1
  • ...
  • 1074
  • 1075
  • 1076
  • 1077
  • 1078
  • 1079
  • 1080
  • ...
  • 1868
  • Older →

HyperKitty Powered by HyperKitty