- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c
by Zeng Heng 06 Jan '25

06 Jan '25

From: Dipendra Khadka <kdipendra88(a)gmail.com> stable inclusion from stable-v6.6.64 commit 52c63a6a27d3178fab533fcfb4baa2ed5b8608a3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDOQ CVE: CVE-2024-56679 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0fbc7a5027c6f7f2c785adae3dcec22b2f2b69b3 ] Add error pointer check after calling otx2_mbox_get_rsp(). Fixes: ab58a416c93f ("octeontx2-pf: cn10k: Get max mtu supported from admin function") Signed-off-by: Dipendra Khadka <kdipendra88(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c index b3064377510e..47adccf7a777 100644 --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c @@ -1837,6 +1837,10 @@ u16 otx2_get_max_mtu(struct otx2_nic *pfvf) if (!rc) { rsp = (struct nix_hw_info *) otx2_mbox_get_rsp(&pfvf->mbox.mbox, 0, &req->hdr); + if (IS_ERR(rsp)) { + rc = PTR_ERR(rsp); + goto out; + } /* HW counts VLAN insertion bytes (8 for double tag) * irrespective of whether SQE is requesting to insert VLAN -- 2.25.1

2 1

[PATCH OLK-6.6 V1] sched: Fix bpf cpustats refcount leak
by Cheng Yu 06 Jan '25

06 Jan '25

From: Hui Tang <tanghui20(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBG1V2 CVE: NA -------------------------------- Refcount 'cpustats->usage' is clear in bpf_sched_cpu_stats_of which triggering WARNING bpf_sched_cpustats_release called. refcount_t: underflow; use-after-free. WARNING: CPU: 31 PID: 9517 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Call trace: refcount_warn_saturate+0xf4/0x148 bpf_sched_cpustats_release+0xa4/0xc0 bpf_prog_62f48e1f0ef32ae3_select_rq+0x360/0x398 bpf_trampoline_6442463850+0x8c/0x1000 bpf_sched_cfs_select_rq+0x8/0x18 select_task_rq_fair+0x250/0x4c8 Ctx is clear in bpf_sched_cpustats_create, so it not need to clear in bpf_sched_cpu_stats_of. Fixes: ace175278fa1 ("sched: Add kfunc to get cpu statistics") Signed-off-by: Hui Tang <tanghui20(a)huawei.com> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- kernel/sched/bpf_sched.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/sched/bpf_sched.c b/kernel/sched/bpf_sched.c index 2958b3029d38..1973cfacc079 100644 --- a/kernel/sched/bpf_sched.c +++ b/kernel/sched/bpf_sched.c @@ -152,7 +152,6 @@ __bpf_kfunc s32 bpf_sched_cpu_stats_of(int cpuid, return -EINVAL; rq = cpu_rq(cpu); - memset(ctx, 0, sizeof(*ctx)); SCHED_WARN_ON(!rcu_read_lock_held()); /* nr_running */ -- 2.25.1

2 1

[PATCH OLK-6.6] KVM: arm64: Don't retire aborted MMIO instruction
by Zhang Kunbo 06 Jan '25

06 Jan '25

From: Oliver Upton <oliver.upton(a)linux.dev> stable inclusion from stable-v6.6.66 commit ea6b5d98fea4ee8cb443ea98fda520909e90d30e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAG3 CVE: CVE-2024-53196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e735a5da64420a86be370b216c269b5dd8e830e2 ] Returning an abort to the guest for an unsupported MMIO access is a documented feature of the KVM UAPI. Nevertheless, it's clear that this plumbing has seen limited testing, since userspace can trivially cause a WARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 The splat is complaining that KVM is advancing PC while an exception is pending, i.e. that KVM is retiring the MMIO instruction despite a pending synchronous external abort. Womp womp. Fix the glaring UAPI bug by skipping over all the MMIO emulation in case there is a pending synchronous exception. Note that while userspace is capable of pending an asynchronous exception (SError, IRQ, or FIQ), it is still safe to retire the MMIO instruction in this case as (1) they are by definition asynchronous, and (2) KVM relies on hardware support for pending/delivering these exceptions instead of the software state machine for advancing PC. Cc: stable(a)vger.kernel.org Fixes: da345174ceca ("KVM: arm/arm64: Allow user injection of external data aborts") Reported-by: Alexander Potapenko <glider(a)google.com> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20241025203106.3529261-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/arm64/kvm/mmio.c [ different return polarity introduced by this commit not merged: cc81b6dfc3bc8 ("KVM: arm64: Change kvm_handle_mmio_return() return polarity") ] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/arm64/kvm/mmio.c | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c index 40d6d056e261..bf5de05cb7a8 100644 --- a/arch/arm64/kvm/mmio.c +++ b/arch/arm64/kvm/mmio.c @@ -73,6 +73,31 @@ unsigned long kvm_mmio_read_buf(const void *buf, unsigned int len) return data; } +static bool kvm_pending_sync_exception(struct kvm_vcpu *vcpu) +{ + if (!vcpu_get_flag(vcpu, PENDING_EXCEPTION)) + return false; + + if (vcpu_el1_is_32bit(vcpu)) { + switch (vcpu_get_flag(vcpu, EXCEPT_MASK)) { + case unpack_vcpu_flag(EXCEPT_AA32_UND): + case unpack_vcpu_flag(EXCEPT_AA32_IABT): + case unpack_vcpu_flag(EXCEPT_AA32_DABT): + return true; + default: + return false; + } + } else { + switch (vcpu_get_flag(vcpu, EXCEPT_MASK)) { + case unpack_vcpu_flag(EXCEPT_AA64_EL1_SYNC): + case unpack_vcpu_flag(EXCEPT_AA64_EL2_SYNC): + return true; + default: + return false; + } + } +} + /** * kvm_handle_mmio_return -- Handle MMIO loads after user space emulation * or in-kernel IO emulation @@ -85,8 +110,11 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu) unsigned int len; int mask; - /* Detect an already handled MMIO return */ - if (unlikely(!vcpu->mmio_needed)) + /* + * Detect if the MMIO return was already handled or if userspace aborted + * the MMIO access. + */ + if (unlikely(!vcpu->mmio_needed || kvm_pending_sync_exception(vcpu))) return 0; vcpu->mmio_needed = 0; -- 2.34.1

2 1

[PATCH OLK-6.6] f2fs: fix to account dirty data in __get_secs_required()
by Liu Mingrui 06 Jan '25

06 Jan '25

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.6.64 commit f1b8bfe8d2f2fdf905d37c174d5bc1cd2b6910c5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBA6RL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1acd73edbbfef2c3c5b43cba4006a7797eca7050 ] It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/ Fixes: 4354994f097d ("f2fs: checkpoint disabling") Cc: Daniel Rosenberg <drosen(a)google.com> Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- fs/f2fs/segment.h | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index 952970166d5d..cd2ec6acc717 100644 --- a/fs/f2fs/segment.h +++ b/fs/f2fs/segment.h @@ -559,18 +559,21 @@ static inline int reserved_sections(struct f2fs_sb_info *sbi) } static inline bool has_curseg_enough_space(struct f2fs_sb_info *sbi, - unsigned int node_blocks, unsigned int dent_blocks) + unsigned int node_blocks, unsigned int data_blocks, + unsigned int dent_blocks) { - unsigned segno, left_blocks; + unsigned int segno, left_blocks, blocks; int i; - /* check current node sections in the worst case. */ - for (i = CURSEG_HOT_NODE; i <= CURSEG_COLD_NODE; i++) { + /* check current data/node sections in the worst case. */ + for (i = CURSEG_HOT_DATA; i < NR_PERSISTENT_LOG; i++) { segno = CURSEG_I(sbi, i)->segno; left_blocks = CAP_BLKS_PER_SEC(sbi) - get_ckpt_valid_blocks(sbi, segno, true); - if (node_blocks > left_blocks) + + blocks = i <= CURSEG_COLD_DATA ? data_blocks : node_blocks; + if (blocks > left_blocks) return false; } @@ -584,8 +587,9 @@ static inline bool has_curseg_enough_space(struct f2fs_sb_info *sbi, } /* - * calculate needed sections for dirty node/dentry - * and call has_curseg_enough_space + * calculate needed sections for dirty node/dentry and call + * has_curseg_enough_space, please note that, it needs to account + * dirty data as well in lfs mode when checkpoint is disabled. */ static inline void __get_secs_required(struct f2fs_sb_info *sbi, unsigned int *lower_p, unsigned int *upper_p, bool *curseg_p) @@ -594,19 +598,30 @@ static inline void __get_secs_required(struct f2fs_sb_info *sbi, get_pages(sbi, F2FS_DIRTY_DENTS) + get_pages(sbi, F2FS_DIRTY_IMETA); unsigned int total_dent_blocks = get_pages(sbi, F2FS_DIRTY_DENTS); + unsigned int total_data_blocks = 0; unsigned int node_secs = total_node_blocks / CAP_BLKS_PER_SEC(sbi); unsigned int dent_secs = total_dent_blocks / CAP_BLKS_PER_SEC(sbi); + unsigned int data_secs = 0; unsigned int node_blocks = total_node_blocks % CAP_BLKS_PER_SEC(sbi); unsigned int dent_blocks = total_dent_blocks % CAP_BLKS_PER_SEC(sbi); + unsigned int data_blocks = 0; + + if (f2fs_lfs_mode(sbi) && + unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) { + total_data_blocks = get_pages(sbi, F2FS_DIRTY_DATA); + data_secs = total_data_blocks / CAP_BLKS_PER_SEC(sbi); + data_blocks = total_data_blocks % CAP_BLKS_PER_SEC(sbi); + } if (lower_p) - *lower_p = node_secs + dent_secs; + *lower_p = node_secs + dent_secs + data_secs; if (upper_p) *upper_p = node_secs + dent_secs + - (node_blocks ? 1 : 0) + (dent_blocks ? 1 : 0); + (node_blocks ? 1 : 0) + (dent_blocks ? 1 : 0) + + (data_blocks ? 1 : 0); if (curseg_p) *curseg_p = has_curseg_enough_space(sbi, - node_blocks, dent_blocks); + node_blocks, data_blocks, dent_blocks); } static inline bool has_not_enough_free_secs(struct f2fs_sb_info *sbi, -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] gpiolib: fix memory use-after-free in gpiochip_setup_dev()
by He Yujie 06 Jan '25

06 Jan '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB8UN5 CVE: CVE-2022-48975 -------------------------------- Commit aa1e2bfdc899 attempt to fix a CVE problem, but the patch conflicted with current version. When the patch is adapted, an error is introduced in the function of gpiochip_add_data_with_key. After the gdev is released, the gdev is still accessed, resulting in use-after-free. The value of gdev->ngpio is assigned from gc->ngpio and is not changed during the processing of function. Therefore, this patch changes gdev->ngpio to gc->ngpio to solve the above use-after-free problem. Fixes: aa1e2bfdc899 ("gpiolib: fix memory leak in gpiochip_setup_dev()") Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/gpio/gpiolib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 206d73810876..07d26ca22c2c 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -796,7 +796,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data, err_print_message: /* failures here can mean systems won't boot... */ pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", __func__, - base, base + gdev->ngpio - 1, + base, base + (int)gc->ngpio - 1, gc->label ? : "generic", ret); return ret; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25

etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/task_mmu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0

2 2

[PATCH OLK-6.6 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25

etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/etmem_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0

2 2

[PATCH openEuler-25.03 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25

etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/etmem_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0

1 1

[PATCH openEuler-22.03-LTS-SP1 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25

etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/task_mmu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0

2 2

[PATCH openEuler-25.03 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 06 Jan '25

06 Jan '25

etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/etmem_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0

1 1