- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-27002
by Yongqiang Liu 21 May '24

21 May '24

Yongqiang Liu (1): clk: mediatek: Do a runtime PM get on controllers during probe drivers/clk/mediatek/clk-mt8183-mfgcfg.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.34.1

2 2

[PATCH v4 OLK-5.10 00/11] sync hulk-5.10 patches
by Yu Kuai 21 May '24

21 May '24

Changes in v4: - just resend Changes in v3: - modify openeuler_defconfig for disabled new config in patch 1,2 Changes in v2: - fix head in commit message Christoph Hellwig (2): block: serialize all debugfs operations using q->debugfs_mutex block: remove per-disk debugfs files in blk_unregister_queue Yu Kuai (9): block: add a switch to enable hungtask check for io block: disable BLK_IO_HUNG_TASK_CHECK by default blk-throttle: add a config to control hierarchical throttle in cgroup v1 blk-throttle: fix missing prefix "CONFIG_" block: protect blk_mq_debugfs_register/unregister_hctx() with 'debugfs_mutex' block: shutdown blktrace in blk_release_queue() block: support enable/disable blk-mq debugfs dynamically block: fix kabi broken in struct request_queue block: support to disable debugfs by default arch/arm64/configs/openeuler_defconfig | 3 + arch/powerpc/configs/openeuler_defconfig | 2 + arch/x86/configs/openeuler_defconfig | 3 + block/Kconfig | 31 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 +++- block/blk-exec.c | 2 +- block/blk-mq-debugfs.c | 87 +++++++++++++++++++++--- block/blk-mq-debugfs.h | 5 -- block/blk-mq-sched.c | 11 +++ block/blk-mq.c | 12 ++++ block/blk-rq-qos.c | 2 - block/blk-rq-qos.h | 7 +- block/blk-sysfs.c | 82 ++++++++++++++++++---- block/blk-throttle.c | 17 ++++- block/blk.h | 1 + include/linux/blkdev.h | 8 ++- kernel/trace/blktrace.c | 3 - 18 files changed, 249 insertions(+), 42 deletions(-) -- 2.39.2

2 12

[PATCH OLK-5.10 0/3] fix CVE-2024-35839
by Zhengchao Shao 21 May '24

21 May '24

Fix CVE-2024-35839. Pavel Tikhomirov (3): netfilter: nfnetlink_log: use proper helper for fetching physinif netfilter: propagate net to nf_bridge_get_physindev netfilter: bridge: replace physindev with physinif in nf_bridge_info include/linux/netfilter_bridge.h | 6 ++-- include/linux/skbuff.h | 2 +- include/net/netfilter/nf_log.h | 2 +- net/bridge/br_netfilter_hooks.c | 41 +++++++++++++++++----- net/bridge/br_netfilter_ipv6.c | 14 +++++--- net/ipv4/netfilter/nf_log_arp.c | 2 +- net/ipv4/netfilter/nf_log_ipv4.c | 2 +- net/ipv4/netfilter/nf_reject_ipv4.c | 9 +++-- net/ipv6/netfilter/nf_log_ipv6.c | 2 +- net/ipv6/netfilter/nf_reject_ipv6.c | 11 ++++-- net/netfilter/ipset/ip_set_hash_netiface.c | 8 ++--- net/netfilter/nf_log_common.c | 5 +-- net/netfilter/nf_queue.c | 2 +- net/netfilter/nfnetlink_log.c | 8 ++--- net/netfilter/xt_physdev.c | 2 +- 15 files changed, 78 insertions(+), 38 deletions(-) -- 2.34.1

2 4

[PATCH OLK-5.10 0/3] arm64: Allow CPU0 to be nohz_full
by Xiongfeng Wang 21 May '24

21 May '24

Xiongfeng Wang (3): isolation: Do not check whether housekeeping CPUs are present isolation: Check whether all the housekeeping CPUs are online arm64: Kconfig: select ARCH_SUSPEND_NONZERO_CPU by default arch/arm64/Kconfig | 3 +++ include/linux/cpu.h | 3 ++- include/linux/sched/isolation.h | 5 +++++ kernel/sched/isolation.c | 39 +++++++++++++++++++++++++++++---- kernel/smp.c | 4 ++++ kernel/time/tick-sched.c | 3 ++- 6 files changed, 51 insertions(+), 6 deletions(-) -- 2.30.0

2 4

[PATCH v3 RESEND OLK-5.10 00/11] sync hulk-5.10 patches
by Yu Kuai 21 May '24

21 May '24

Changes in v3: - modify openeuler_defconfig for disabled new config Changes in v2: - fix head in commit message Three features related: - add a switch to enable hungtask check for io, patch 1-2 - add a config to control hierarchical throttle, patch 3-4 - support enable/disable blk-mq debugfs dynamically, patch 5-11 Christoph Hellwig (2): block: serialize all debugfs operations using q->debugfs_mutex block: remove per-disk debugfs files in blk_unregister_queue Yu Kuai (9): block: add a switch to enable hungtask check for io block: disable BLK_IO_HUNG_TASK_CHECK by default blk-throttle: add a config to control hierarchical throttle in cgroup v1 blk-throttle: fix missing prefix "CONFIG_" block: protect blk_mq_debugfs_register/unregister_hctx() with 'debugfs_mutex' block: shutdown blktrace in blk_release_queue() block: support enable/disable blk-mq debugfs dynamically block: fix kabi broken in struct request_queue block: support to disable debugfs by default arch/arm64/configs/openeuler_defconfig | 3 + arch/powerpc/configs/openeuler_defconfig | 2 + arch/x86/configs/openeuler_defconfig | 3 + block/Kconfig | 31 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 +++- block/blk-exec.c | 2 +- block/blk-mq-debugfs.c | 87 +++++++++++++++++++++--- block/blk-mq-debugfs.h | 5 -- block/blk-mq-sched.c | 11 +++ block/blk-mq.c | 12 ++++ block/blk-rq-qos.c | 2 - block/blk-rq-qos.h | 7 +- block/blk-sysfs.c | 82 ++++++++++++++++++---- block/blk-throttle.c | 17 ++++- block/blk.h | 1 + include/linux/blkdev.h | 8 ++- kernel/trace/blktrace.c | 3 - 18 files changed, 249 insertions(+), 42 deletions(-) -- 2.39.2

2 12

[PATCH openEuler-22.03-LTS 0/1] CVE-2023-52655
by Yongqiang Liu 21 May '24

21 May '24

Oliver Neukum (1): usb: aqc111: check packet for fixup for true limit drivers/net/usb/aqc111.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10 00/33] Port livepatch related patches
by Zheng Yejian 21 May '24

21 May '24

Link: https://gitee.com/openeuler/kernel/issues/I9R2TB Masami Hiramatsu (3): x86/unwind: Recover kretprobe trampoline entry x86/unwind: Compile kretprobe fixup code only if CONFIG_KRETPROBES=y arm64: Recover kretprobe modified return address in stacktrace Zheng Yejian (30): livepatch: Move 'struct klp_func_list' out of arch livepatch/x86: Move 'struct klp_func_list' related codes out of arch livepatch/arm: Remove duplicate 'struct klp_func_list' related codes livepatch/arm64: Remove duplicate 'struct klp_func_list' related codes livepatch/ppc32: Remove duplicate 'struct klp_func_list' related codes livepatch/ppc64: Remove duplicate 'struct klp_func_list' related codes livepatch/x86: Implement arch_klp_check_task_calltrace() livepatch/arm: Implement arch_klp_check_task_calltrace() livepatch/arm64: Implement arch_klp_check_task_calltrace() livepatch/ppc32: Implement arch_klp_check_task_calltrace() livepatch/ppc64: Implement arch_klp_check_task_calltrace() livepatch/x86: Ajust instruction replace order for KLP_STACK_OPTIMIZE mode livepatch/arm: Adjust instruction replace order for KLP_STACK_OPTIMIZE mode livepatch/arm64: Adjust instruction replace order for KLP_STACK_OPTIMIZE mode livepatch/ppc32: Adjust instruction replace order for KLP_STACK_OPTIMIZE mode livepatch/ppc64: Adjust instruction replace order for KLP_STACK_OPTIMIZE mode livepatch/core: No stop machine in KLP_STACK_OPTIMIZE mode livepatch: Complete check calltrace for running tasks livepatch: Check calltrace of idle tasks livepatch: Organize active functions with struct 'list_head' [Huawei] livepatch: Fix huge_depth in arch_klp_check_activeness_func() livepatch: Use func->func_node directly livepatch/core: Make several functions to be static livepatch: Fix warning C_RULE_ID_SINGLE_BRANCH_IF_AND_LOOP_BRACKET livepatch: Reduce duplicate definition of 'struct walk_stackframe_args' ftrace: Fix possible use-after-free issue in ftrace_location() kprobes: Fix possible use-after-free issue on kprobe registration livepatch: Avoid patching conflicts with kprobes kprobes: Add kretprobe_find_ret_addr() for searching return address livepatch: Enable CONFIG_LIVEPATCH_ISOLATE_KPROBE in openeuler_defconfig arch/arm/include/asm/livepatch.h | 6 - arch/arm/kernel/livepatch.c | 334 +++++------------ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/livepatch.h | 4 - arch/arm64/kernel/livepatch.c | 360 ++++++------------- arch/arm64/kernel/stacktrace.c | 4 + arch/powerpc/include/asm/livepatch.h | 6 +- arch/powerpc/kernel/livepatch.c | 22 ++ arch/powerpc/kernel/livepatch_32.c | 367 +++++-------------- arch/powerpc/kernel/livepatch_64.c | 435 ++++++++++------------- arch/powerpc/kernel/module_64.c | 29 +- arch/x86/configs/openeuler_defconfig | 1 + arch/x86/include/asm/livepatch.h | 5 - arch/x86/include/asm/unwind.h | 26 ++ arch/x86/kernel/livepatch.c | 320 ++++------------- arch/x86/kernel/unwind_frame.c | 3 +- arch/x86/kernel/unwind_guess.c | 3 +- arch/x86/kernel/unwind_orc.c | 21 +- include/linux/kprobes.h | 24 ++ include/linux/livepatch.h | 30 +- kernel/kprobes.c | 66 +++- kernel/livepatch/Kconfig | 25 ++ kernel/livepatch/core.c | 473 ++++++++++++++++++++++++- kernel/trace/ftrace.c | 39 +- 24 files changed, 1243 insertions(+), 1361 deletions(-) -- 2.25.1

2 34

[PATCH v3 OLK-5.10 00/11] sync hulk-5.10 patches
by Yu Kuai 21 May '24

21 May '24

Changes in v3: - modify openeuler_defconfig for disabled new config Changes in v2: - fix head in commit message Three features related: - add a switch to enable hungtask check for io, patch 1-2 - add a config to control hierarchical throttle, patch 3-4 - support enable/disable blk-mq debugfs dynamically, patch 5-11 Christoph Hellwig (2): block: serialize all debugfs operations using q->debugfs_mutex block: remove per-disk debugfs files in blk_unregister_queue Yu Kuai (9): block: add a switch to enable hungtask check for io block: disable BLK_IO_HUNG_TASK_CHECK by default blk-throttle: add a config to control hierarchical throttle in cgroup v1 blk-throttle: fix missing prefix "CONFIG_" block: protect blk_mq_debugfs_register/unregister_hctx() with 'debugfs_mutex' block: shutdown blktrace in blk_release_queue() block: support enable/disable blk-mq debugfs dynamically block: fix kabi broken in struct request_queue block: support to disable debugfs by default arch/arm64/configs/openeuler_defconfig | 3 + arch/powerpc/configs/openeuler_defconfig | 2 + arch/x86/configs/openeuler_defconfig | 3 + block/Kconfig | 31 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 +++- block/blk-exec.c | 2 +- block/blk-mq-debugfs.c | 87 +++++++++++++++++++++--- block/blk-mq-debugfs.h | 5 -- block/blk-mq-sched.c | 11 +++ block/blk-mq.c | 12 ++++ block/blk-rq-qos.c | 2 - block/blk-rq-qos.h | 7 +- block/blk-sysfs.c | 82 ++++++++++++++++++---- block/blk-throttle.c | 17 ++++- block/blk.h | 1 + include/linux/blkdev.h | 8 ++- kernel/trace/blktrace.c | 3 - 18 files changed, 249 insertions(+), 42 deletions(-) -- 2.39.2

2 12

[PATCH OLK-5.10 0/2] CVE-2024-35936
by Yifan Qiao 21 May '24

21 May '24

David Sterba (1): btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() Dominique Martinet (1): btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() fs/btrfs/volumes.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-35936
by Yifan Qiao 21 May '24

21 May '24

David Sterba (1): btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() Dominique Martinet (1): btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() fs/btrfs/volumes.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) -- 2.39.2

2 3

[openeuler:openEuler-1.0-LTS 21291/22450] drivers/spi/spi-phytium-plat.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 21 May '24

21 May '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 5708160127a606e51a136509cfe0a9448a09849a commit: e8483fcd43fc1dbb8d21bb7eacce804cbab6a7c6 [21291/22450] spi: add phytium spi support config: x86_64-buildonly-randconfig-004-20240521 (https://download.01.org/0day-ci/archive/20240521/202405211804.T84TVKIc-lkp@…) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240521/202405211804.T84TVKIc-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/202405211804.T84TVKIc-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/spi/spi-phytium-plat.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP2] bpf: Guard stack limits against 32bit overflow
by Pu Lehui 21 May '24

21 May '24

From: Andrei Matei <andreimatei1(a)gmail.com> mainline inclusion from mainline-v6.8-rc1 commit 1d38a9ee81570c4bd61f557832dead4d6f816760 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9EW CVE: CVE-2023-52676 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235f… [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235f… Reported-by: Andrii Nakryiko <andrii.nakryiko(a)gmail.com> Signed-off-by: Andrei Matei <andreimatei1(a)gmail.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20231207041150.229139-4-andreimatei1@gmail.com Conflicts: kernel/bpf/verifier.c [The conflict is because some modifications were merged by the commit 8f5863d230fed ("bpf: Fix accesses to uninit stack slots")] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index c781e753e9a9..b74fd334a2ca 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -3770,7 +3770,7 @@ static int check_stack_access_within_bounds( struct bpf_reg_state *regs = cur_regs(env); struct bpf_reg_state *reg = regs + regno; struct bpf_func_state *state = func(env, reg); - int min_off, max_off; + s64 min_off, max_off; int err; char *err_extra; @@ -3783,7 +3783,7 @@ static int check_stack_access_within_bounds( err_extra = " write to"; if (tnum_is_const(reg->var_off)) { - min_off = reg->var_off.value + off; + min_off = (s64)reg->var_off.value + off; max_off = min_off + access_size; } else { if (reg->smax_value >= BPF_MAX_VAR_OFF || -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] bpf: Guard stack limits against 32bit overflow
by Pu Lehui 21 May '24

21 May '24

From: Andrei Matei <andreimatei1(a)gmail.com> mainline inclusion from mainline-v6.8-rc1 commit 1d38a9ee81570c4bd61f557832dead4d6f816760 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9EW CVE: CVE-2023-52676 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235f… [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235f… Reported-by: Andrii Nakryiko <andrii.nakryiko(a)gmail.com> Signed-off-by: Andrei Matei <andreimatei1(a)gmail.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20231207041150.229139-4-andreimatei1@gmail.com Conflicts: kernel/bpf/verifier.c [The conflict is because some modifications were merged by the commit db2a27bb5398e ("bpf: Fix accesses to uninit stack slots")] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index d5706782be14..946e485a102c 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -3697,7 +3697,7 @@ static int check_stack_access_within_bounds( struct bpf_reg_state *regs = cur_regs(env); struct bpf_reg_state *reg = regs + regno; struct bpf_func_state *state = func(env, reg); - int min_off, max_off; + s64 min_off, max_off; int err; char *err_extra; @@ -3710,7 +3710,7 @@ static int check_stack_access_within_bounds( err_extra = " write to"; if (tnum_is_const(reg->var_off)) { - min_off = reg->var_off.value + off; + min_off = (s64)reg->var_off.value + off; max_off = min_off + access_size; } else { if (reg->smax_value >= BPF_MAX_VAR_OFF || -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS] bpf: Guard stack limits against 32bit overflow
by Pu Lehui 21 May '24

21 May '24

From: Andrei Matei <andreimatei1(a)gmail.com> mainline inclusion from mainline-v6.8-rc1 commit 1d38a9ee81570c4bd61f557832dead4d6f816760 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9EW CVE: CVE-2023-52676 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235f… [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235f… Reported-by: Andrii Nakryiko <andrii.nakryiko(a)gmail.com> Signed-off-by: Andrei Matei <andreimatei1(a)gmail.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Link: https://lore.kernel.org/bpf/20231207041150.229139-4-andreimatei1@gmail.com Conflicts: kernel/bpf/verifier.c [The conflict is because some modifications were merged by the commit f18a791ef88ed ("bpf: Fix accesses to uninit stack slots")] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 1b7e855962b8..222aa218f826 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -3696,7 +3696,7 @@ static int check_stack_access_within_bounds( struct bpf_reg_state *regs = cur_regs(env); struct bpf_reg_state *reg = regs + regno; struct bpf_func_state *state = func(env, reg); - int min_off, max_off; + s64 min_off, max_off; int err; char *err_extra; @@ -3709,7 +3709,7 @@ static int check_stack_access_within_bounds( err_extra = " write to"; if (tnum_is_const(reg->var_off)) { - min_off = reg->var_off.value + off; + min_off = (s64)reg->var_off.value + off; max_off = min_off + access_size; } else { if (reg->smax_value >= BPF_MAX_VAR_OFF || -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 V1] pmdomain: ti: Add a null pointer check to the omap_prm_domain_init
by Cheng Yu 21 May '24

21 May '24

From: Kunwu Chan <chentao(a)kylinos.cn> mainline inclusion from mainline-v6.9-rc1 commit 5d7f58ee08434a33340f75ac7ac5071eea9673b3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QGK5 CVE: CVE-2024-35943 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Signed-off-by: Kunwu Chan <chentao(a)kylinos.cn> Link: https://lore.kernel.org/r/20240118054257.200814-1-chentao@kylinos.cn Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Conflicts: drivers/soc/ti/omap_prm.c drivers/pmdomain/ti/omap_prm.c [This is a conflict caused by commit e2ad626f8f40("pmdomain: Rename the genpd subsystem to pmdomain") which is not merged.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/soc/ti/omap_prm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c index 4a782bfd753c..2ce8a8f4f005 100644 --- a/drivers/soc/ti/omap_prm.c +++ b/drivers/soc/ti/omap_prm.c @@ -381,6 +381,8 @@ static int omap_prm_domain_init(struct device *dev, struct omap_prm *prm) data = prm->data; name = devm_kasprintf(dev, GFP_KERNEL, "prm_%s", data->name); + if (!name) + return -ENOMEM; prmd->dev = dev; prmd->prm = prm; -- 2.25.1

2 1

[PATCH OLK-5.10 V1] pmdomain: ti: Add a null pointer check to the omap_prm_domain_init
by Cheng Yu 21 May '24

21 May '24

From: Kunwu Chan <chentao(a)kylinos.cn> mainline inclusion from mainline-v6.9-rc1 commit 5d7f58ee08434a33340f75ac7ac5071eea9673b3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QGK5 CVE: CVE-2024-35943 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Signed-off-by: Kunwu Chan <chentao(a)kylinos.cn> Link: https://lore.kernel.org/r/20240118054257.200814-1-chentao@kylinos.cn Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Conflicts: drivers/soc/ti/omap_prm.c drivers/pmdomain/ti/omap_prm.c [This is a conflict caused by commit e2ad626f8f40("pmdomain: Rename the genpd subsystem to pmdomain") which is not merged.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/soc/ti/omap_prm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c index 4a782bfd753c..2ce8a8f4f005 100644 --- a/drivers/soc/ti/omap_prm.c +++ b/drivers/soc/ti/omap_prm.c @@ -381,6 +381,8 @@ static int omap_prm_domain_init(struct device *dev, struct omap_prm *prm) data = prm->data; name = devm_kasprintf(dev, GFP_KERNEL, "prm_%s", data->name); + if (!name) + return -ENOMEM; prmd->dev = dev; prmd->prm = prm; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
by Yang Yingliang 21 May '24

21 May '24

From: Sergey Shtylyov <s.shtylyov(a)omp.ru> mainline inclusion from mainline-v6.7-rc2 commit 86222a8fc16ec517de8da2604d904c9df3a08e5d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9FV CVE: CVE-2023-52685 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return 64-bit value since persistent_ram_zone::buffer_size has type size_t which is derived from the 64-bit *unsigned long*, while the ecc_blocks variable this value gets assigned to has (always 32-bit) *int* type. Even if that value fits into *int* type, an overflow is still possible when calculating the size_t typed ecc_total variable further below since there's no cast to any 64-bit type before multiplication. Declaring the ecc_blocks variable as *size_t* should fix this mess... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 9cc05ad97c57 ("staging: android: persistent_ram: refactor ecc support") Signed-off-by: Sergey Shtylyov <s.shtylyov(a)omp.ru> Link: https://lore.kernel.org/r/20231105202936.25694-1-s.shtylyov@omp.ru Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/pstore/ram_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index a0fa3820ef2a..5ac9b1f155a8 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -190,7 +190,7 @@ static int persistent_ram_init_ecc(struct persistent_ram_zone *prz, { int numerr; struct persistent_ram_buffer *buffer = prz->buffer; - int ecc_blocks; + size_t ecc_blocks; size_t ecc_total; if (!ecc_info || !ecc_info->ecc_size) -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 767cbebf04ee..eb10a43b1498 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1558,7 +1558,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS] scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
by Li Lingfeng 21 May '24

21 May '24

From: Justin Tee <justin.tee(a)broadcom.com> stable inclusion from stable-v5.10.215 commit c473288f27d15014447de5a891bdf22a0695847a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QGLA CVE: CVE-2024-35930 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2ae917d4bcab80ab304b774d492e2fcd6c52c06b ] The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked. Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240131185112.149731-3-justintee8345@gmail.com Reviewed-by: Himanshu Madhani <himanshu.madhani(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/scsi/lpfc/lpfc_nportdisc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c b/drivers/scsi/lpfc/lpfc_nportdisc.c index 1e22364a31fc..d6287c58d504 100644 --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -784,8 +784,10 @@ lpfc_rcv_padisc(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp, /* Save the ELS cmd */ elsiocb->drvrTimeout = cmd; - lpfc_sli4_resume_rpi(ndlp, - lpfc_mbx_cmpl_resume_rpi, elsiocb); + if (lpfc_sli4_resume_rpi(ndlp, + lpfc_mbx_cmpl_resume_rpi, + elsiocb)) + kfree(elsiocb); goto out; } } -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
by Li Lingfeng 21 May '24

21 May '24

From: Justin Tee <justin.tee(a)broadcom.com> stable inclusion from stable-v5.10.215 commit c473288f27d15014447de5a891bdf22a0695847a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QGLA CVE: CVE-2024-35930 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2ae917d4bcab80ab304b774d492e2fcd6c52c06b ] The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked. Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240131185112.149731-3-justintee8345@gmail.com Reviewed-by: Himanshu Madhani <himanshu.madhani(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/scsi/lpfc/lpfc_nportdisc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c b/drivers/scsi/lpfc/lpfc_nportdisc.c index 3dfed191252c..22e336cb2284 100644 --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -601,8 +601,10 @@ lpfc_rcv_padisc(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp, /* Save the ELS cmd */ elsiocb->drvrTimeout = cmd; - lpfc_sli4_resume_rpi(ndlp, - lpfc_mbx_cmpl_resume_rpi, elsiocb); + if (lpfc_sli4_resume_rpi(ndlp, + lpfc_mbx_cmpl_resume_rpi, + elsiocb)) + kfree(elsiocb); goto out; } } -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS 0/1] CVE-2023-52669
by Yongqiang Liu 21 May '24

21 May '24

Herbert Xu (1): crypto: s390/aes - Fix buffer overread in CTR mode arch/s390/crypto/aes_s390.c | 5 +++-- arch/s390/crypto/paes_s390.c | 4 +++- 2 files changed, 6 insertions(+), 3 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP2] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 58980c6acbc8..b433d28b76a5 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1548,7 +1548,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, ext4_group_first_block_no(sb, 0), -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
by Li Zetao 21 May '24

21 May '24

From: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9R0VC Reference: https://lore.kernel.org/all/1716212077-43826-1-git-send-email-xiaojiangfeng… ---------------------------------------- When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: d0ffffe0 910003fd 91000000 9400000b (d4210000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: BRK handler: Fatal exception Fix this by always aligning the end of a bug_entry to 4 bytes, which is correct regardless of CONFIG_DEBUG_BUGVERBOSE. Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps") Signed-off-by: Yuanbin Xie <xieyuanbin1(a)huawei.com> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- arch/arm64/include/asm/asm-bug.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/asm-bug.h b/arch/arm64/include/asm/asm-bug.h index b3552c4a405f2..13a5abaac36bf 100644 --- a/arch/arm64/include/asm/asm-bug.h +++ b/arch/arm64/include/asm/asm-bug.h @@ -39,6 +39,7 @@ 14470: .long 14471f - 14470b; \ _BUGVERBOSE_LOCATION(__FILE__, __LINE__) \ .short flags; \ + .align 2; \ .popsection; \ 14471: #else -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP2 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP2] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 58980c6acbc8..b433d28b76a5 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1548,7 +1548,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 58980c6acbc8..b433d28b76a5 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1548,7 +1548,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 58980c6acbc8..b433d28b76a5 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1548,7 +1548,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] Bluetooth: af_bluetooth: Fix deadlock
by Li Huafei 21 May '24

21 May '24

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> mainline inclusion from mainline-v6.9-rc1 commit f7b94bdc1ec107c92262716b073b3e816d4784fb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK0R CVE: CVE-2024-26886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 2e07e8348ea4 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Conflicts: net/bluetooth/af_bluetooth.c [ The conflict occurred because commit f4b41f062c42 ("net: remove noblock parameter from skb_recv_datagram()") and b8ddc3b14c7a ("Bluetooth: fix indentation and alignment reported by checkpatch") were not merged. ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- net/bluetooth/af_bluetooth.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c index 363f85c617bbc..0bd7ad4e72dc6 100644 --- a/net/bluetooth/af_bluetooth.c +++ b/net/bluetooth/af_bluetooth.c @@ -263,14 +263,11 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, if (flags & MSG_OOB) return -EOPNOTSUPP; - lock_sock(sk); - skb = skb_recv_datagram(sk, flags, noblock, &err); if (!skb) { if (sk->sk_shutdown & RCV_SHUTDOWN) err = 0; - release_sock(sk); return err; } @@ -293,8 +290,6 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, skb_free_datagram(sk, skb); - release_sock(sk); - if (flags & MSG_TRUNC) copied = skblen; @@ -519,10 +514,11 @@ int bt_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg) if (sk->sk_state == BT_LISTEN) return -EINVAL; - lock_sock(sk); + spin_lock(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); amount = skb ? skb->len : 0; - release_sock(sk); + spin_unlock(&sk->sk_receive_queue.lock); + err = put_user(amount, (int __user *) arg); break; -- 2.25.1

2 1

[PATCH OLK-5.10] Bluetooth: af_bluetooth: Fix deadlock
by Li Huafei 21 May '24

21 May '24

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> mainline inclusion from mainline-v6.9-rc1 commit f7b94bdc1ec107c92262716b073b3e816d4784fb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK0R CVE: CVE-2024-26886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 2e07e8348ea4 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Conflicts: net/bluetooth/af_bluetooth.c [ The conflict occurred because commit f4b41f062c42 ("net: remove noblock parameter from skb_recv_datagram()") and b8ddc3b14c7a ("Bluetooth: fix indentation and alignment reported by checkpatch") were not merged. ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- net/bluetooth/af_bluetooth.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c index 14a917e70f3ee..bb648d2a14fbb 100644 --- a/net/bluetooth/af_bluetooth.c +++ b/net/bluetooth/af_bluetooth.c @@ -263,14 +263,11 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, if (flags & MSG_OOB) return -EOPNOTSUPP; - lock_sock(sk); - skb = skb_recv_datagram(sk, flags, noblock, &err); if (!skb) { if (sk->sk_shutdown & RCV_SHUTDOWN) err = 0; - release_sock(sk); return err; } @@ -296,8 +293,6 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, skb_free_datagram(sk, skb); - release_sock(sk); - if (flags & MSG_TRUNC) copied = skblen; @@ -520,10 +515,11 @@ int bt_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg) if (sk->sk_state == BT_LISTEN) return -EINVAL; - lock_sock(sk); + spin_lock(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); amount = skb ? skb->len : 0; - release_sock(sk); + spin_unlock(&sk->sk_receive_queue.lock); + err = put_user(amount, (int __user *) arg); break; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 767cbebf04ee..eb10a43b1498 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1558,7 +1558,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

1 0

[PATCH openEuler-22.03-LTS-SP2 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 0/1] CVE-2023-52669
by Yongqiang Liu 21 May '24

21 May '24

Herbert Xu (1): crypto: s390/aes - Fix buffer overread in CTR mode arch/s390/crypto/aes_s390.c | 5 +++-- arch/s390/crypto/paes_s390.c | 4 +++- 2 files changed, 6 insertions(+), 3 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP2] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 2d022055675c..9edc8da921f4 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1551,7 +1551,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t padding_blocks = meta_bg ? 0 : sbi->s_sbh->b_blocknr - ext4_group_first_block_no(sb, 0); sector_t old_gdb = 0; -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 2d022055675c..9edc8da921f4 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1551,7 +1551,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t padding_blocks = meta_bg ? 0 : sbi->s_sbh->b_blocknr - ext4_group_first_block_no(sb, 0); sector_t old_gdb = 0; -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 2d022055675c..9edc8da921f4 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1551,7 +1551,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t padding_blocks = meta_bg ? 0 : sbi->s_sbh->b_blocknr - ext4_group_first_block_no(sb, 0); sector_t old_gdb = 0; -- 2.31.1

2 1

[PATCH OLK-5.10] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 2d022055675c..9edc8da921f4 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1551,7 +1551,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t padding_blocks = meta_bg ? 0 : sbi->s_sbh->b_blocknr - ext4_group_first_block_no(sb, 0); sector_t old_gdb = 0; -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
by Li Zetao 21 May '24

21 May '24

From: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: NA Reference: https://lore.kernel.org/all/1716212077-43826-1-git-send-email-xiaojiangfeng… ---------------------------------------- When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: d0ffffe0 910003fd 91000000 9400000b (d4210000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: BRK handler: Fatal exception Fix this by always aligning the end of a bug_entry to 4 bytes, which is correct regardless of CONFIG_DEBUG_BUGVERBOSE. Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps") Signed-off-by: Yuanbin Xie <xieyuanbin1(a)huawei.com> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- arch/arm64/include/asm/asm-bug.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/asm-bug.h b/arch/arm64/include/asm/asm-bug.h index b3552c4a405f2..13a5abaac36bf 100644 --- a/arch/arm64/include/asm/asm-bug.h +++ b/arch/arm64/include/asm/asm-bug.h @@ -39,6 +39,7 @@ 14470: .long 14471f - 14470b; \ _BUGVERBOSE_LOCATION(__FILE__, __LINE__) \ .short flags; \ + .align 2; \ .popsection; \ 14471: #else -- 2.34.1

2 1

[PATCH OLK-5.10] dm snapshot: fix lockup in dm_exception_table_exit
by Li Lingfeng 21 May '24

21 May '24

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.4.274 commit e7d4cff57c3c43fdd72342c78d4138f509c7416e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CC CVE: CVE-2024-35805 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc ] There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions. Reported-by: John Pittman <jpittman(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/dm-snap.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c index 41735a25d50a..de73fe79640f 100644 --- a/drivers/md/dm-snap.c +++ b/drivers/md/dm-snap.c @@ -685,8 +685,10 @@ static void dm_exception_table_exit(struct dm_exception_table *et, for (i = 0; i < size; i++) { slot = et->table + i; - hlist_bl_for_each_entry_safe(ex, pos, n, slot, hash_list) + hlist_bl_for_each_entry_safe(ex, pos, n, slot, hash_list) { kmem_cache_free(mem, ex); + cond_resched(); + } } vfree(et->table); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/amdgpu: Skip do PCI error slot reset during RAS recovery
by Liu Chuang 21 May '24

21 May '24

From: "Stanley.Yang" <Stanley.Yang(a)amd.com> mainline inclusion from mainline-v6.9-rc1 commit 601429cca96b4af3be44172c3b64e4228515dbe1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QGL7 CVE: CVE-2024-26969 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Why: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered [ 557.610492] [drm] PCI error: slot reset callback!! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023 [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202 [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000 [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Call Trace: [ 560.849225] <TASK> [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [ 560.872293] ? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [ 560.885532] ? asm_exc_general_protection+0x27/0x30 [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] process_one_work+0x228/0x3d0 How: In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure. Signed-off-by: Stanley.Yang <Stanley.Yang(a)amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Conflicts: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index bde0496d2f15..177d70b70471 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -4995,6 +4995,20 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev *pdev) bool need_full_reset = true; u32 memsize; struct list_head device_list; + struct amdgpu_hive_info *hive; + int hive_ras_recovery = 0; + struct amdgpu_ras *ras; + + /* PCI error slot reset should be skipped During RAS recovery */ + hive = amdgpu_get_xgmi_hive(adev); + if (hive) { + hive_ras_recovery = atomic_read(&hive->ras_recovery); + amdgpu_put_xgmi_hive(hive); + } + ras = amdgpu_ras_get_context(adev); + if ((amdgpu_ip_version(adev, GC_HWIP, 0) == IP_VERSION(9, 4, 3)) && + ras && (atomic_read(&ras->in_recovery) || hive_ras_recovery)) + return PCI_ERS_RESULT_RECOVERED; DRM_INFO("PCI error: slot reset callback!!\n"); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] dm snapshot: fix lockup in dm_exception_table_exit
by Li Lingfeng 21 May '24

21 May '24

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v5.4.274 commit e7d4cff57c3c43fdd72342c78d4138f509c7416e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CC CVE: CVE-2024-35805 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc ] There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions. Reported-by: John Pittman <jpittman(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/md/dm-snap.c [Commit f79ae415b64c change the way to traverse exception] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/dm-snap.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c index 52101e5c7258..ad65b4a8464d 100644 --- a/drivers/md/dm-snap.c +++ b/drivers/md/dm-snap.c @@ -650,8 +650,10 @@ static void dm_exception_table_exit(struct dm_exception_table *et, for (i = 0; i < size; i++) { slot = et->table + i; - list_for_each_entry_safe (ex, next, slot, hash_list) + list_for_each_entry_safe (ex, next, slot, hash_list) { kmem_cache_free(mem, ex); + cond_resched(); + } } vfree(et->table); -- 2.31.1

2 1

[PATCH OLK-5.10 0/3] xfs: three bug fix recently
by Long Li 21 May '24

21 May '24

This patch set fix three bug: Jiachen Zhang (1): xfs: ensure logflagsp is initialized in xfs_bmap_del_extent_real Long Li (1): iomap: fix warning in xfs_iomap_write_delalloc_release() Zhang Tianci (1): xfs: update dir3 leaf block metadata after swap fs/xfs/libxfs/xfs_bmap.c | 76 +++++++++++++++--------------------- fs/xfs/libxfs/xfs_da_btree.c | 7 ++++ fs/xfs/xfs_iomap.c | 2 +- 3 files changed, 40 insertions(+), 45 deletions(-) -- 2.31.1

2 4

[PATCH OLK-5.10] [Huawei] bpf: tcp: fix compilation fails during resolve_btfids when pahole version < 12
by Luo Gengkun 21 May '24

21 May '24

From: Yang Jihong <yangjihong1(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9QZ7Q ------------------------------- commit 63695db417a9 ("[Backport] bpf: tcp: Put some tcp cong functions in allowlist for bpf-tcp-cc") puts some tcp cong helper functions, into the allowlist for the bpf-tcp-cc program. The pahole version must be later than 1.21 (see [1]). Otherwise, compilation fails: LD .tmp_vmlinux.kallsyms1 KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux BTFIDS vmlinux FAILED unresolved symbol cubictcp_state make: *** [Makefile:1191: vmlinux] Error 255 The actual pahole version we use is 1.17, add pahole verion flags to move out functions. [1]: https://lore.kernel.org/dwarves/20210506015824.2335125-1-kafai@fb.com/ Fixes: e78aea8b2170 ("bpf: tcp: Put some tcp cong functions in allowlist for bpf-tcp-cc") Signed-off-by: Yang Jihong <yangjihong1(a)huawei.com> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- net/ipv4/bpf_tcp_ca.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv4/bpf_tcp_ca.c b/net/ipv4/bpf_tcp_ca.c index 575245276f76..94863facecd7 100644 --- a/net/ipv4/bpf_tcp_ca.c +++ b/net/ipv4/bpf_tcp_ca.c @@ -187,6 +187,7 @@ BTF_ID(func, tcp_slow_start) BTF_ID(func, tcp_cong_avoid_ai) #ifdef CONFIG_X86 #ifdef CONFIG_DYNAMIC_FTRACE +#if CONFIG_PAHOLE_VERSION >= 120 #if IS_BUILTIN(CONFIG_TCP_CONG_CUBIC) BTF_ID(func, cubictcp_init) BTF_ID(func, cubictcp_recalc_ssthresh) @@ -213,6 +214,7 @@ BTF_ID(func, bbr_ssthresh) BTF_ID(func, bbr_min_tso_segs) BTF_ID(func, bbr_set_state) #endif +#endif /* CONFIG_PAHOLE_VERSION */ #endif /* CONFIG_DYNAMIC_FTRACE */ #endif /* CONFIG_X86 */ BTF_SET_END(bpf_tcp_ca_check_kfunc_ids) -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP2 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/2] CVE-2024-35936
by Yifan Qiao 21 May '24

21 May '24

David Sterba (1): btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() Dominique Martinet (1): btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() fs/btrfs/volumes.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) -- 2.39.2

2 3