- Kernel - mailweb.openeuler.org

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

21 May '24

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

2 3

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

21 May '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 5708160127a606e51a136509cfe0a9448a09849a commit: e8483fcd43fc1dbb8d21bb7eacce804cbab6a7c6 [21291/22450] spi: add phytium spi support config: x86_64-buildonly-randconfig-004-20240521 (https://download.01.org/0day-ci/archive/20240521/202405211804.T84TVKIc-lkp@…) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240521/202405211804.T84TVKIc-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202405211804.T84TVKIc-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/spi/spi-phytium-plat.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

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

21 May '24

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

2 1

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

21 May '24

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

2 1

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

21 May '24

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

2 1

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

21 May '24

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

2 1

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

21 May '24

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

2 1

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

21 May '24

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

2 1

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

21 May '24

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

2 1

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

21 May '24

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

2 1