November 2024 - Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 0/6] mm: support poison recover for more
by Wupeng Ma 06 Nov '24

06 Nov '24

From: Ma Wupeng <mawupeng1(a)huawei.com> Add machine check safe support for cow & migrate_pages. Avoid kernel panic during arm64_do_kernel_sea if no valid info is reported. Kefeng Wang (2): mm: support poison recovery from copy_present_page() mm: support poison recovery from do_cow_fault() Liu Shixin (1): mm: hwpoison: support recovery from HugePage copy-on-write faults Ma Wupeng (2): arm64: mm: Add copy mc support for all migrate_page arm64: send sig fault for user task when apei_claim_sea fails Tong Tiangen (1): make copy_[user]_highpage_mc have return value arch/arm64/include/asm/page.h | 6 +-- arch/arm64/lib/copy_page_mc.S | 6 ++- arch/arm64/mm/copypage.c | 21 +++++--- arch/arm64/mm/fault.c | 17 +++++-- include/linux/highmem.h | 13 ++++- include/linux/mm.h | 8 ++-- mm/hugetlb.c | 7 ++- mm/memory.c | 90 +++++++++++++++++++++++------------ mm/migrate.c | 5 +- 9 files changed, 118 insertions(+), 55 deletions(-) -- 2.25.1

2 7

[openeuler:OLK-5.10] BUILD REGRESSION f705e909a01ee9ae75542457ca95b055dae177a0
by kernel test robot 06 Nov '24

06 Nov '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: f705e909a01ee9ae75542457ca95b055dae177a0 !13009 CVE-2024-49950 Unverified Error/Warning (likely false positive, kindly check if interested): drivers/gpu/drm/ast/ast_mm.c:116 ast_pci_host_is_5c01() error: we previously assumed 'child' could be null (see line 109) Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allnoconfig | |-- arch-arm64-kernel-ipi_nmi.c:error:implicit-declaration-of-function-printk_safe_enter | |-- arch-arm64-kernel-ipi_nmi.c:error:implicit-declaration-of-function-printk_safe_exit | |-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_enter | |-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_exit | |-- kismet:WARNING:unmet-direct-dependencies-detected-for-BPF_NET_GLOBAL_PROG-when-selected-by-SCHED_TASK_RELATIONSHIP | |-- kismet:WARNING:unmet-direct-dependencies-detected-for-PCI_IOV-when-selected-by-CRYPTO_DEV_HISI_MIGRATION | `-- kismet:WARNING:unmet-direct-dependencies-detected-for-TASK_PLACEMENT_BY_CPU_RANGE-when-selected-by-BPF_SCHED |-- arm64-randconfig-003-20241106 | |-- arch-arm64-include-asm-archrandom.h:error:unknown-register-name-r2-in-asm | `-- arch-arm64-include-asm-archrandom.h:error:unknown-register-name-r3-in-asm |-- x86_64-allnoconfig | |-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_exit-Werror-Wimplicit-function-declaration | |-- kismet:WARNING:unmet-direct-dependencies-detected-for-BPF_NET_GLOBAL_PROG-when-selected-by-SCHED_TASK_RELATIONSHIP | `-- kismet:WARNING:unmet-direct-dependencies-detected-for-TASK_PLACEMENT_BY_CPU_RANGE-when-selected-by-BPF_SCHED |-- x86_64-allyesconfig | `-- drivers-net-ipvlan-ipvlan_main.c:warning:variable-old_prog-set-but-not-used |-- x86_64-buildonly-randconfig-001-20241106 | |-- arch-x86-kernel-paravirt.c:error:implicit-declaration-of-function-__text_gen_insn-Werror-Wimplicit-function-declaration | |-- arch-x86-kernel-paravirt.c:error:use-of-undeclared-identifier-CALL_INSN_OPCODE | `-- arch-x86-kernel-paravirt.c:error:use-of-undeclared-identifier-CALL_INSN_SIZE |-- x86_64-buildonly-randconfig-002-20241028 | `-- fs-crypto-fname.o:warning:objtool:fscrypt_fname_encrypt:unreachable-instruction |-- x86_64-buildonly-randconfig-002-20241106 | |-- drivers-net-ipvlan-ipvlan_main.c:warning:variable-old_prog-set-but-not-used | |-- drivers-tty-tty_buffer.c:error:implicit-declaration-of-function-printk_safe_exit-Werror-Wimplicit-function-declaration | |-- kernel-sched-topology.c:error:implicit-declaration-of-function-register_sysctl_init-Werror-Wimplicit-function-declaration | `-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_exit-Werror-Wimplicit-function-declaration |-- x86_64-buildonly-randconfig-004-20241106 | |-- kernel-sched-topology.c:error:implicit-declaration-of-function-register_sysctl_init | |-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_enter | |-- kernel-workqueue.c:error:implicit-declaration-of-function-printk_safe_exit | `-- mm-memcontrol.c:error:implicit-declaration-of-function-ksm_process_profit |-- x86_64-buildonly-randconfig-005-20241106 | |-- arch-x86-kernel-paravirt.c:error:CALL_INSN_OPCODE-undeclared-(first-use-in-this-function) | |-- arch-x86-kernel-paravirt.c:error:CALL_INSN_SIZE-undeclared-(first-use-in-this-function) | `-- arch-x86-kernel-paravirt.c:error:implicit-declaration-of-function-__text_gen_insn |-- x86_64-kexec | `-- kernel-trace-trace_uprobe.o:warning:objtool:__uprobe_perf_func:unreachable-instruction |-- x86_64-randconfig-003-20241106 | |-- security-integrity-ima-ima.h:warning:struct-ima_digest-declared-inside-parameter-list-will-not-be-visible-outside-of-this-definition-or-declaration | `-- security-integrity-ima-ima_main.c:error:too-few-arguments-to-function-ima_appraise_measurement |-- x86_64-randconfig-006-20241106 | `-- drivers-net-ipvlan-ipvlan_main.c:warning:variable-old_prog-set-but-not-used |-- x86_64-randconfig-013-20241106 | `-- drivers-gpu-drm-nouveau-nvkm-subdev-clk-pllnv04.o:warning:objtool:nv04_pll_calc-falls-through-to-next-function-asanmodule_ctor() |-- x86_64-randconfig-014-20241106 | `-- drivers-usb-cdns3-debug.h:warning:sprintf-argument-may-overlap-destination-object-field |-- x86_64-randconfig-015-20241106 | |-- arch-x86-events-zhaoxin-uncore.c:warning:cluster_id-is-used-uninitialized | |-- arch-x86-events-zhaoxin-uncore.c:warning:subnode_id-is-used-uninitialized | |-- security-integrity-ima-ima.h:warning:struct-ima_digest-declared-inside-parameter-list-will-not-be-visible-outside-of-this-definition-or-declaration | `-- security-integrity-ima-ima_main.c:error:too-few-arguments-to-function-ima_appraise_measurement |-- x86_64-randconfig-074-20241106 | `-- drivers-net-ipvlan-ipvlan_main.c:warning:variable-old_prog-set-but-not-used `-- x86_64-randconfig-161-20241029 `-- drivers-gpu-drm-ast-ast_mm.c-ast_pci_host_is_5c01()-error:we-previously-assumed-child-could-be-null-(see-line-) elapsed time: 754m configs tested: 35 configs skipped: 128 tested configs: arm64 allmodconfig clang-20 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20241106 gcc-14.1.0 arm64 randconfig-002-20241106 gcc-14.1.0 arm64 randconfig-003-20241106 clang-20 arm64 randconfig-004-20241106 clang-20 x86_64 allnoconfig clang-19 x86_64 allyesconfig clang-19 x86_64 buildonly-randconfig-001-20241106 clang-19 x86_64 buildonly-randconfig-002-20241106 clang-19 x86_64 buildonly-randconfig-003-20241106 clang-19 x86_64 buildonly-randconfig-004-20241106 gcc-12 x86_64 buildonly-randconfig-005-20241106 gcc-12 x86_64 buildonly-randconfig-006-20241106 clang-19 x86_64 defconfig gcc-11 x86_64 kexec clang-19 x86_64 randconfig-001-20241106 clang-19 x86_64 randconfig-002-20241106 gcc-11 x86_64 randconfig-003-20241106 gcc-12 x86_64 randconfig-004-20241106 gcc-12 x86_64 randconfig-005-20241106 clang-19 x86_64 randconfig-006-20241106 gcc-11 x86_64 randconfig-011-20241106 gcc-11 x86_64 randconfig-012-20241106 gcc-12 x86_64 randconfig-013-20241106 clang-19 x86_64 randconfig-014-20241106 gcc-12 x86_64 randconfig-015-20241106 gcc-12 x86_64 randconfig-016-20241106 gcc-12 x86_64 randconfig-071-20241106 gcc-12 x86_64 randconfig-072-20241106 gcc-12 x86_64 randconfig-073-20241106 clang-19 x86_64 randconfig-074-20241106 gcc-12 x86_64 randconfig-075-20241106 clang-19 x86_64 randconfig-076-20241106 gcc-12 x86_64 rhel-8.3 gcc-12 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] selinux: clarify return code in filename_trans_read_helper_compat()
by Yi Yang 06 Nov '24

06 Nov '24

From: Ondrej Mosnacek <omosnace(a)redhat.com> mainline inclusion from mainline-v6.10-rc1 commit 4e551db0426472ca305a2f3284b25af763bfe57d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB1MNX CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- For the "conflicting/duplicate rules" branch in filename_trans_read_helper_compat() the Smatch static checker reports: security/selinux/ss/policydb.c:1953 filename_trans_read_helper_compat() warn: missing error code 'rc' While the value of rc will already always be zero here, it is not obvious that it's the case and that it's the intended return value (Smatch expects rc to be assigned within 5 lines from the goto). Therefore, add an explicit assignment just before the goto to make the intent more clear and the code less error-prone. Fixes: c3a276111ea2 ("selinux: optimize storage of filename transitions") Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/selinux/722b90c4-1f4b-42ff-a6c2-108ea262bd10@moroto… Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- security/selinux/ss/policydb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c index 2d528f699a22..f70399373588 100644 --- a/security/selinux/ss/policydb.c +++ b/security/selinux/ss/policydb.c @@ -1921,6 +1921,7 @@ static int filename_trans_read_helper_compat(struct policydb *p, void *fp) if (unlikely(ebitmap_get_bit(&datum->stypes, stype - 1))) { /* conflicting/duplicate rules are ignored */ datum = NULL; + rc = 0; goto out; } if (likely(datum->otype == otype)) -- 2.25.1

2 1

[PATCH OLK-5.10] selinux: clarify return code in filename_trans_read_helper_compat()
by Yi Yang 06 Nov '24

06 Nov '24

From: Ondrej Mosnacek <omosnace(a)redhat.com> mainline inclusion from mainline-v6.10-rc1 commit 4e551db0426472ca305a2f3284b25af763bfe57d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB1MNX CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- For the "conflicting/duplicate rules" branch in filename_trans_read_helper_compat() the Smatch static checker reports: security/selinux/ss/policydb.c:1953 filename_trans_read_helper_compat() warn: missing error code 'rc' While the value of rc will already always be zero here, it is not obvious that it's the case and that it's the intended return value (Smatch expects rc to be assigned within 5 lines from the goto). Therefore, add an explicit assignment just before the goto to make the intent more clear and the code less error-prone. Fixes: c3a276111ea2 ("selinux: optimize storage of filename transitions") Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/selinux/722b90c4-1f4b-42ff-a6c2-108ea262bd10@moroto… Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- security/selinux/ss/policydb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c index 82cfeab16217..2f15ab8534b2 100644 --- a/security/selinux/ss/policydb.c +++ b/security/selinux/ss/policydb.c @@ -1923,6 +1923,7 @@ static int filename_trans_read_helper_compat(struct policydb *p, void *fp) if (unlikely(ebitmap_get_bit(&datum->stypes, stype - 1))) { /* conflicting/duplicate rules are ignored */ datum = NULL; + rc = 0; goto out; } if (likely(datum->otype == otype)) -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 1231/1231] arch/arm64/kernel/mpam/mpam_mon.c:48: warning: Cannot understand * @rmid_mon_exclusive_all List of allocated RMIDs with
by kernel test robot 06 Nov '24

06 Nov '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: e33ed48bc600febcdca9e71e43cf224934dadc4f commit: 0f728d63ce7a19f1dd0dbde79197248e7c4accf6 [1231/1231] arm64/mpam: Add wait queue for monitor alloc and free config: arm64-randconfig-001-20241029 (https://download.01.org/0day-ci/archive/20241106/202411061140.gNjqbgZ7-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241106/202411061140.gNjqbgZ7-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/202411061140.gNjqbgZ7-lkp@intel.com/ All warnings (new ones prefixed by >>): >> arch/arm64/kernel/mpam/mpam_mon.c:48: warning: Cannot understand * @rmid_mon_exclusive_all List of allocated RMIDs with on line 48 - I thought it was a doc line >> arch/arm64/kernel/mpam/mpam_mon.c:54: warning: Cannot understand * @rmid_mon_wait_all List of allocated RMIDs with default on line 54 - I thought it was a doc line >> arch/arm64/kernel/mpam/mpam_mon.c:62: warning: Cannot understand * @rmid_entry - The entry in the mon list. on line 62 - I thought it was a doc line vim +48 arch/arm64/kernel/mpam/mpam_mon.c 46 47 /** > 48 * @rmid_mon_exclusive_all List of allocated RMIDs with 49 * exclusive available mon. 50 */ 51 static LIST_HEAD(rmid_mon_exclusive_all); 52 53 /** > 54 * @rmid_mon_wait_all List of allocated RMIDs with default 55 * 0 mon and wait for exclusive available mon. 56 */ 57 static LIST_HEAD(rmid_mon_wait_all); 58 59 static u32 rmid_ptrs_len; 60 61 /** > 62 * @rmid_entry - The entry in the mon list. 63 */ 64 static struct rmid_entry *rmid_ptrs; 65 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1] static_call: Handle module init failure correctly in static_call_del_module()
by Gu Bowen 06 Nov '24

06 Nov '24

From: Thomas Gleixner <tglx(a)linutronix.de> stable inclusion from stable-v6.1.113 commit b566c7d8a2de403ccc9d8a06195e19bbb386d0e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYR8E CVE: CVE-2024-50002 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4b30051c4864234ec57290c3d142db7c88f10d8a ] Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer. Fixes: 9183c3f9ed71 ("static_call: Add inline static call infrastructure") Closes: https://lore.kernel.org/all/20230915082126.4187913-1-ruanjinjie@huawei.com Reported-by: Jinjie Ruan <ruanjinjie(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Tested-by: Jinjie Ruan <ruanjinjie(a)huawei.com> Link: https://lore.kernel.org/r/87zfon6b0s.ffs@tglx Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: kernel/static_call.c kernel/static_call_inline.c [Commit 8fd4ddda2f49(static_call: Don't make __static_call_return0 static) rename kernel/static_call.c to kernel/static_call_inline.c which not merge] Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- kernel/static_call.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/kernel/static_call.c b/kernel/static_call.c index a5df28b2bc1b..63e7c2efc5cd 100644 --- a/kernel/static_call.c +++ b/kernel/static_call.c @@ -406,6 +406,17 @@ static void static_call_del_module(struct module *mod) for (site = start; site < stop; site++) { key = static_call_key(site); + + /* + * If the key was not updated due to a memory allocation + * failure in __static_call_init() then treating key::sites + * as key::mods in the code below would cause random memory + * access and #GP. In that case all subsequent sites have + * not been touched either, so stop iterating. + */ + if (!static_call_key_has_mods(key)) + break; + if (key == prev_key) continue; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] f2fs: fix to check atomic_file in f2fs ioctl interfaces
by Gu Bowen 06 Nov '24

06 Nov '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.1.113 commit 26b07bd2e1f124b0e430c8d250023f7205c549c3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYQSF CVE: CVE-2024-49859 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit bfe5c02654261bfb8bd9cb174a67f3279ea99e58 upstream. Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/f2fs/file.c [There is context conflicts due to commit d6dd477436957(f2fs: do not allow to defragment files have FI_COMPRESS_RELEASED) not merge in f2fs_defragment_range().] Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- fs/f2fs/file.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 0b355f00225b..12351851cb2e 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -2614,6 +2614,11 @@ static int f2fs_defragment_range(struct f2fs_sb_info *sbi, inode_lock(inode); + if (f2fs_is_atomic_file(inode)) { + err = -EINVAL; + goto out; + } + /* writeback all dirty pages in the range */ err = filemap_write_and_wait_range(inode->i_mapping, range->start, range->start + range->len - 1); @@ -2821,6 +2826,11 @@ static int f2fs_move_file_range(struct file *file_in, loff_t pos_in, goto out; } + if (f2fs_is_atomic_file(src) || f2fs_is_atomic_file(dst)) { + ret = -EINVAL; + goto out_unlock; + } + ret = -EINVAL; if (pos_in + len > src->i_size || pos_in + len < pos_in) goto out_unlock; @@ -3267,6 +3277,11 @@ static int f2fs_ioc_set_pin_file(struct file *filp, unsigned long arg) goto out; } + if (f2fs_is_atomic_file(inode)) { + ret = -EINVAL; + goto out; + } + if (!pin) { clear_inode_flag(inode, FI_PIN_FILE); f2fs_i_gc_failures_write(inode, 0); -- 2.25.1

2 1

openEuler Kernel SIG双周例会
by openEuler conference 06 Nov '24

06 Nov '24

您好！ Kernel 邀请您参加 2024-11-08 14:00 召开的WeLink会议(自动录制) 会议主题：openEuler Kernel SIG双周例会会议内容： 1. 进展update 2. 征集中（可回复本邮件申请，也可直接填写至会议纪要看板）会议链接：https://meeting.huaweicloud.com:36443/#/j/983782327 会议纪要：https://etherpad.openeuler.org/p/Kernel-meetings 更多资讯尽在：https://www.openeuler.org/zh/ Hello! Kernel invites you to attend the WeLink conference(auto recording) will be held at 2024-11-08 14:00, The subject of the conference is openEuler Kernel SIG双周例会, Summary: 1. 进展update 2. 征集中（可回复本邮件申请，也可直接填写至会议纪要看板） You can join the meeting at https://meeting.huaweicloud.com:36443/#/j/983782327. Add topics at https://etherpad.openeuler.org/p/Kernel-meetings. More information: https://www.openeuler.org/en/

1 0

[PATCH OLK-6.6] NFSD: Mark filecache "down" if init fails
by Li Lingfeng 06 Nov '24

06 Nov '24

From: Chuck Lever <chuck.lever(a)oracle.com> stable inclusion from stable-v6.6.57 commit 4ab072325c621e0e4fadff991c7a00379a16a037 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB22IQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dc0d0f885aa422f621bc1c2124133eff566b0bc8 ] NeilBrown says: > The handling of NFSD_FILE_CACHE_UP is strange. nfsd_file_cache_init() > sets it, but doesn't clear it on failure. So if nfsd_file_cache_init() > fails for some reason, nfsd_file_cache_shutdown() would still try to > clean up if it was called. Reported-by: NeilBrown <neilb(a)suse.de> Fixes: c7b824c3d06c ("NFSD: Replace the "init once" mechanism") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/filecache.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c index 5c9f8f8404d5..6f2bcbfde45e 100644 --- a/fs/nfsd/filecache.c +++ b/fs/nfsd/filecache.c @@ -718,7 +718,7 @@ nfsd_file_cache_init(void) ret = rhltable_init(&nfsd_file_rhltable, &nfsd_file_rhash_params); if (ret) - return ret; + goto out; ret = -ENOMEM; nfsd_filecache_wq = alloc_workqueue("nfsd_filecache", 0, 0); @@ -770,6 +770,8 @@ nfsd_file_cache_init(void) INIT_DELAYED_WORK(&nfsd_filecache_laundrette, nfsd_file_gc_worker); out: + if (ret) + clear_bit(NFSD_FILE_CACHE_UP, &nfsd_file_flags); return ret; out_notifier: lease_unregister_notifier(&nfsd_file_lease_notifier); -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] nfs: fix rpc_task use-after-free when open and close different files concurrently
by Li Lingfeng 06 Nov '24

06 Nov '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB20ED CVE: NA -------------------------------- Commit b5e9ee1ed8bb("[Huawei] NFSv4: release seqid when open failed for nfs4.0") describes a scenario where a file system is forcibly unmounted when different files are opened concurrently. There is another similar issue where performing concurrent operations of opening file B, closing file A, and unmounting while file A is open which can trigger a UAF of rpc_task. T1: OPEN fileB T2: CLOSE fileA nfs4_do_open ... .rpc_call_prepare nfs_wait_on_sequence // insert to sequence list(T1) // This is the first entry, // and continue. nfs4_do_close .rpc_call_prepare nfs_wait_on_sequence // insert to sequence list(T2) // This is the second entry, // and wait. [T3 wake up T2 here] ... rpc_put_task // finish rpc_task and free it .rpc_call_done nfs_release_seqid list_first_entry // get T1 from list rpc_wake_up_queued_task // wake up T1, UAF _nfs4_open_and_get_state _nfs4_open_and_get_state _nfs4_opendata_to_nfs4_state nfs_release_seqid // remove T1 from list T3: UMOUNT nfs_umount_begin rpc_killall_tasks rpc_signal_task // get T2 from clnt->cl_tasks rpc_wake_up_queued_task_set_status rpc_wake_up_task_queue_set_status_locked rpc_wake_up_task_on_wq_queue_action_locked __rpc_do_wake_up_task_on_wq rpc_make_runnable wake_up_bit // wake up T2 Although the rpc_task corresponding to T1 has been freed, its seqid has not been removed from the sequence list. Additionally, even though T2 is the last task in the list, the current logic of nfs_release_seqid allows T2 to access tasks inserted before it, which can trigger UAF. Fix it by using nfs_release_seqid_inorder instead of nfs_release_seqid in nfs4_close_done. Fixes: 72211dbe727f ("NFSv4: Release the sequence id before restarting a CLOSE rpc call") Link: https://lore.kernel.org/all/b9924cd2-253a-6c44-3331-56310f13df0b@huawei.com/ Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index b19a738dd2e1..94f73294b8d6 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -3403,7 +3403,7 @@ static void nfs4_close_done(struct rpc_task *task, void *data) res_stateid, calldata->arg.fmode); out_release: task->tk_status = 0; - nfs_release_seqid(calldata->arg.seqid); + nfs_release_seqid_inorder(calldata->arg.seqid); nfs_refresh_inode(calldata->inode, &calldata->fattr); dprintk("%s: done, ret = %d!\n", __func__, task->tk_status); return; -- 2.31.1

2 1

2024

2023

2022

2021

2020

2019

Kernel November 2024