- Kernel - mailweb.openeuler.org

[openeuler:openEuler-1.0-LTS 17447/23564] block/.tmp_blk-mq.o: warning: objtool: blk_mq_unfreeze_queue()+0x75: unreachable instruction
by kernel test robot 28 Aug '24

28 Aug '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 73a86ad60aabf460a4c8a0f96a1b2ddb98522fd8 commit: cbd9fe6e727ed12c1e542f74514e6dd4419f1cf6 [17447/23564] blk-mq: fix hang caused by freeze/unfreeze sequence config: x86_64-buildonly-randconfig-004-20240825 (https://download.01.org/0day-ci/archive/20240828/202408280826.MupKFjBW-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/20240828/202408280826.MupKFjBW-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/202408280826.MupKFjBW-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from block/blk-mq.c:9: In file included from include/linux/backing-dev.h:15: In file included from include/linux/blkdev.h:16: include/linux/pagemap.h:425:21: warning: cast from 'int (*)(struct file *, struct page *)' to 'filler_t *' (aka 'int (*)(void *, struct page *)') converts to incompatible function type [-Wcast-function-type-strict] 425 | filler_t *filler = (filler_t *)mapping->a_ops->readpage; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block/blk-mq.c:600:44: warning: passing 8-byte aligned argument to 32-byte aligned parameter 2 of 'smp_call_function_single_async' may result in an unaligned pointer access [-Walign-mismatch] 600 | smp_call_function_single_async(ctx->cpu, &rq->csd); | ^ 2 warnings generated. >> block/.tmp_blk-mq.o: warning: objtool: blk_mq_unfreeze_queue()+0x75: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 26811/30000] include/linux/backing-dev.h:418:49: warning: declaration of 'struct cgroup_subsys' will not be visible outside of this function
by kernel test robot 28 Aug '24

28 Aug '24

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: b32a887db4e5c4c061e61977efabbc1d5e867aa7 commit: 13e5c52d7cec7621f78bce452b78785e689ed0b2 [26811/30000] cgroup_writeback: bind blkcg and memcg config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20240828/202408280725.RGVxlJvi-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/20240828/202408280725.RGVxlJvi-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/202408280725.RGVxlJvi-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from kernel/sysctl.c:54: In file included from include/linux/nfs_fs.h:31: In file included from include/linux/sunrpc/auth.h:13: In file included from include/linux/sunrpc/sched.h:19: include/linux/sunrpc/xdr.h:606:10: warning: result of comparison of constant 4611686018427387903 with expression of type '__u32' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare] 606 | if (len > SIZE_MAX / sizeof(*p)) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~ In file included from kernel/sysctl.c:54: In file included from include/linux/nfs_fs.h:39: In file included from include/linux/nfs_fs_sb.h:6: >> include/linux/backing-dev.h:418:49: warning: declaration of 'struct cgroup_subsys' will not be visible outside of this function [-Wvisibility] 418 | static inline void bind_memcg_blkcg_link(struct cgroup_subsys *ss, | ^ 2 warnings generated. vim +418 include/linux/backing-dev.h 417 > 418 static inline void bind_memcg_blkcg_link(struct cgroup_subsys *ss, 419 struct css_set *cset) 420 { 421 } 422 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 26549/30000] kernel/static_call_inline.c:458:5: warning: no previous prototype for 'klp_static_call_register'
by kernel test robot 28 Aug '24

28 Aug '24

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: b32a887db4e5c4c061e61977efabbc1d5e867aa7 commit: 581f41f797bd88092689c43c47ee06a8ab2eec7f [26549/30000] static_call: Don't make __static_call_return0 static config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20240828/202408280714.V3WjAG3t-lkp@…) compiler: gcc-11 (Debian 11.3.0-12) 11.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240828/202408280714.V3WjAG3t-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/202408280714.V3WjAG3t-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/static_call_inline.c:458:5: warning: no previous prototype for 'klp_static_call_register' [-Wmissing-prototypes] 458 | int klp_static_call_register(struct module *mod) | ^~~~~~~~~~~~~~~~~~~~~~~~ vim +/klp_static_call_register +458 kernel/static_call_inline.c 457 > 458 int klp_static_call_register(struct module *mod) 459 { 460 int ret; 461 462 ret = static_call_module_notify(&static_call_module_nb, MODULE_STATE_COMING, mod); 463 return notifier_to_errno(ret); 464 } 465 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 26811/30000] include/linux/backing-dev.h:418:49: warning: 'struct cgroup_subsys' declared inside parameter list will not be visible outside of this definition or declaration
by kernel test robot 28 Aug '24

28 Aug '24

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: b32a887db4e5c4c061e61977efabbc1d5e867aa7 commit: 13e5c52d7cec7621f78bce452b78785e689ed0b2 [26811/30000] cgroup_writeback: bind blkcg and memcg config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20240828/202408280630.Xx6ILcbO-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240828/202408280630.Xx6ILcbO-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/202408280630.Xx6ILcbO-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from include/linux/nfs_fs_sb.h:6, from include/linux/nfs_fs.h:39, from init/do_mounts.c:23: >> include/linux/backing-dev.h:418:49: warning: 'struct cgroup_subsys' declared inside parameter list will not be visible outside of this definition or declaration 418 | static inline void bind_memcg_blkcg_link(struct cgroup_subsys *ss, | ^~~~~~~~~~~~~ vim +418 include/linux/backing-dev.h 417 > 418 static inline void bind_memcg_blkcg_link(struct cgroup_subsys *ss, 419 struct css_set *cset) 420 { 421 } 422 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 26549/30000] kernel/static_call_inline.c:468:5: warning: no previous prototype for function 'klp_static_call_register'
by kernel test robot 28 Aug '24

28 Aug '24

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: b32a887db4e5c4c061e61977efabbc1d5e867aa7 commit: 581f41f797bd88092689c43c47ee06a8ab2eec7f [26549/30000] static_call: Don't make __static_call_return0 static config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20240828/202408280504.viXVjhyZ-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/20240828/202408280504.viXVjhyZ-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/202408280504.viXVjhyZ-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/static_call_inline.c:468:5: warning: no previous prototype for function 'klp_static_call_register' [-Wmissing-prototypes] 468 | int klp_static_call_register(struct module *mod) | ^ kernel/static_call_inline.c:468:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 468 | int klp_static_call_register(struct module *mod) | ^ | static 1 warning generated. vim +/klp_static_call_register +468 kernel/static_call_inline.c 467 > 468 int klp_static_call_register(struct module *mod) 469 { 470 return 0; 471 } 472 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 73a86ad60aabf460a4c8a0f96a1b2ddb98522fd8
by kernel test robot 28 Aug '24

28 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 73a86ad60aabf460a4c8a0f96a1b2ddb98522fd8 !11150 protect the fetch of ->fd[fd elapsed time: 757m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240828 gcc-14.1.0 arm64 randconfig-002-20240828 gcc-14.1.0 arm64 randconfig-003-20240828 gcc-14.1.0 arm64 randconfig-004-20240828 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240827 clang-18 x86_64 buildonly-randconfig-002-20240827 gcc-12 x86_64 buildonly-randconfig-003-20240827 gcc-12 x86_64 buildonly-randconfig-004-20240827 gcc-12 x86_64 buildonly-randconfig-005-20240827 clang-18 x86_64 buildonly-randconfig-006-20240827 gcc-12 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240827 clang-18 x86_64 randconfig-002-20240827 gcc-12 x86_64 randconfig-003-20240827 gcc-12 x86_64 randconfig-004-20240827 gcc-12 x86_64 randconfig-005-20240827 clang-18 x86_64 randconfig-006-20240827 gcc-12 x86_64 randconfig-011-20240827 gcc-12 x86_64 randconfig-012-20240827 gcc-12 x86_64 randconfig-013-20240827 gcc-12 x86_64 randconfig-014-20240827 clang-18 x86_64 randconfig-015-20240827 gcc-12 x86_64 randconfig-016-20240827 gcc-12 x86_64 randconfig-071-20240827 gcc-12 x86_64 randconfig-072-20240827 gcc-11 x86_64 randconfig-073-20240827 gcc-12 x86_64 randconfig-074-20240827 gcc-12 x86_64 randconfig-075-20240827 clang-18 x86_64 randconfig-076-20240827 gcc-12 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 17249/23564] kernel/.tmp_kprobes.o: warning: objtool: register_kprobe()+0x6d4: unreachable instruction
by kernel test robot 28 Aug '24

28 Aug '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 73a86ad60aabf460a4c8a0f96a1b2ddb98522fd8 commit: 388c9a84a807812e7226e0e1ca606563e14a7f5a [17249/23564] kprobes: Warn if the kprobe is reregistered config: x86_64-buildonly-randconfig-004-20240825 (https://download.01.org/0day-ci/archive/20240828/202408280332.EuYU3ttl-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/20240828/202408280332.EuYU3ttl-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/202408280332.EuYU3ttl-lkp@intel.com/ All warnings (new ones prefixed by >>): kernel/kprobes.c:120:14: warning: no previous prototype for function 'alloc_insn_page' [-Wmissing-prototypes] 120 | void __weak *alloc_insn_page(void) | ^ kernel/kprobes.c:120:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 120 | void __weak *alloc_insn_page(void) | ^ | static kernel/kprobes.c:125:13: warning: no previous prototype for function 'free_insn_page' [-Wmissing-prototypes] 125 | void __weak free_insn_page(void *page) | ^ kernel/kprobes.c:125:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 125 | void __weak free_insn_page(void *page) | ^ | static 2 warnings generated. kernel/kprobes.c:145: warning: Function parameter or member 'c' not described in '__get_insn_slot' >> kernel/.tmp_kprobes.o: warning: objtool: register_kprobe()+0x6d4: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] jfs: Fix shift-out-of-bounds in dbDiscardAG
by GONG Ruiqi 27 Aug '24

27 Aug '24

From: Pei Li <peili.dev(a)gmail.com> mainline inclusion from mainline-v6.11-rc1 commit 7063b80268e2593e58bee8a8d709c2f3ff93e2f2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMMML CVE: CVE-2024-44938 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative. This patch fixes the issue by exiting the loop directly when negative shift is found. Reported-by: syzbot+61be3359d2ee3467e7e4(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=61be3359d2ee3467e7e4 Signed-off-by: Pei Li <peili.dev(a)gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> Conflicts: fs/jfs/jfs_dmap.c [Just context conflicts: 1 vs 1LL at the next line.] Signed-off-by: GONG Ruiqi <gongruiqi1(a)huawei.com> --- fs/jfs/jfs_dmap.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c index bd69bc08222f..2b3df1704d23 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c @@ -1700,6 +1700,8 @@ s64 dbDiscardAG(struct inode *ip, int agno, s64 minlen) } else if (rc == -ENOSPC) { /* search for next smaller log2 block */ l2nb = BLKSTOL2(nblocks) - 1; + if (unlikely(l2nb < 0)) + break; nblocks = 1 << l2nb; } else { /* Trim any already allocated blocks */ -- 2.25.1

2 1

[openeuler:OLK-6.6] BUILD REGRESSION e65c0786c5c765daf978c13bfe587f5426745bc7
by kernel test robot 27 Aug '24

27 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: e65c0786c5c765daf978c13bfe587f5426745bc7 !11156 v3 Fix CVE-2024-43869 Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | |-- arch-arm64-kernel-virtcca_cvm_tsi.c:warning:variable-ver-is-uninitialized-when-used-here | |-- arch-arm64-kvm-arm.c:warning:variable-r-is-used-uninitialized-whenever-if-condition-is-false | |-- arch-arm64-kvm-tmi.c:warning:no-previous-prototype-for-function-tmi_tmm_inf_test | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_create_ttt_levels | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_get_num_brps | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_get_num_wrps | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_ipa_limit | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_populate_par_region | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_supports_pmu | `-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_supports_sve |-- x86_64-buildonly-randconfig-001-20240827 | `-- kernel-sched-isolation.c:error:use-of-undeclared-identifier-setup_max_cpus |-- x86_64-buildonly-randconfig-002-20240827 | `-- kernel-sched-isolation.c:error:setup_max_cpus-undeclared-(first-use-in-this-function) `-- x86_64-buildonly-randconfig-003-20240827 `-- kernel-sched-isolation.c:error:setup_max_cpus-undeclared-(first-use-in-this-function) elapsed time: 736m configs tested: 28 configs skipped: 122 tested configs: arm64 allmodconfig clang-20 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240827 gcc-14.1.0 arm64 randconfig-002-20240827 clang-14 arm64 randconfig-003-20240827 clang-14 arm64 randconfig-004-20240827 clang-20 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch randconfig-001-20240827 gcc-14.1.0 loongarch randconfig-002-20240827 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240827 clang-18 x86_64 buildonly-randconfig-002-20240827 gcc-12 x86_64 buildonly-randconfig-003-20240827 gcc-12 x86_64 buildonly-randconfig-004-20240827 gcc-12 x86_64 buildonly-randconfig-005-20240827 clang-18 x86_64 buildonly-randconfig-006-20240827 gcc-12 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240827 clang-18 x86_64 randconfig-002-20240827 gcc-12 x86_64 randconfig-003-20240827 gcc-12 x86_64 randconfig-004-20240827 gcc-12 x86_64 randconfig-005-20240827 clang-18 x86_64 randconfig-006-20240827 gcc-12 x86_64 randconfig-011-20240827 gcc-12 x86_64 randconfig-012-20240827 gcc-12 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10 0/4] kprobe support %pd/%pD type
by Ye Bin 27 Aug '24

27 Aug '24

Ye Bin (4): tracing/probes: support '%pd' type for print struct dentry's name tracing/probes: support '%pD' type for print struct file's name Documentation: tracing: add new type '%pd' and '%pD' for kprobe selftests/ftrace: add kprobe test cases for VFS type "%pd" and "%pD" Documentation/trace/kprobetrace.rst | 7 +- kernel/trace/trace.c | 2 +- kernel/trace/trace_kprobe.c | 6 ++ kernel/trace/trace_probe.c | 64 +++++++++++++++++++ kernel/trace/trace_probe.h | 2 + .../ftrace/test.d/kprobe/kprobe_args_vfs.tc | 40 ++++++++++++ 6 files changed, 118 insertions(+), 3 deletions(-) create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_vfs.tc -- 2.34.1

2 5

[PATCH OLK-6.6 0/6] kprobe support %pd/%pD type
by Ye Bin 27 Aug '24

27 Aug '24

Masami Hiramatsu (Google) (1): selftests/ftrace: Fix required features for VFS type test case Ye Bin (5): tracing/probes: support '%pd' type for print struct dentry's name tracing/probes: support '%pD' type for print struct file's name Documentation: tracing: add new type '%pd' and '%pD' for kprobe selftests/ftrace: add kprobe test cases for VFS type "%pd" and "%pD" selftests/ftrace: add fprobe test cases for VFS type "%pd" and "%pD" Documentation/trace/kprobetrace.rst | 6 +- kernel/trace/trace.c | 2 +- kernel/trace/trace_fprobe.c | 6 ++ kernel/trace/trace_kprobe.c | 6 ++ kernel/trace/trace_probe.c | 63 +++++++++++++++++++ kernel/trace/trace_probe.h | 2 + .../ftrace/test.d/dynevent/fprobe_args_vfs.tc | 41 ++++++++++++ .../ftrace/test.d/kprobe/kprobe_args_vfs.tc | 40 ++++++++++++ 8 files changed, 164 insertions(+), 2 deletions(-) create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/fprobe_args_vfs.tc create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_vfs.tc -- 2.34.1

2 7

[PATCH OLK-5.10] ksmbd: discard write access to the directory open
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Hobin Woo <hobin.woo(a)samsung.com> mainline inclusion from mainline-v6.10-rc7 commit e2e33caa5dc2eae7bddf88b22ce11ec3d760e5cd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGELQ CVE: CVE-2024-41030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- may_open() does not allow a directory to be opened with the write access. However, some writing flags set by client result in adding write access on server, making ksmbd incompatible with FUSE file system. Simply, let's discard the write access when opening a directory. list_add corruption. next is NULL. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:26! pc : __list_add_valid+0x88/0xbc lr : __list_add_valid+0x88/0xbc Call trace: __list_add_valid+0x88/0xbc fuse_finish_open+0x11c/0x170 fuse_open_common+0x284/0x5e8 fuse_dir_open+0x14/0x24 do_dentry_open+0x2a4/0x4e0 dentry_open+0x50/0x80 smb2_open+0xbe4/0x15a4 handle_ksmbd_work+0x478/0x5ec process_one_work+0x1b4/0x448 worker_thread+0x25c/0x430 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20 Cc: stable(a)vger.kernel.org Signed-off-by: Yoonho Shin <yoonho.shin(a)samsung.com> Signed-off-by: Hobin Woo <hobin.woo(a)samsung.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/smb/server/smb2pdu.c fs/ksmbd/smb2pdu.c [lc:file path is not same] Signed-off-by: XiongWei Yang <yangxiongwei6(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index 50ef53115cab..feec18445829 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -2043,15 +2043,22 @@ int smb2_tree_connect(struct ksmbd_work *work) * @access: file access flags * @disposition: file disposition flags * @may_flags: set with MAY_ flags + * @is_dir: is creating open flags for directory * * Return: file open flags */ static int smb2_create_open_flags(bool file_present, __le32 access, __le32 disposition, - int *may_flags) + int *may_flags, + bool is_dir) { int oflags = O_NONBLOCK | O_LARGEFILE; + if (is_dir) { + access &= ~FILE_WRITE_DESIRE_ACCESS_LE; + ksmbd_debug(SMB, "Discard write access to a directory\n"); + } + if (access & FILE_READ_DESIRED_ACCESS_LE && access & FILE_WRITE_DESIRE_ACCESS_LE) { oflags |= O_RDWR; @@ -2891,7 +2898,9 @@ int smb2_open(struct ksmbd_work *work) open_flags = smb2_create_open_flags(file_present, daccess, req->CreateDisposition, - &may_flags); + &may_flags, + req->CreateOptions & FILE_DIRECTORY_FILE_LE || + (file_present && S_ISDIR(d_inode(path.dentry)->i_mode))); if (!test_tree_conn_flag(tcon, KSMBD_TREE_CONN_FLAG_WRITABLE)) { if (open_flags & O_CREAT) { -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ksmbd: discard write access to the directory open
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Hobin Woo <hobin.woo(a)samsung.com> mainline inclusion from mainline-v6.10-rc7 commit e2e33caa5dc2eae7bddf88b22ce11ec3d760e5cd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGELQ CVE: CVE-2024-41030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- may_open() does not allow a directory to be opened with the write access. However, some writing flags set by client result in adding write access on server, making ksmbd incompatible with FUSE file system. Simply, let's discard the write access when opening a directory. list_add corruption. next is NULL. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:26! pc : __list_add_valid+0x88/0xbc lr : __list_add_valid+0x88/0xbc Call trace: __list_add_valid+0x88/0xbc fuse_finish_open+0x11c/0x170 fuse_open_common+0x284/0x5e8 fuse_dir_open+0x14/0x24 do_dentry_open+0x2a4/0x4e0 dentry_open+0x50/0x80 smb2_open+0xbe4/0x15a4 handle_ksmbd_work+0x478/0x5ec process_one_work+0x1b4/0x448 worker_thread+0x25c/0x430 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20 Cc: stable(a)vger.kernel.org Signed-off-by: Yoonho Shin <yoonho.shin(a)samsung.com> Signed-off-by: Hobin Woo <hobin.woo(a)samsung.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/smb/server/smb2pdu.c fs/ksmbd/smb2pdu.c [lc:file path is not same] Signed-off-by: XiongWei Yang <yangxiongwei6(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index 50ef53115cab..feec18445829 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -2043,15 +2043,22 @@ int smb2_tree_connect(struct ksmbd_work *work) * @access: file access flags * @disposition: file disposition flags * @may_flags: set with MAY_ flags + * @is_dir: is creating open flags for directory * * Return: file open flags */ static int smb2_create_open_flags(bool file_present, __le32 access, __le32 disposition, - int *may_flags) + int *may_flags, + bool is_dir) { int oflags = O_NONBLOCK | O_LARGEFILE; + if (is_dir) { + access &= ~FILE_WRITE_DESIRE_ACCESS_LE; + ksmbd_debug(SMB, "Discard write access to a directory\n"); + } + if (access & FILE_READ_DESIRED_ACCESS_LE && access & FILE_WRITE_DESIRE_ACCESS_LE) { oflags |= O_RDWR; @@ -2891,7 +2898,9 @@ int smb2_open(struct ksmbd_work *work) open_flags = smb2_create_open_flags(file_present, daccess, req->CreateDisposition, - &may_flags); + &may_flags, + req->CreateOptions & FILE_DIRECTORY_FILE_LE || + (file_present && S_ISDIR(d_inode(path.dentry)->i_mode))); if (!test_tree_conn_flag(tcon, KSMBD_TREE_CONN_FLAG_WRITABLE)) { if (open_flags & O_CREAT) { -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drivers: core: synchronize really_probe() and dev_uevent()
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Dirk Behme <dirk.behme(a)de.bosch.com> mainline inclusion from mainline-v6.10-rc4 commit c0a40097f0bc81deafc15f9195d1fb54595cd6d0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACSAA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization: Thread #1: ========== really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... } Thread #2: ========== dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... } really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Similar cases are reported by syzkaller in https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a But these are regarding the *initialization* of dev->driver dev->driver = drv; As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though). The same issue was reported and tried to be fixed back in 2015 in https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@sam… already. Fixes: 239378f16aa1 ("Driver core: add uevent vars for devices of a class") Cc: stable <stable(a)kernel.org> Cc: syzbot+ffa8143439596313a85a(a)syzkaller.appspotmail.com Cc: Ashish Sangwan <a.sangwan(a)samsung.com> Cc: Namjae Jeon <namjae.jeon(a)samsung.com> Signed-off-by: Dirk Behme <dirk.behme(a)de.bosch.com> Link: https://lore.kernel.org/r/20240513050634.3964461-1-dirk.behme@de.bosch.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/base/core.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- drivers/base/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 1070e1bb501f..fcb5daf6604d 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2006,8 +2006,11 @@ static ssize_t uevent_show(struct device *dev, struct device_attribute *attr, if (!env) return -ENOMEM; + /* Synchronize with really_probe() */ + device_lock(dev); /* let the kset specific function add its keys */ retval = kset->uevent_ops->uevent(kset, &dev->kobj, env); + device_unlock(dev); if (retval) goto out; -- 2.17.1

2 1

[PATCH OLK-5.10] drivers: core: synchronize really_probe() and dev_uevent()
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Dirk Behme <dirk.behme(a)de.bosch.com> mainline inclusion from mainline-v6.10-rc4 commit c0a40097f0bc81deafc15f9195d1fb54595cd6d0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACSAA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization: Thread #1: ========== really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... } Thread #2: ========== dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... } really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Similar cases are reported by syzkaller in https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a But these are regarding the *initialization* of dev->driver dev->driver = drv; As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though). The same issue was reported and tried to be fixed back in 2015 in https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@sam… already. Fixes: 239378f16aa1 ("Driver core: add uevent vars for devices of a class") Cc: stable <stable(a)kernel.org> Cc: syzbot+ffa8143439596313a85a(a)syzkaller.appspotmail.com Cc: Ashish Sangwan <a.sangwan(a)samsung.com> Cc: Namjae Jeon <namjae.jeon(a)samsung.com> Signed-off-by: Dirk Behme <dirk.behme(a)de.bosch.com> Link: https://lore.kernel.org/r/20240513050634.3964461-1-dirk.behme@de.bosch.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/base/core.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- drivers/base/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 82b50a89cedc..a5ff2a88bbeb 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2041,8 +2041,11 @@ static ssize_t uevent_show(struct device *dev, struct device_attribute *attr, if (!env) return -ENOMEM; + /* Synchronize with really_probe() */ + device_lock(dev); /* let the kset specific function add its keys */ retval = kset->uevent_ops->uevent(kset, &dev->kobj, env); + device_unlock(dev); if (retval) goto out; -- 2.17.1

2 1

[PATCH OLK-5.10] ibmvnic: don't release napi in __ibmvnic_open()
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Sukadev Bhattiprolu <sukadev(a)linux.ibm.com> mainline inclusion from mainline-v5.17-rc4 commit 61772b0908c640d0309c40f7d41d062ca4e979fa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADGL6 CVE: CVE-2022-48811 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If __ibmvnic_open() encounters an error such as when setting link state, it calls release_resources() which frees the napi structures needlessly. Instead, have __ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers. If caller of __ibmvnic_open() is ibmvnic_open(), it should release the resources immediately. If the caller is do_reset() or do_hard_reset(), they will release the resources on the next reset. This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface: [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq [102056] ibmvnic 30000003 env3: Replenished 8 pools Kernel attempted to read user page (10) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000a3c840 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries ... CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1 Workqueue: events_long __ibmvnic_reset [ibmvnic] NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820 REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004 CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000 ... NIP [c000000000a3c840] napi_enable+0x20/0xc0 LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic] Call Trace: [c0000000548e3a80] [0000000000000006] 0x6 (unreliable) [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic] [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic] [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570 [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660 [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0 [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010 38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020 ---[ end trace 5f8033b08fd27706 ]--- Fixes: ed651a10875f ("ibmvnic: Updated reset handling") Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com> Signed-off-by: Sukadev Bhattiprolu <sukadev(a)linux.ibm.com> Reviewed-by: Dany Madden <drt(a)linux.ibm.com> Link: https://lore.kernel.org/r/20220208001918.900602-1-sukadev@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/ibm/ibmvnic.c [commit bbd809305bc7 invocate release_rx_pools() if resources initialization failed, which not merged lead to conflicts] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/ethernet/ibm/ibmvnic.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 955eea41dc16..89b36c928b0e 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -109,6 +109,7 @@ static void release_crq_queue(struct ibmvnic_adapter *); static int __ibmvnic_set_mac(struct net_device *, u8 *); static int init_crq_queue(struct ibmvnic_adapter *adapter); static int send_query_phys_parms(struct ibmvnic_adapter *adapter); +static void ibmvnic_disable_irqs(struct ibmvnic_adapter *adapter); struct ibmvnic_stat { char name[ETH_GSTRING_LEN]; @@ -1177,7 +1178,7 @@ static int __ibmvnic_open(struct net_device *netdev) rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_UP); if (rc) { ibmvnic_napi_disable(adapter); - release_resources(adapter); + ibmvnic_disable_irqs(adapter); return rc; } @@ -1213,7 +1214,6 @@ static int ibmvnic_open(struct net_device *netdev) rc = init_resources(adapter); if (rc) { netdev_err(netdev, "failed to initialize resources\n"); - release_resources(adapter); goto out; } } @@ -1229,6 +1229,10 @@ static int ibmvnic_open(struct net_device *netdev) adapter->state = VNIC_OPEN; rc = 0; } + + if (rc) + release_resources(adapter); + return rc; } -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ibmvnic: don't release napi in __ibmvnic_open()
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Sukadev Bhattiprolu <sukadev(a)linux.ibm.com> mainline inclusion from mainline-v5.17-rc4 commit 61772b0908c640d0309c40f7d41d062ca4e979fa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IADGL6 CVE: CVE-2022-48811 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If __ibmvnic_open() encounters an error such as when setting link state, it calls release_resources() which frees the napi structures needlessly. Instead, have __ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers. If caller of __ibmvnic_open() is ibmvnic_open(), it should release the resources immediately. If the caller is do_reset() or do_hard_reset(), they will release the resources on the next reset. This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface: [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq [102056] ibmvnic 30000003 env3: Replenished 8 pools Kernel attempted to read user page (10) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000a3c840 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries ... CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1 Workqueue: events_long __ibmvnic_reset [ibmvnic] NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820 REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004 CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000 ... NIP [c000000000a3c840] napi_enable+0x20/0xc0 LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic] Call Trace: [c0000000548e3a80] [0000000000000006] 0x6 (unreliable) [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic] [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic] [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570 [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660 [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0 [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010 38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020 ---[ end trace 5f8033b08fd27706 ]--- Fixes: ed651a10875f ("ibmvnic: Updated reset handling") Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com> Signed-off-by: Sukadev Bhattiprolu <sukadev(a)linux.ibm.com> Reviewed-by: Dany Madden <drt(a)linux.ibm.com> Link: https://lore.kernel.org/r/20220208001918.900602-1-sukadev@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/ibm/ibmvnic.c [commit bbd809305bc7 invocate release_rx_pools() if resources initialization failed, which not merged lead to conflicts] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/ethernet/ibm/ibmvnic.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 48757a59fadd..6e0092937017 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -109,6 +109,7 @@ static void release_crq_queue(struct ibmvnic_adapter *); static int __ibmvnic_set_mac(struct net_device *, u8 *); static int init_crq_queue(struct ibmvnic_adapter *adapter); static int send_query_phys_parms(struct ibmvnic_adapter *adapter); +static void ibmvnic_disable_irqs(struct ibmvnic_adapter *adapter); struct ibmvnic_stat { char name[ETH_GSTRING_LEN]; @@ -1167,7 +1168,7 @@ static int __ibmvnic_open(struct net_device *netdev) rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_UP); if (rc) { ibmvnic_napi_disable(adapter); - release_resources(adapter); + ibmvnic_disable_irqs(adapter); return rc; } @@ -1203,7 +1204,6 @@ static int ibmvnic_open(struct net_device *netdev) rc = init_resources(adapter); if (rc) { netdev_err(netdev, "failed to initialize resources\n"); - release_resources(adapter); goto out; } } @@ -1219,6 +1219,10 @@ static int ibmvnic_open(struct net_device *netdev) adapter->state = VNIC_OPEN; rc = 0; } + + if (rc) + release_resources(adapter); + return rc; } -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] nvme-fabrics: use reserved tag for reg read/write command
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Chunguang Xu <chunguang.xu(a)shopee.com> mainline inclusion from mainline-v6.10-rc3 commit 7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKB CVE: CVE-2024-41082 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially. So the reserved tags may still be enough while reg_xx() use reserved tags. Signed-off-by: Chunguang Xu <chunguang.xu(a)shopee.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/host/fabrics.c [Ma Wupeng: BLK_MQ_REQ_RESERVED is replaced by NVME_SUBMIT_RESERVED in v6.8] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/nvme/host/fabrics.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c index 7015fba2e512..2687454351bc 100644 --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -151,7 +151,7 @@ int nvmf_reg_read32(struct nvme_ctrl *ctrl, u32 off, u32 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -198,7 +198,7 @@ int nvmf_reg_read64(struct nvme_ctrl *ctrl, u32 off, u64 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -244,7 +244,7 @@ int nvmf_reg_write32(struct nvme_ctrl *ctrl, u32 off, u32 val) cmd.prop_set.value = cpu_to_le64(val); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, NULL, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (unlikely(ret)) dev_err(ctrl->device, "Property Set error: %d, offset %#x\n", -- 2.17.1

2 1

[PATCH OLK-5.10] nvme-fabrics: use reserved tag for reg read/write command
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Chunguang Xu <chunguang.xu(a)shopee.com> mainline inclusion from mainline-v6.10-rc3 commit 7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKB CVE: CVE-2024-41082 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially. So the reserved tags may still be enough while reg_xx() use reserved tags. Signed-off-by: Chunguang Xu <chunguang.xu(a)shopee.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/host/fabrics.c [Ma Wupeng: BLK_MQ_REQ_RESERVED is replaced by NVME_SUBMIT_RESERVED in v6.8] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/nvme/host/fabrics.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c index 7015fba2e512..2687454351bc 100644 --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -151,7 +151,7 @@ int nvmf_reg_read32(struct nvme_ctrl *ctrl, u32 off, u32 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -198,7 +198,7 @@ int nvmf_reg_read64(struct nvme_ctrl *ctrl, u32 off, u64 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -244,7 +244,7 @@ int nvmf_reg_write32(struct nvme_ctrl *ctrl, u32 off, u32 val) cmd.prop_set.value = cpu_to_le64(val); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, NULL, NULL, 0, 0, - NVME_QID_ANY, 0, 0, false); + NVME_QID_ANY, 0, BLK_MQ_REQ_RESERVED, false); if (unlikely(ret)) dev_err(ctrl->device, "Property Set error: %d, offset %#x\n", -- 2.17.1

2 1

[PATCH OLK-5.10] drm/radeon: check bo_va->bo is non-NULL before using it
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> stable inclusion from stable-v6.6.42 commit f13c96e0e325a057c03f8a47734adb360e112efe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMD CVE: CVE-2024-41060 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6fb15dcbcf4f212930350eaee174bb60ed40a536 ] The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/gpu/drm/radeon/radeon_gem.c [Ma Wupeng: Context conflict] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 75053917d213..51b6f38b5c47 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -582,7 +582,7 @@ static void radeon_gem_va_update_vm(struct radeon_device *rdev, if (r) goto error_unlock; - if (bo_va->it.start) + if (bo_va->it.start && bo_va->bo) r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem); error_unlock: -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/radeon: check bo_va->bo is non-NULL before using it
by Guo Mengqi 27 Aug '24

27 Aug '24

From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> stable inclusion from stable-v6.6.42 commit f13c96e0e325a057c03f8a47734adb360e112efe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMD CVE: CVE-2024-41060 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6fb15dcbcf4f212930350eaee174bb60ed40a536 ] The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/gpu/drm/radeon/radeon_gem.c [Ma Wupeng: Context conflict] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index e5c4271e64ed..1c9c6e49cb22 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -584,7 +584,7 @@ static void radeon_gem_va_update_vm(struct radeon_device *rdev, if (r) goto error_unlock; - if (bo_va->it.start) + if (bo_va->it.start && bo_va->bo) r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem); error_unlock: -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
by Xiang Yang 27 Aug '24

27 Aug '24

From: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> stable inclusion from stable-v5.10.215 commit ada28eb4b9561aab93942f3224a2e41d76fe57fa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9S26U CVE: CVE-2023-52880 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 67c37756898a5a6b2941a13ae7260c89b54e0d88 upstream. Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> Link: https://lore.kernel.org/r/20230731185942.279611-1-cascardo@canonical.com Cc: Salvatore Bonaccorso <carnil(a)debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- drivers/tty/n_gsm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index 6cd87e71fecc..96a5e0f91c15 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2619,6 +2619,9 @@ static int gsmld_open(struct tty_struct *tty) struct gsm_mux *gsm; int ret; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + if (tty->ops->write == NULL) return -EINVAL; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 13475/23564] net/can/j1939/.tmp_socket.o: warning: objtool: j1939_sk_queue_activate_next()+0x89: unreachable instruction
by kernel test robot 27 Aug '24

27 Aug '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 73a86ad60aabf460a4c8a0f96a1b2ddb98522fd8 commit: e0c2ee9edcacfdda0e806166eaec1310cdf9e324 [13475/23564] can: add support of SAE J1939 protocol config: x86_64-buildonly-randconfig-004-20240825 (https://download.01.org/0day-ci/archive/20240827/202408272140.3C5OLBQP-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/20240827/202408272140.3C5OLBQP-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/202408272140.3C5OLBQP-lkp@intel.com/ All warnings (new ones prefixed by >>): >> net/can/j1939/.tmp_socket.o: warning: objtool: j1939_sk_queue_activate_next()+0x89: unreachable instruction -- >> net/can/j1939/.tmp_transport.o: warning: objtool: j1939_xtp_abort_to_errno()+0xea: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10 0/2] Fix mainline patchs
by Luo Gengkun 27 Aug '24

27 Aug '24

Breno Leitao (1): perf/x86/amd/core: Always clear status for idx Sandipan Das (1): perf/x86/amd/core: Fix overflow reset on hotplug arch/x86/events/amd/core.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] net/ipv6: Fix the RT cache flush via sysctl using a previous delay
by Liu Jian 27 Aug '24

27 Aug '24

From: Petr Pavlu <petr.pavlu(a)suse.com> stable inclusion from stable-v4.19.317 commit ebde6e8a52c68dc45b4ae354e279ba74788579e7 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAMPH5 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- [ Upstream commit 14a20e5b4ad998793c5f43b0330d9e1388446cf3 ] The net.ipv6.route.flush system parameter takes a value which specifies a delay used during the flush operation for aging exception routes. The written value is however not used in the currently requested flush and instead utilized only in the next one. A problem is that ipv6_sysctl_rtcache_flush() first reads the old value of net->ipv6.sysctl.flush_delay into a local delay variable and then calls proc_dointvec() which actually updates the sysctl based on the provided input. Fix the problem by switching the order of the two operations. Fixes: 4990509f19e8 ("[NETNS][IPV6]: Make sysctls route per namespace.") Signed-off-by: Petr Pavlu <petr.pavlu(a)suse.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240607112828.30285-1-petr.pavlu@suse.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv6/route.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index e7ff0f40867b..907a5e507819 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -5186,12 +5186,12 @@ int ipv6_sysctl_rtcache_flush(struct ctl_table *ctl, int write, if (!write) return -EINVAL; - net = (struct net *)ctl->extra1; - delay = net->ipv6.sysctl.flush_delay; ret = proc_dointvec(ctl, write, buffer, lenp, ppos); if (ret) return ret; + net = (struct net *)ctl->extra1; + delay = net->ipv6.sysctl.flush_delay; fib6_run_gc(delay <= 0 ? 0 : (unsigned long)delay, net, delay > 0); return 0; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] af_packet: do not call packet_read_pending() from tpacket_destruct_skb()
by Dong Chenchen 27 Aug '24

27 Aug '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.316 commit 4f3ae7d846b4565c0b80d65ed607c3277bc984d4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAMPH5 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 581073f626e387d3e7eed55c48c8495584ead7ba ] trafgen performance considerably sank on hosts with many cores after the blamed commit. packet_read_pending() is very expensive, and calling it in af_packet fast path defeats Daniel intent in commit b013840810c2 ("packet: use percpu mmap tx frame pending refcount") tpacket_destruct_skb() makes room for one packet, we can immediately wakeup a producer, no need to completely drain the tx ring. Fixes: 89ed5b519004 ("af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Neil Horman <nhorman(a)tuxdriver.com> Cc: Daniel Borkmann <daniel(a)iogearbox.net> Reviewed-by: Willem de Bruijn <willemb(a)google.com> Link: https://lore.kernel.org/r/20240515163358.4105915-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/packet/af_packet.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index c64bcba21e47..e26ee0486ded 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -2437,8 +2437,7 @@ static void tpacket_destruct_skb(struct sk_buff *skb) ts = __packet_set_timestamp(po, ph, skb); __packet_set_status(po, ph, TP_STATUS_AVAILABLE | ts); - if (!packet_read_pending(&po->tx_ring)) - complete(&po->skb_completion); + complete(&po->skb_completion); } sock_wfree(skb); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
by Long Li 27 Aug '24

27 Aug '24

From: Huacai Chen <chenhuacai(a)loongson.cn> stable inclusion from stable-v5.15.164 commit 0484adcb5fbcadd9ba0fd4485c42630f72e97da9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKPVC CVE: CVE-2024-42299 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit 2fef55d8f78383c8e6d6d4c014b9597375132696 upstream. If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page(). Cc: stable(a)vger.kernel.org Fixes: b46acd6a6a627d876898e ("fs/ntfs3: Add NTFS journal") Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ntfs3/fslog.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/ntfs3/fslog.c b/fs/ntfs3/fslog.c index f78aa66313d2..fb56c4c33987 100644 --- a/fs/ntfs3/fslog.c +++ b/fs/ntfs3/fslog.c @@ -3953,6 +3953,9 @@ int log_replay(struct ntfs_inode *ni, bool *initialized) goto out; } + log->page_mask = log->page_size - 1; + log->page_bits = blksize_bits(log->page_size); + /* If the file size has shrunk then we won't mount it. */ if (l_size < le64_to_cpu(ra2->l_size)) { err = -EINVAL; -- 2.39.2

2 1

[PATCH OLK-5.10] fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
by Long Li 27 Aug '24

27 Aug '24

From: Huacai Chen <chenhuacai(a)loongson.cn> stable inclusion from stable-v5.15.164 commit 0484adcb5fbcadd9ba0fd4485c42630f72e97da9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKPVC CVE: CVE-2024-42299 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit 2fef55d8f78383c8e6d6d4c014b9597375132696 upstream. If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page(). Cc: stable(a)vger.kernel.org Fixes: b46acd6a6a627d876898e ("fs/ntfs3: Add NTFS journal") Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ntfs3/fslog.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/ntfs3/fslog.c b/fs/ntfs3/fslog.c index f78aa66313d2..fb56c4c33987 100644 --- a/fs/ntfs3/fslog.c +++ b/fs/ntfs3/fslog.c @@ -3953,6 +3953,9 @@ int log_replay(struct ntfs_inode *ni, bool *initialized) goto out; } + log->page_mask = log->page_size - 1; + log->page_bits = blksize_bits(log->page_size); + /* If the file size has shrunk then we won't mount it. */ if (l_size < le64_to_cpu(ra2->l_size)) { err = -EINVAL; -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] tcp: fix race in tcp_v6_syn_recv_sock()
by Yue Haibing 27 Aug '24

27 Aug '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.317 commit 06f208ae0670ef97b0bf253a5523863e113026b6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMPH5 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit d37fe4255abe8e7b419b90c5847e8ec2b8debb08 ] tcp_v6_syn_recv_sock() calls ip6_dst_store() before inet_sk(newsk)->pinet6 has been set up. This means ip6_dst_store() writes over the parent (listener) np->dst_cookie. This is racy because multiple threads could share the same parent and their final np->dst_cookie could be wrong. Move ip6_dst_store() call after inet_sk(newsk)->pinet6 has been changed and after the copy of parent ipv6_pinfo. Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yue Haibing <yuehaibing(a)huawei.com> --- net/ipv6/tcp_ipv6.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index e3878cf00dd4..4d9c9fbef8b9 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -1176,7 +1176,6 @@ static struct sock *tcp_v6_syn_recv_sock(const struct sock *sk, struct sk_buff * */ newsk->sk_gso_type = SKB_GSO_TCPV6; - ip6_dst_store(newsk, dst, NULL, NULL); inet6_sk_rx_dst_set(newsk, skb); newtcp6sk = (struct tcp6_sock *)newsk; @@ -1188,6 +1187,8 @@ static struct sock *tcp_v6_syn_recv_sock(const struct sock *sk, struct sk_buff * memcpy(newnp, np, sizeof(struct ipv6_pinfo)); + ip6_dst_store(newsk, dst, NULL, NULL); + newsk->sk_v6_daddr = ireq->ir_v6_rmt_addr; newnp->saddr = ireq->ir_v6_loc_addr; newsk->sk_v6_rcv_saddr = ireq->ir_v6_loc_addr; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] net: Backport lts-4.19 patches
by Dong Chenchen 27 Aug '24

27 Aug '24

backport lts-4.19 patches. Eric Dumazet (1): af_packet: do not call packet_read_pending() from tpacket_destruct_skb() Qingfang DENG (1): neighbour: fix unaligned access to pneigh_entry include/net/neighbour.h | 2 +- net/packet/af_packet.c | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) -- 2.25.1

2 3

[PATCH OLK-5.10 0/5] Bugfix patches for hns RoCE
by Chengchang Tang 27 Aug '24

27 Aug '24

From: Xinghai Cen <cenxinghai(a)h-partners.com> Some bugfix patches for hns roce. Chengchang Tang (4): RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS RDMA/hns: Fix possible RAS when DCA is not attached RDMA/hns: Fix a meaningless loop in active_dca_pages_proc() RDMA/hns: Fix list_*_careful() not being used in pairs Junxian Huang (1): RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler drivers/infiniband/hw/hns/hns_roce_dca.c | 60 +++++++++++++++++++-- drivers/infiniband/hw/hns/hns_roce_dca.h | 2 + drivers/infiniband/hw/hns/hns_roce_device.h | 3 ++ drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 9 ++-- drivers/infiniband/hw/hns/hns_roce_main.c | 12 +++++ drivers/infiniband/hw/hns/hns_roce_qp.c | 23 ++++++++ 6 files changed, 102 insertions(+), 7 deletions(-) -- 2.33.0

2 6

[PATCH openEuler-1.0-LTS v1 0/2] Backport bugfix for AMD SMN
by Wei Li 27 Aug '24

27 Aug '24

Backport bugfix for AMD SMN. Naveen Naidu (1): PCI: Add PCI_ERROR_RESPONSE and related definitions Yazen Ghannam (1): x86/amd_nb: Check for invalid SMN reads arch/x86/kernel/amd_nb.c | 9 ++++++++- include/linux/pci.h | 9 +++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS] kobject_uevent: Fix OOB access within zap_modalias_env()
by Zhao Wenhui 27 Aug '24

27 Aug '24

From: Zijun Hu <quic_zijuhu(a)quicinc.com> mainline inclusion from mainline-v6.11-rc1 commit dd6e9894b451e7c85cceb8e9dc5432679a70e7dc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKPXP CVE: CVE-2024-42292 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove. Fixes: 9b3fa47d4a76 ("kobject: fix suppressing modalias in uevents delivered over netlink") Cc: stable(a)vger.kernel.org Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> Reviewed-by: Lk Sii <lk_sii(a)163.com> Link: https://lore.kernel.org/r/1717074877-11352-1-git-send-email-quic_zijuhu@qui… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhao Wenhui <zhaowenhui8(a)huawei.com> --- lib/kobject_uevent.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c index b5fc7b9ce197..1af2e79b5c2d 100644 --- a/lib/kobject_uevent.c +++ b/lib/kobject_uevent.c @@ -430,8 +430,23 @@ static void zap_modalias_env(struct kobj_uevent_env *env) len = strlen(env->envp[i]) + 1; if (i != env->envp_idx - 1) { + /* @env->envp[] contains pointers to @env->buf[] + * with @env->buflen chars, and we are removing + * variable MODALIAS here pointed by @env->envp[i] + * with length @len as shown below: + * + * 0 @env->buf[] @env->buflen + * --------------------------------------------- + * ^ ^ ^ ^ + * | |-> @len <-| target block | + * @env->envp[0] @env->envp[i] @env->envp[i + 1] + * + * so the "target block" indicated above is moved + * backward by @len, and its right size is + * @env->buflen - (@env->envp[i + 1] - @env->envp[0]). + */ memmove(env->envp[i], env->envp[i + 1], - env->buflen - len); + env->buflen - (env->envp[i + 1] - env->envp[0])); for (j = i; j < env->envp_idx - 1; j++) env->envp[j] = env->envp[j + 1] - len; -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] Fix Mainline patchs
by Luo Gengkun 27 Aug '24

27 Aug '24

Breno Leitao (1): perf/x86/amd/core: Always clear status for idx Sandipan Das (1): perf/x86/amd/core: Fix overflow reset on hotplug arch/x86/events/amd/core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/2]
by Luo Gengkun 27 Aug '24

27 Aug '24

Breno Leitao (1): perf/x86/amd/core: Always clear status for idx Sandipan Das (1): perf/x86/amd/core: Fix overflow reset on hotplug arch/x86/events/amd/core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) -- 2.34.1

2 7

[PATCH OLK-5.10 0/1] CVE-2024-42287
by Chen Ridong 27 Aug '24

27 Aug '24

CVE-2024-42287 Shreyas Deodhar (1): scsi: qla2xxx: Complete command early within lock drivers/scsi/qla2xxx/qla_os.c | 5 ----- 1 file changed, 5 deletions(-) -- 2.34.1

2 2

[openeuler:openEuler-1.0-LTS 12062/23560] drivers/tty/serial/.tmp_qcom_geni_serial.o: warning: objtool: qcom_geni_serial_isr()+0x6c8: unreachable instruction
by kernel test robot 27 Aug '24

27 Aug '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 4ac8b0d82ef645e01323a31304f6455504295672 commit: c33757a1508dbe0d07881dbe5d82c59dcc6f28ac [12062/23560] tty: serial: qcom_geni_serial: Fix softlock config: x86_64-buildonly-randconfig-004-20240825 (https://download.01.org/0day-ci/archive/20240827/202408271554.zPOb5Yqp-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/20240827/202408271554.zPOb5Yqp-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/202408271554.zPOb5Yqp-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/tty/serial/.tmp_qcom_geni_serial.o: warning: objtool: qcom_geni_serial_isr()+0x6c8: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10 V1] block: initialize integrity buffer to zero before writing it to media
by Cheng Yu 27 Aug '24

27 Aug '24

From: Christoph Hellwig <hch(a)lst.de> stable inclusion from stable-v6.6.44 commit 23a19655fb56f241e592041156dfb1c6d04da644 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ5R CVE: CVE-2024-43854 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f ] Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes. Fixes: 7ba1ba12eeef ("block: Block layer data integrity support") Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com> Reviewed-by: Kanchan Joshi <joshi.k(a)samsung.com> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Link: https://lore.kernel.org/r/20240613084839.1044015-2-hch@lst.de Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: block/bio-integrity.c [This is a conflict caused by commit ce288e053568("block: remove BLK_BOUNCE_ISA support") which is not merged.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- block/bio-integrity.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/block/bio-integrity.c b/block/bio-integrity.c index a4cfc97275df..a5fd04db5ae8 100644 --- a/block/bio-integrity.c +++ b/block/bio-integrity.c @@ -216,6 +216,7 @@ bool bio_integrity_prep(struct bio *bio) unsigned int bytes, offset, i; unsigned int intervals; blk_status_t status; + gfp_t gfp = GFP_NOIO; if (!bi) return true; @@ -238,12 +239,20 @@ bool bio_integrity_prep(struct bio *bio) if (!bi->profile->generate_fn || !(bi->flags & BLK_INTEGRITY_GENERATE)) return true; + + /* + * Zero the memory allocated to not leak uninitialized kernel + * memory to disk. For PI this only affects the app tag, but + * for non-integrity metadata it affects the entire metadata + * buffer. + */ + gfp |= __GFP_ZERO; } intervals = bio_integrity_intervals(bi, bio_sectors(bio)); /* Allocate kernel buffer for protection data */ len = intervals * bi->tuple_size; - buf = kmalloc(len, GFP_NOIO | q->bounce_gfp); + buf = kmalloc(len, gfp | q->bounce_gfp); status = BLK_STS_RESOURCE; if (unlikely(buf == NULL)) { printk(KERN_ERR "could not allocate integrity buffer\n"); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 V1] block: initialize integrity buffer to zero before writing it to media
by Cheng Yu 27 Aug '24

27 Aug '24

From: Christoph Hellwig <hch(a)lst.de> stable inclusion from stable-v6.6.44 commit 23a19655fb56f241e592041156dfb1c6d04da644 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ5R CVE: CVE-2024-43854 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f ] Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes. Fixes: 7ba1ba12eeef ("block: Block layer data integrity support") Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com> Reviewed-by: Kanchan Joshi <joshi.k(a)samsung.com> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Link: https://lore.kernel.org/r/20240613084839.1044015-2-hch@lst.de Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: block/bio-integrity.c [This is a conflict caused by commit ce288e053568("block: remove BLK_BOUNCE_ISA support") which is not merged.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- block/bio-integrity.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/block/bio-integrity.c b/block/bio-integrity.c index 4f6f140a44e0..3473e0133468 100644 --- a/block/bio-integrity.c +++ b/block/bio-integrity.c @@ -216,6 +216,7 @@ bool bio_integrity_prep(struct bio *bio) unsigned int bytes, offset, i; unsigned int intervals; blk_status_t status; + gfp_t gfp = GFP_NOIO; if (!bi) return true; @@ -238,12 +239,20 @@ bool bio_integrity_prep(struct bio *bio) if (!bi->profile->generate_fn || !(bi->flags & BLK_INTEGRITY_GENERATE)) return true; + + /* + * Zero the memory allocated to not leak uninitialized kernel + * memory to disk. For PI this only affects the app tag, but + * for non-integrity metadata it affects the entire metadata + * buffer. + */ + gfp |= __GFP_ZERO; } intervals = bio_integrity_intervals(bi, bio_sectors(bio)); /* Allocate kernel buffer for protection data */ len = intervals * bi->tuple_size; - buf = kmalloc(len, GFP_NOIO | q->bounce_gfp); + buf = kmalloc(len, gfp | q->bounce_gfp); status = BLK_STS_RESOURCE; if (unlikely(buf == NULL)) { printk(KERN_ERR "could not allocate integrity buffer\n"); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] tcp: fix race in tcp_v6_syn_recv_sock()
by Yue Haibing 27 Aug '24

27 Aug '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.317 commit 06f208ae0670ef97b0bf253a5523863e113026b6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMPH5 CVE: Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit d37fe4255abe8e7b419b90c5847e8ec2b8debb08 ] tcp_v6_syn_recv_sock() calls ip6_dst_store() before inet_sk(newsk)->pinet6 has been set up. This means ip6_dst_store() writes over the parent (listener) np->dst_cookie. This is racy because multiple threads could share the same parent and their final np->dst_cookie could be wrong. Move ip6_dst_store() call after inet_sk(newsk)->pinet6 has been changed and after the copy of parent ipv6_pinfo. Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yue Haibing <yuehaibing(a)huawei.com> --- net/ipv6/tcp_ipv6.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index e3878cf00dd4..4d9c9fbef8b9 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -1176,7 +1176,6 @@ static struct sock *tcp_v6_syn_recv_sock(const struct sock *sk, struct sk_buff * */ newsk->sk_gso_type = SKB_GSO_TCPV6; - ip6_dst_store(newsk, dst, NULL, NULL); inet6_sk_rx_dst_set(newsk, skb); newtcp6sk = (struct tcp6_sock *)newsk; @@ -1188,6 +1187,8 @@ static struct sock *tcp_v6_syn_recv_sock(const struct sock *sk, struct sk_buff * memcpy(newnp, np, sizeof(struct ipv6_pinfo)); + ip6_dst_store(newsk, dst, NULL, NULL); + newsk->sk_v6_daddr = ireq->ir_v6_rmt_addr; newnp->saddr = ireq->ir_v6_loc_addr; newsk->sk_v6_rcv_saddr = ireq->ir_v6_loc_addr; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/1] irqchip/alpine-msi: Fix off-by-one in allocation error path
by Yuntao Liu 27 Aug '24

27 Aug '24

irqchip/alpine-msi: Fix off-by-one in allocation error path Zenghui Yu (1): irqchip/alpine-msi: Fix off-by-one in allocation error path drivers/irqchip/irq-alpine-msi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] dma: fix call order in dmam_free_coherent
by Kaixiong Yu 27 Aug '24

27 Aug '24

From: Lance Richardson <rlance(a)google.com> stable inclusion from stable-v6.6.44 commit 1fe97f68fce1ba24bf823bfb0eb0956003473130 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ2W CVE: CVE-2024-43856 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 28e8b7406d3a1f5329a03aa25a43aa28e087cb20 ] dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. Tested: kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 Fixes: 9ac7849e35f7 ("devres: device resource management") Signed-off-by: Lance Richardson <rlance(a)google.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- kernel/dma/mapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 9cc1b34cab8f..9d0b026e6aba 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -97,8 +97,8 @@ void dmam_free_coherent(struct device *dev, size_t size, void *vaddr, { struct dma_devres match_data = { size, vaddr, dma_handle }; - dma_free_coherent(dev, size, vaddr, dma_handle); WARN_ON(devres_destroy(dev, dmam_release, dmam_match, &match_data)); + dma_free_coherent(dev, size, vaddr, dma_handle); } EXPORT_SYMBOL(dmam_free_coherent); -- 2.25.1

2 1

[PATCH OLK-5.10] dma: fix call order in dmam_free_coherent
by Kaixiong Yu 27 Aug '24

27 Aug '24

From: Lance Richardson <rlance(a)google.com> stable inclusion from stable-v6.6.44 commit 1fe97f68fce1ba24bf823bfb0eb0956003473130 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ2W CVE: CVE-2024-43856 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 28e8b7406d3a1f5329a03aa25a43aa28e087cb20 ] dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. Tested: kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 Fixes: 9ac7849e35f7 ("devres: device resource management") Signed-off-by: Lance Richardson <rlance(a)google.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/dma/mapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 51bb8fa8eb89..453c0fbe87ff 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -60,8 +60,8 @@ void dmam_free_coherent(struct device *dev, size_t size, void *vaddr, { struct dma_devres match_data = { size, vaddr, dma_handle }; - dma_free_coherent(dev, size, vaddr, dma_handle); WARN_ON(devres_destroy(dev, dmam_release, dmam_match, &match_data)); + dma_free_coherent(dev, size, vaddr, dma_handle); } EXPORT_SYMBOL(dmam_free_coherent); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/1] irqchip/alpine-msi: Fix off-by-one in allocation error path
by Yuntao Liu 27 Aug '24

27 Aug '24

irqchip/alpine-msi: Fix off-by-one in allocation error path Zenghui Yu (1): irqchip/alpine-msi: Fix off-by-one in allocation error path drivers/irqchip/irq-alpine-msi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.34.1

2 2

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS cbbc4774e41c354f5b0f9fc7a9be442fcee74b3f
by kernel test robot 27 Aug '24

27 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: cbbc4774e41c354f5b0f9fc7a9be442fcee74b3f !11122 fix CVE-2023-52893 elapsed time: 771m configs tested: 34 configs skipped: 127 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240827 gcc-14.1.0 arm64 randconfig-002-20240827 gcc-14.1.0 arm64 randconfig-003-20240827 gcc-14.1.0 arm64 randconfig-004-20240827 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240827 clang-18 x86_64 buildonly-randconfig-002-20240827 gcc-12 x86_64 buildonly-randconfig-003-20240827 gcc-12 x86_64 buildonly-randconfig-004-20240827 gcc-12 x86_64 buildonly-randconfig-005-20240827 clang-18 x86_64 buildonly-randconfig-006-20240827 gcc-12 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240827 clang-18 x86_64 randconfig-002-20240827 gcc-12 x86_64 randconfig-003-20240827 gcc-12 x86_64 randconfig-004-20240827 gcc-12 x86_64 randconfig-005-20240827 clang-18 x86_64 randconfig-006-20240827 gcc-12 x86_64 randconfig-011-20240827 gcc-12 x86_64 randconfig-012-20240827 gcc-12 x86_64 randconfig-013-20240827 gcc-12 x86_64 randconfig-014-20240827 clang-18 x86_64 randconfig-015-20240827 gcc-12 x86_64 randconfig-016-20240827 gcc-12 x86_64 randconfig-071-20240827 gcc-12 x86_64 randconfig-072-20240827 gcc-11 x86_64 randconfig-073-20240827 gcc-12 x86_64 randconfig-074-20240827 gcc-12 x86_64 randconfig-075-20240827 clang-18 x86_64 randconfig-076-20240827 gcc-12 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] md: restore 'noio_flag' for the last mddev_resume()
by Zheng Qixing 27 Aug '24

27 Aug '24

From: Yu Kuai <yukuai3(a)huawei.com> mainline inclusion from mainline-v6.6-rc1 commit e24ed04389f9619e0aaef615a8948633c182a8b0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAMIV7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- memalloc_noio_save() is called for the first mddev_suspend(), and repeated mddev_suspend() only increase 'suspended'. However, memalloc_noio_restore() is also called for the first mddev_resume(), which means that memory reclaim will be enabled before the last mddev_resume() is called, while the array is still suspended. Fix this problem by restore 'noio_flag' for the last mddev_resume(). Fixes: 78f57ef9d50a ("md: use memalloc scope APIs in mddev_suspend()/mddev_resume()") Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Link: https://lore.kernel.org/r/20230628012931.88911-3-yukuai1@huaweicloud.com Signed-off-by: Song Liu <song(a)kernel.org> Conflicts: drivers/md/md.c [The modifications made in commit 72adae23a72c ("md: Change active_io to percpu") are related to performance optimization and involve multiple parts. The conflict here is only due to inconsistencies in the context.] Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/md/md.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 6d53a4078c08..897bb0aad180 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -520,11 +520,13 @@ EXPORT_SYMBOL_GPL(mddev_suspend); void mddev_resume(struct mddev *mddev) { - /* entred the memalloc scope from mddev_suspend() */ - memalloc_noio_restore(mddev->noio_flag); lockdep_assert_held(&mddev->reconfig_mutex); if (--mddev->suspended) return; + + /* entred the memalloc scope from mddev_suspend() */ + memalloc_noio_restore(mddev->noio_flag); + wake_up(&mddev->sb_wait); mddev->pers->quiesce(mddev, 0); -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] tracing: Fix overflow in get_free_elt()
by Liu Chuang 27 Aug '24

27 Aug '24

From: Tze-nan Wu <Tze-nan.Wu(a)mediatek.com> stable inclusion from stable-v4.19.320 commit 302ceb625d7b990db205a15e371f9a71238de91c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMMUB CVE: CVE-2024-43890 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit bcf86c01ca4676316557dd482c8416ece8c2e143 upstream. "tracing_map->next_elt" in get_free_elt() is at risk of overflowing. Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (`max_elts`) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using `__tracing_map_insert()`, it will cause an infinite loop with preemption disabled, leading to a CPU hang problem. Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt". Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Fixes: 08d43a5fa063e ("tracing: Add lock-free tracing_map") Co-developed-by: Cheng-Jui Wang <cheng-jui.wang(a)mediatek.com> Link: https://lore.kernel.org/20240805055922.6277-1-Tze-nan.Wu@mediatek.com Signed-off-by: Cheng-Jui Wang <cheng-jui.wang(a)mediatek.com> Signed-off-by: Tze-nan Wu <Tze-nan.Wu(a)mediatek.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- kernel/trace/tracing_map.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c index da7337f0c9bc..5e534ef6d695 100644 --- a/kernel/trace/tracing_map.c +++ b/kernel/trace/tracing_map.c @@ -451,7 +451,7 @@ static struct tracing_map_elt *get_free_elt(struct tracing_map *map) struct tracing_map_elt *elt = NULL; int idx; - idx = atomic_inc_return(&map->next_elt); + idx = atomic_fetch_add_unless(&map->next_elt, 1, map->max_elts); if (idx < map->max_elts) { elt = *(TRACING_MAP_ELT(map->elts, idx)); if (map->ops && map->ops->elt_init) @@ -696,7 +696,7 @@ void tracing_map_clear(struct tracing_map *map) { unsigned int i; - atomic_set(&map->next_elt, -1); + atomic_set(&map->next_elt, 0); atomic64_set(&map->hits, 0); atomic64_set(&map->drops, 0); @@ -780,7 +780,7 @@ struct tracing_map *tracing_map_create(unsigned int map_bits, map->map_bits = map_bits; map->max_elts = (1 << map_bits); - atomic_set(&map->next_elt, -1); + atomic_set(&map->next_elt, 0); map->map_size = (1 << (map_bits + 1)); map->ops = ops; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] tracing: Fix overflow in get_free_elt()
by Liu Chuang 27 Aug '24

27 Aug '24

From: Tze-nan Wu <Tze-nan.Wu(a)mediatek.com> stable inclusion from stable-v5.10.224 commit eb223bf01e688dfe37e813c8988ee11c8c9f8d0a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMMUB CVE: CVE-2024-43890 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit bcf86c01ca4676316557dd482c8416ece8c2e143 upstream. "tracing_map->next_elt" in get_free_elt() is at risk of overflowing. Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (`max_elts`) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using `__tracing_map_insert()`, it will cause an infinite loop with preemption disabled, leading to a CPU hang problem. Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt". Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Fixes: 08d43a5fa063e ("tracing: Add lock-free tracing_map") Co-developed-by: Cheng-Jui Wang <cheng-jui.wang(a)mediatek.com> Link: https://lore.kernel.org/20240805055922.6277-1-Tze-nan.Wu@mediatek.com Signed-off-by: Cheng-Jui Wang <cheng-jui.wang(a)mediatek.com> Signed-off-by: Tze-nan Wu <Tze-nan.Wu(a)mediatek.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- kernel/trace/tracing_map.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c index d47641f9740b..e6cc8d5ab1a4 100644 --- a/kernel/trace/tracing_map.c +++ b/kernel/trace/tracing_map.c @@ -454,7 +454,7 @@ static struct tracing_map_elt *get_free_elt(struct tracing_map *map) struct tracing_map_elt *elt = NULL; int idx; - idx = atomic_inc_return(&map->next_elt); + idx = atomic_fetch_add_unless(&map->next_elt, 1, map->max_elts); if (idx < map->max_elts) { elt = *(TRACING_MAP_ELT(map->elts, idx)); if (map->ops && map->ops->elt_init) @@ -699,7 +699,7 @@ void tracing_map_clear(struct tracing_map *map) { unsigned int i; - atomic_set(&map->next_elt, -1); + atomic_set(&map->next_elt, 0); atomic64_set(&map->hits, 0); atomic64_set(&map->drops, 0); @@ -783,7 +783,7 @@ struct tracing_map *tracing_map_create(unsigned int map_bits, map->map_bits = map_bits; map->max_elts = (1 << map_bits); - atomic_set(&map->next_elt, -1); + atomic_set(&map->next_elt, 0); map->map_size = (1 << (map_bits + 1)); map->ops = ops; -- 2.34.1

2 1

[PATCH OLK-5.10] tracing: Fix overflow in get_free_elt()
by Liu Chuang 27 Aug '24

27 Aug '24

From: Tze-nan Wu <Tze-nan.Wu(a)mediatek.com> stable inclusion from stable-v5.10.224 commit eb223bf01e688dfe37e813c8988ee11c8c9f8d0a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMMUB CVE: CVE-2024-43890 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit bcf86c01ca4676316557dd482c8416ece8c2e143 upstream. "tracing_map->next_elt" in get_free_elt() is at risk of overflowing. Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (`max_elts`) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using `__tracing_map_insert()`, it will cause an infinite loop with preemption disabled, leading to a CPU hang problem. Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt". Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Fixes: 08d43a5fa063e ("tracing: Add lock-free tracing_map") Co-developed-by: Cheng-Jui Wang <cheng-jui.wang(a)mediatek.com> Link: https://lore.kernel.org/20240805055922.6277-1-Tze-nan.Wu@mediatek.com Signed-off-by: Cheng-Jui Wang <cheng-jui.wang(a)mediatek.com> Signed-off-by: Tze-nan Wu <Tze-nan.Wu(a)mediatek.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- kernel/trace/tracing_map.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c index d47641f9740b..e6cc8d5ab1a4 100644 --- a/kernel/trace/tracing_map.c +++ b/kernel/trace/tracing_map.c @@ -454,7 +454,7 @@ static struct tracing_map_elt *get_free_elt(struct tracing_map *map) struct tracing_map_elt *elt = NULL; int idx; - idx = atomic_inc_return(&map->next_elt); + idx = atomic_fetch_add_unless(&map->next_elt, 1, map->max_elts); if (idx < map->max_elts) { elt = *(TRACING_MAP_ELT(map->elts, idx)); if (map->ops && map->ops->elt_init) @@ -699,7 +699,7 @@ void tracing_map_clear(struct tracing_map *map) { unsigned int i; - atomic_set(&map->next_elt, -1); + atomic_set(&map->next_elt, 0); atomic64_set(&map->hits, 0); atomic64_set(&map->drops, 0); @@ -783,7 +783,7 @@ struct tracing_map *tracing_map_create(unsigned int map_bits, map->map_bits = map_bits; map->max_elts = (1 << map_bits); - atomic_set(&map->next_elt, -1); + atomic_set(&map->next_elt, 0); map->map_size = (1 << (map_bits + 1)); map->ops = ops; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 10069/23560] net/mac80211/.tmp_mlme.o: warning: objtool: ieee80211_sta_rx_queued_mgmt()+0x21c3: unreachable instruction
by kernel test robot 27 Aug '24

27 Aug '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: cbbc4774e41c354f5b0f9fc7a9be442fcee74b3f commit: 3d9b47cc5bf272c32ac3004c433a102db71407c2 [10069/23560] mac80211: Reject malformed SSID elements config: x86_64-buildonly-randconfig-004-20240825 (https://download.01.org/0day-ci/archive/20240827/202408270942.wU6VgBgJ-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/20240827/202408270942.wU6VgBgJ-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/202408270942.wU6VgBgJ-lkp@intel.com/ All warnings (new ones prefixed by >>): >> net/mac80211/.tmp_mlme.o: warning: objtool: ieee80211_sta_rx_queued_mgmt()+0x21c3: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0