- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] dma-direct: Leak pages on dma_set_decrypted() failure
by Jinjiang Tu 31 May '24

31 May '24

From: Rick Edgecombe <rick.p.edgecombe(a)intel.com> mainline inclusion from mainline-v6.9-rc1 commit b9fa16949d18e06bdf728a560f5c8af56d2bdcaf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QGIS CVE: CVE-2024-35939 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On TDX it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. DMA could free decrypted/shared pages if dma_set_decrypted() fails. This should be a rare case. Just leak the pages in this case instead of freeing them. Signed-off-by: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Conflicts: kernel/dma/direct.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- kernel/dma/direct.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index f13493c54629..9f08d81ce1f8 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -243,7 +243,7 @@ void *dma_direct_alloc(struct device *dev, size_t size, err = set_memory_decrypted((unsigned long)ret, PFN_UP(size)); if (err) - goto out_free_pages; + goto out_leak_pages; } memset(ret, 0, size); @@ -270,6 +270,8 @@ void *dma_direct_alloc(struct device *dev, size_t size, out_free_pages: __dma_direct_free_pages(dev, page, size); return NULL; +out_leak_pages: + return NULL; } void dma_direct_free(struct device *dev, size_t size, @@ -333,7 +335,7 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size, ret = page_address(page); if (force_dma_unencrypted(dev)) { if (set_memory_decrypted((unsigned long)ret, PFN_UP(size))) - goto out_free_pages; + goto out_leak_pages; } memset(ret, 0, size); *dma_handle = phys_to_dma_direct(dev, page_to_phys(page)); @@ -341,6 +343,8 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size, out_free_pages: __dma_direct_free_pages(dev, page, size); return NULL; +out_leak_pages: + return NULL; } void dma_direct_free_pages(struct device *dev, size_t size, -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-35808
by Li Nan 31 May '24

31 May '24

Li Nan (2): md/dm-raid: don't call md_reap_sync_thread() directly md/dm-raid: don't clear MD_RECOVERY_FROZEN after setting frozen drivers/md/md.h | 2 ++ drivers/md/dm-raid.c | 16 ++++++++-------- drivers/md/md.c | 6 ++++-- 3 files changed, 14 insertions(+), 10 deletions(-) -- 2.39.2

2 3

[PATCH OLK-5.10 0/2] CVE-2024-35808
by Li Nan 31 May '24

31 May '24

Li Nan (2): md/dm-raid: don't call md_reap_sync_thread() directly md/dm-raid: don't clear MD_RECOVERY_FROZEN after setting frozen drivers/md/md.h | 2 ++ drivers/md/dm-raid.c | 16 ++++++++-------- drivers/md/md.c | 6 ++++-- 3 files changed, 14 insertions(+), 10 deletions(-) -- 2.39.2

2 3

[openeuler:OLK-6.6 9622/9794] arch/x86/kernel/zhaoxin_kh40000.c:35:15: sparse: sparse: symbol 'zhaoxin_patch_code' was not declared. Should it be static?
by kernel test robot 31 May '24

31 May '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 147f67b8431ec3c45060ee19e8458bec4354b6b8 commit: 4332dbb07181359cccca3ba757ef54e434fb1296 [9622/9794] Add kh40000_direct_dma_ops for KH-40000 platform config: x86_64-randconfig-123-20240531 (https://download.01.org/0day-ci/archive/20240531/202405311007.oNegiICq-lkp@…) compiler: gcc-12 (Ubuntu 12.3.0-9ubuntu2) 12.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240531/202405311007.oNegiICq-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/202405311007.oNegiICq-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> arch/x86/kernel/zhaoxin_kh40000.c:35:15: sparse: sparse: symbol 'zhaoxin_patch_code' was not declared. Should it be static? vim +/zhaoxin_patch_code +35 arch/x86/kernel/zhaoxin_kh40000.c 34 > 35 unsigned long zhaoxin_patch_code = ZHAOXIN_PATCH_CODE_DEFAULT; 36 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1] locking/ww_mutex/test: Fix potential workqueue corruption
by Xie XiuQi 31 May '24

31 May '24

From: John Stultz <jstultz(a)google.com> stable inclusion from stable-v5.10.202 commit 9ed2d68b3925145f5f51c46559484881d6082f75 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9RFIG CVE: CVE-2023-52836 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit bccdd808902f8c677317cec47c306e42b93b849e ] In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished. Often this would cause strange crashes as the mutexes would be freed while they were being used. Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them. Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting. It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely. So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns. Signed-off-by: John Stultz <jstultz(a)google.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Link: https://lore.kernel.org/r/20230922043616.19282-3-jstultz@google.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: sanglipeng <sanglipeng1(a)jd.com> Signed-off-by: Xie XiuQi <xiexiuqi(a)huawei.com> --- kernel/locking/test-ww_mutex.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex.c index 3e82f449b4ff..da36997d8742 100644 --- a/kernel/locking/test-ww_mutex.c +++ b/kernel/locking/test-ww_mutex.c @@ -426,7 +426,6 @@ static void stress_inorder_work(struct work_struct *work) } while (!time_after(jiffies, stress->timeout)); kfree(order); - kfree(stress); } struct reorder_lock { @@ -491,7 +490,6 @@ static void stress_reorder_work(struct work_struct *work) list_for_each_entry_safe(ll, ln, &locks, link) kfree(ll); kfree(order); - kfree(stress); } static void stress_one_work(struct work_struct *work) @@ -512,8 +510,6 @@ static void stress_one_work(struct work_struct *work) break; } } while (!time_after(jiffies, stress->timeout)); - - kfree(stress); } #define STRESS_INORDER BIT(0) @@ -524,15 +520,24 @@ static void stress_one_work(struct work_struct *work) static int stress(int nlocks, int nthreads, unsigned int flags) { struct ww_mutex *locks; - int n; + struct stress *stress_array; + int n, count; locks = kmalloc_array(nlocks, sizeof(*locks), GFP_KERNEL); if (!locks) return -ENOMEM; + stress_array = kmalloc_array(nthreads, sizeof(*stress_array), + GFP_KERNEL); + if (!stress_array) { + kfree(locks); + return -ENOMEM; + } + for (n = 0; n < nlocks; n++) ww_mutex_init(&locks[n], &ww_class); + count = 0; for (n = 0; nthreads; n++) { struct stress *stress; void (*fn)(struct work_struct *work); @@ -556,9 +561,7 @@ static int stress(int nlocks, int nthreads, unsigned int flags) if (!fn) continue; - stress = kmalloc(sizeof(*stress), GFP_KERNEL); - if (!stress) - break; + stress = &stress_array[count++]; INIT_WORK(&stress->work, fn); stress->locks = locks; @@ -573,6 +576,7 @@ static int stress(int nlocks, int nthreads, unsigned int flags) for (n = 0; n < nlocks; n++) ww_mutex_destroy(&locks[n]); + kfree(stress_array); kfree(locks); return 0; -- 2.20.1

2 1

[PATCH openEuler-22.03-LTS-SP1] efi/capsule-loader: fix incorrect allocation size
by Kaixiong Yu 31 May '24

31 May '24

From: Arnd Bergmann <arnd(a)arndb.de> stable inclusion from stable-v5.10.212 commit 537e3f49dbe88881a6f0752beaa596942d9efd64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q8LN CVE: CVE-2024-27413 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e ] gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here. Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/firmware/efi/capsule-loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/capsule-loader.c b/drivers/firmware/efi/capsule-loader.c index 3e8d4b51a814..97bafb5f7038 100644 --- a/drivers/firmware/efi/capsule-loader.c +++ b/drivers/firmware/efi/capsule-loader.c @@ -292,7 +292,7 @@ static int efi_capsule_open(struct inode *inode, struct file *file) return -ENOMEM; } - cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); + cap_info->phys = kzalloc(sizeof(phys_addr_t), GFP_KERNEL); if (!cap_info->phys) { kfree(cap_info->pages); kfree(cap_info); -- 2.25.1

2 1

[PATCH OLK-5.10] efi/capsule-loader: fix incorrect allocation size
by Kaixiong Yu 31 May '24

31 May '24

From: Arnd Bergmann <arnd(a)arndb.de> stable inclusion from stable-v5.10.212 commit 537e3f49dbe88881a6f0752beaa596942d9efd64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q8LN CVE: CVE-2024-27413 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e ] gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here. Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/firmware/efi/capsule-loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/capsule-loader.c b/drivers/firmware/efi/capsule-loader.c index 3e8d4b51a814..97bafb5f7038 100644 --- a/drivers/firmware/efi/capsule-loader.c +++ b/drivers/firmware/efi/capsule-loader.c @@ -292,7 +292,7 @@ static int efi_capsule_open(struct inode *inode, struct file *file) return -ENOMEM; } - cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); + cap_info->phys = kzalloc(sizeof(phys_addr_t), GFP_KERNEL); if (!cap_info->phys) { kfree(cap_info->pages); kfree(cap_info); -- 2.25.1

2 1

[PATCH OLK-5.10] cvm: clean code for cvm init
by Ju Fu 31 May '24

31 May '24

virtcca inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I9TM0T -------------------------------- clean code for cvm init Signed-off-by: Ju Fu <fuju1(a)huawei.com> --- arch/arm64/include/asm/kvm_pgtable.h | 3 -- arch/arm64/include/asm/kvm_tmi.h | 5 +++ arch/arm64/kvm/arm.c | 35 -------------------- arch/arm64/kvm/cvm.c | 49 +++++++++++++++++++++++++--- arch/arm64/kvm/hyp/vgic-v3-sr.c | 19 ----------- 5 files changed, 49 insertions(+), 62 deletions(-) diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h index 2068ec591..f5dff6d40 100644 --- a/arch/arm64/include/asm/kvm_pgtable.h +++ b/arch/arm64/include/asm/kvm_pgtable.h @@ -53,9 +53,6 @@ enum kvm_pgtable_prot { KVM_PGTABLE_PROT_PBHA3 = BIT(62), }; -#define TMI_NO_MEASURE_CONTENT U(0) -#define TMI_MEASURE_CONTENT U(1) - #define PAGE_HYP (KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W) #define PAGE_HYP_EXEC (KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_X) #define PAGE_HYP_RO (KVM_PGTABLE_PROT_R) diff --git a/arch/arm64/include/asm/kvm_tmi.h b/arch/arm64/include/asm/kvm_tmi.h index 68a2da685..536594017 100644 --- a/arch/arm64/include/asm/kvm_tmi.h +++ b/arch/arm64/include/asm/kvm_tmi.h @@ -211,6 +211,9 @@ struct tmi_tec_run { #define U(_x) (_x##U) +#define TMI_NO_MEASURE_CONTENT U(0) +#define TMI_MEASURE_CONTENT U(1) + /* * SMC_TMM_INIT_COMPLETE is the only function in the TMI that originates from * the CVM world and is handled by the SPMD. The remaining functions are @@ -384,6 +387,8 @@ unsigned long cvm_psci_vcpu_affinity_info(struct kvm_vcpu *vcpu, unsigned long target_affinity, unsigned long lowest_affinity_level); int kvm_cvm_vcpu_set_events(struct kvm_vcpu *vcpu, bool serror_pending, bool ext_dabt_pending); +int kvm_create_cvm_vm(struct kvm *kvm); +int kvm_init_cvm_vm(struct kvm *kvm); #endif #endif diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 16cff3900..363f62073 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -145,41 +145,6 @@ static void set_default_csv2(struct kvm *kvm) kvm->arch.pfr0_csv2 = 1; } -static int kvm_create_cvm_vm(struct kvm *kvm) -{ - struct cvm *cvm; - - if (!static_key_enabled(&kvm_cvm_is_available)) - return -EFAULT; - - if (kvm->arch.cvm) { - kvm_info("cvm already create.\n"); - return 0; - } - - kvm->arch.cvm = kzalloc(sizeof(struct cvm), GFP_KERNEL_ACCOUNT); - if (!kvm->arch.cvm) - return -ENOMEM; - - cvm = (struct cvm *)kvm->arch.cvm; - cvm->is_cvm = true; - return 0; -} - -static int kvm_init_cvm_vm(struct kvm *kvm) -{ - struct tmi_cvm_params *params; - struct cvm *cvm = (struct cvm *)kvm->arch.cvm; - - params = kzalloc(PAGE_SIZE, GFP_KERNEL_ACCOUNT); - if (!params) - return -ENOMEM; - - cvm->params = params; - - return 0; -} - /** * kvm_arch_init_vm - initializes a VM data structure * @kvm: pointer to the KVM struct diff --git a/arch/arm64/kvm/cvm.c b/arch/arm64/kvm/cvm.c index 7f4de2522..70521fec8 100644 --- a/arch/arm64/kvm/cvm.c +++ b/arch/arm64/kvm/cvm.c @@ -158,8 +158,10 @@ int kvm_arm_create_cvm(struct kvm *kvm) if (!kvm_is_cvm(kvm) || kvm_cvm_state(kvm) != CVM_STATE_NONE) return 0; - if (!cvm->params) - return -EFAULT; + if (!cvm->params) { + ret = -EFAULT; + goto out; + } ret = cvm_vmid_reserve(); if (ret < 0) @@ -184,12 +186,14 @@ int kvm_arm_create_cvm(struct kvm *kvm) } WRITE_ONCE(cvm->state, CVM_STATE_NEW); - kfree(cvm->params); - cvm->params = NULL; - return ret; + ret = 0; out: kfree(cvm->params); cvm->params = NULL; + if (ret < 0) { + kfree(cvm); + kvm->arch.cvm = NULL; + } return ret; } @@ -835,3 +839,38 @@ int kvm_cvm_vcpu_set_events(struct kvm_vcpu *vcpu, } return 0; } + +int kvm_create_cvm_vm(struct kvm *kvm) +{ + struct cvm *cvm; + + if (!static_key_enabled(&kvm_cvm_is_available)) + return -EFAULT; + + if (kvm->arch.cvm) { + kvm_info("cvm already create.\n"); + return 0; + } + + kvm->arch.cvm = kzalloc(sizeof(struct cvm), GFP_KERNEL_ACCOUNT); + if (!kvm->arch.cvm) + return -ENOMEM; + + cvm = (struct cvm *)kvm->arch.cvm; + cvm->is_cvm = true; + return 0; +} + +int kvm_init_cvm_vm(struct kvm *kvm) +{ + struct tmi_cvm_params *params; + struct cvm *cvm = (struct cvm *)kvm->arch.cvm; + + params = kzalloc(PAGE_SIZE, GFP_KERNEL_ACCOUNT); + if (!params) + return -ENOMEM; + + cvm->params = params; + + return 0; +} diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c index a45e68ef2..452f4cacd 100644 --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c @@ -229,25 +229,6 @@ void __vgic_v3_save_state(struct vgic_v3_cpu_if *cpu_if) } } -#ifdef CONFIG_CVM_HOST -void __vgic_v3_restore_tec_state(struct vgic_v3_cpu_if *cpu_if, - u64 *entry_hcr, - u64 *entry_lrs) -{ - u64 used_lrs = cpu_if->used_lrs; - int i; - - *entry_hcr = cpu_if->vgic_hcr; - for (i = 0; i < kvm_vgic_global_state.nr_lr; ++i) { - if (i < used_lrs) { - entry_lrs[i] = cpu_if->vgic_lr[i]; - } else { - entry_lrs[i] = 0; - } - } -} -#endif - void __vgic_v3_restore_state(struct vgic_v3_cpu_if *cpu_if) { u64 used_lrs = cpu_if->used_lrs; -- 2.25.1.windows.1

2 1

[PATCH openEuler-1.0-LTS] net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()
by Pu Lehui 31 May '24

31 May '24

From: Zhou Qingyang <zhou1615(a)umn.edu> stable inclusion from stable-v4.19.220 commit 676dc7d9b15bf8733233a2db1ec3f9091ab34275 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9S1ZN CVE: CVE-2021-47541 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit addad7643142f500080417dd7272f49b7a185570 upstream. In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and tmp->tx_cq will be freed on the error path of mlx4_en_copy_priv(). After that mlx4_en_alloc_resources() is called and there is a dereference of &tmp->tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to a use after free problem on failure of mlx4_en_copy_priv(). Fix this bug by adding a check of mlx4_en_copy_priv() This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_MLX4_EN=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: ec25bc04ed8e ("net/mlx4_en: Add resilience in low memory systems") Signed-off-by: Zhou Qingyang <zhou1615(a)umn.edu> Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com> Link: https://lore.kernel.org/r/20211130164438.190591-1-zhou1615@umn.edu Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c index 47eee3e083ec..e60ca4c86482 100644 --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c @@ -2279,9 +2279,14 @@ int mlx4_en_try_alloc_resources(struct mlx4_en_priv *priv, bool carry_xdp_prog) { struct bpf_prog *xdp_prog; - int i, t; + int i, t, ret; - mlx4_en_copy_priv(tmp, priv, prof); + ret = mlx4_en_copy_priv(tmp, priv, prof); + if (ret) { + en_warn(priv, "%s: mlx4_en_copy_priv() failed, return\n", + __func__); + return ret; + } if (mlx4_en_alloc_resources(tmp)) { en_warn(priv, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] efi/capsule-loader: fix incorrect allocation size
by Kaixiong Yu 31 May '24

31 May '24

From: Arnd Bergmann <arnd(a)arndb.de> stable inclusion from stable-v5.10.212 commit 537e3f49dbe88881a6f0752beaa596942d9efd64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q8LN CVE: CVE-2024-27413 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fccfa646ef3628097d59f7d9c1a3e84d4b6bb45e ] gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here. Fixes: f24c4d478013 ("efi/capsule-loader: Reinstate virtual capsule mapping") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/firmware/efi/capsule-loader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/capsule-loader.c b/drivers/firmware/efi/capsule-loader.c index 94aae1e67c99..43fefab75524 100644 --- a/drivers/firmware/efi/capsule-loader.c +++ b/drivers/firmware/efi/capsule-loader.c @@ -293,7 +293,7 @@ static int efi_capsule_open(struct inode *inode, struct file *file) return -ENOMEM; } - cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); + cap_info->phys = kzalloc(sizeof(phys_addr_t), GFP_KERNEL); if (!cap_info->phys) { kfree(cap_info->pages); kfree(cap_info); -- 2.25.1

2 1

2024

2023

2022

2021

2020

2019

Kernel