- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/4] ext4: improve buffered write with more than one blocks_per_folio part 2
by Zhang Yi 30 Jul '24

30 Jul '24

Drop unnecessary state_lock in ifs, which could improve some (~10%) buffer write performance. I tested it through UnixBench on my x86 and arm64 virtual machine with 50GB ramdisk & xfs filesystem, the results shows below. 1. UnixBench Test on xfs: ./Run -i 1 -c 1 fstime-w Before: x86 File Write 1024 bufsize 2000 maxblocks 524708.0 KBps arm64 File Write 1024 bufsize 2000 maxblocks 801965.0 KBps After: x86 File Write 1024 bufsize 2000 maxblocks 571315.0 KBps arm64 File Write 1024 bufsize 2000 maxblocks 876077.0 KBps 2. Libmacro test in ext4: Before: Running: pwrite_u1k# bin/pwrite -E -C 200 -L -S -W -N pwrite_u1k -s 1k -I 500 -f /var/tmp/libmicro.1240/data prc thr usecs/call samples errors cnt/samp size pwrite_u1k 1 1 0.86016 167 0 200 1024 After: Running: pwrite_u1k# bin/pwrite -E -C 200 -L -S -W -N pwrite_u1k -s 1k -I 500 -f /var/tmp/libmicro.1957/data prc thr usecs/call samples errors cnt/samp size pwrite_u1k 1 1 0.7699 190 0 200 1024 Thanks, Yi. Matthew Wilcox (Oracle) (2): iomap: hold state_lock over call to ifs_set_range_uptodate() iomap: protect read_bytes_pending with the state_lock Zhang Yi (2): iomap: drop unnecessary state_lock when setting ifs uptodate bits iomap: drop unnecessary state_lock when changing ifs dirty bits fs/iomap/buffered-io.c | 73 +++++++++++++++++++++++++----------------- 1 file changed, 43 insertions(+), 30 deletions(-) -- 2.39.2

2 5

[PATCH OLK-5.10] iommu/arm-smmu-v3: Fix the compile warning
by Zhang Zekun 30 Jul '24

30 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAGJ97 --------------------------------------- Fix the following compile warning: WARNING: modpost: vmlinux.o(.text+0x854620): ... The function arm_smmu_device_probe() references the variable __initdata arm_smmu_v3_plat_info. This is often because arm_smmu_device_probe lacks a __initdata annotation or the annotation of arm_smmu_v3_plat_info is wrong. Fixes: 3bced619d7dc ("iommu/arm-smmu-v3: Change the style to identify the the hisi_platform") Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index c5c25be54fd5..cedc1eda7250 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -5244,7 +5244,7 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) } #ifdef CONFIG_ACPI -static struct acpi_platform_list arm_smmu_v3_plat_info[] __initdata = { +static struct acpi_platform_list arm_smmu_v3_plat_info[] = { /* HiSilicon Hip09 Platform */ {"HISI ", "HIP09 ", 0, ACPI_SIG_IORT, greater_than_or_equal, "Erratum #162100602", 0}, -- 2.17.1

2 1

[PATCH OLK-5.10] usb: gadget: ncm: Fix handling of zero block length packets
by Wang Hai 30 Jul '24

30 Jul '24

From: Krishna Kurapati <quic_kriskura(a)quicinc.com> stable inclusion from stable-v5.10.215 commit ef846cdbd100f7f9dc045e8bcd7fe4b3a3713c03 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92E CVE: CVE-2024-35825 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70 upstream. While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero. Cc: stable(a)vger.kernel.org Fixes: 427694cfaafa ("usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call") Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> Reviewed-by: Maciej Żenczykowski <maze(a)google.com> Link: https://lore.kernel.org/r/20240228115441.2105585-1-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/usb/gadget/function/f_ncm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index e3b89b7c1d67..f3410dc25d12 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -1357,7 +1357,7 @@ static int ncm_unwrap_ntb(struct gether *port, if (to_process == 1 && (*(unsigned char *)(ntb_ptr + block_len) == 0x00)) { to_process--; - } else if (to_process > 0) { + } else if ((to_process > 0) && (block_len != 0)) { ntb_ptr = (unsigned char *)(ntb_ptr + block_len); goto parse_ntb; } -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] Fix CVE-2024-41069
by Zheng Yejian 30 Jul '24

30 Jul '24

Amadeusz Sławiński (2): ASoC: topology: Fix references to freed memory ASoC: topology: Fix route memory corruption sound/soc/soc-topology.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) -- 2.25.1

2 3

[PATCH OLK-5.10 0/2] Fix CVE-2024-41069
by Zheng Yejian 30 Jul '24

30 Jul '24

Amadeusz Sławiński (2): ASoC: topology: Fix references to freed memory ASoC: topology: Fix route memory corruption sound/soc/soc-topology.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/3] Fix CVE-2024-41069
by Zheng Yejian 30 Jul '24

30 Jul '24

Amadeusz Sławiński (3): ASoC: topology: Fix references to freed memory ASoC: topology: Do not assign fields that are already set ASoC: topology: Fix route memory corruption sound/soc/soc-topology.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) -- 2.25.1

2 4

[PATCH OLK-5.10] iommu/arm-smmu-v3: Fix the compile warning
by Zhang Zekun 30 Jul '24

30 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAGJ97 --------------------------------------- Fix the following compile warning: WARNING: modpost: vmlinux.o(.text+0x854620): ... The function arm_smmu_device_probe() references the variable __initdata arm_smmu_v3_plat_info. This is often because arm_smmu_device_probe lacks a __initdata annotation or the annotation of arm_smmu_v3_plat_info is wrong. Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index c5c25be54fd5..cedc1eda7250 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -5244,7 +5244,7 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) } #ifdef CONFIG_ACPI -static struct acpi_platform_list arm_smmu_v3_plat_info[] __initdata = { +static struct acpi_platform_list arm_smmu_v3_plat_info[] = { /* HiSilicon Hip09 Platform */ {"HISI ", "HIP09 ", 0, ACPI_SIG_IORT, greater_than_or_equal, "Erratum #162100602", 0}, -- 2.17.1

2 1

[PATCH OLK-6.6] firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files
by Jinjie Ruan 30 Jul '24

30 Jul '24

From: Richard Fitzgerald <rf(a)opensource.cirrus.com> stable inclusion from stable-v6.6.41 commit 16d76857d6b5426f41b587d0bb925de3f25bfb21 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMN CVE: CVE-2024-41056 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 680e126ec0400f6daecf0510c5bb97a55779ff03 ] Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files. In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240708144855.385332-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/firmware/cirrus/cs_dsp.c [Due to not merge commit 76ea8e13aaefd firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/firmware/cirrus/cs_dsp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/cirrus/cs_dsp.c b/drivers/firmware/cirrus/cs_dsp.c index 79d4254d1f9b..fe0fb7d635f0 100644 --- a/drivers/firmware/cirrus/cs_dsp.c +++ b/drivers/firmware/cirrus/cs_dsp.c @@ -1109,7 +1109,7 @@ static inline void cs_dsp_coeff_parse_alg(struct cs_dsp *dsp, const u8 **data, blk->id = le32_to_cpu(raw->id); blk->name = raw->name; - blk->name_len = strlen(raw->name); + blk->name_len = strnlen(raw->name, ARRAY_SIZE(raw->name)); blk->ncoeff = le32_to_cpu(raw->ncoeff); break; default: @@ -1142,7 +1142,7 @@ static inline void cs_dsp_coeff_parse_coeff(struct cs_dsp *dsp, const u8 **data, blk->offset = le16_to_cpu(raw->hdr.offset); blk->mem_type = le16_to_cpu(raw->hdr.type); blk->name = raw->name; - blk->name_len = strlen(raw->name); + blk->name_len = strnlen(raw->name, ARRAY_SIZE(raw->name)); blk->ctl_type = le16_to_cpu(raw->ctl_type); blk->flags = le16_to_cpu(raw->flags); blk->len = le32_to_cpu(raw->len); -- 2.34.1

2 1

[PATCH] iommu/arm-smmu-v3: Fix the compile warning
by Zhang Zekun 30 Jul '24

30 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAGJ97 --------------------------------------- Fix the following compile warning: WARNING: modpost: vmlinux.o(.text+0x854620): ... The function arm_smmu_device_probe() references the variable __initdata arm_smmu_v3_plat_info. This is often because arm_smmu_device_probe lacks a __initdata annotation or the annotation of arm_smmu_v3_plat_info is wrong. Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index c5c25be54fd5..cedc1eda7250 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -5244,7 +5244,7 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) } #ifdef CONFIG_ACPI -static struct acpi_platform_list arm_smmu_v3_plat_info[] __initdata = { +static struct acpi_platform_list arm_smmu_v3_plat_info[] = { /* HiSilicon Hip09 Platform */ {"HISI ", "HIP09 ", 0, ACPI_SIG_IORT, greater_than_or_equal, "Erratum #162100602", 0}, -- 2.17.1

1 0

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2024-41069
by Zheng Yejian 30 Jul '24

30 Jul '24

Amadeusz Sławiński (2): ASoC: topology: Fix references to freed memory ASoC: topology: Fix route memory corruption sound/soc/soc-topology.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 30 Jul '24

30 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PTACH OLK-6.6 0/4] ext4: improve buffered write with more than one blocks_per_folio part 2
by Zhang Yi 30 Jul '24

30 Jul '24

Drop unnecessary state_lock in ifs, which could improve some (~10%) buffer write performance. I tested it through UnixBench on my x86 and arm64 virtual machine with 50GB ramdisk & xfs filesystem, the results shows below. 1. UnixBench Test on xfs: ./Run -i 1 -c 1 fstime-w Before: x86 File Write 1024 bufsize 2000 maxblocks 524708.0 KBps arm64 File Write 1024 bufsize 2000 maxblocks 801965.0 KBps After: x86 File Write 1024 bufsize 2000 maxblocks 571315.0 KBps arm64 File Write 1024 bufsize 2000 maxblocks 876077.0 KBps 2. Libmacro test in ext4: Before: Running: pwrite_u1k# bin/pwrite -E -C 200 -L -S -W -N pwrite_u1k -s 1k -I 500 -f /var/tmp/libmicro.1240/data prc thr usecs/call samples errors cnt/samp size pwrite_u1k 1 1 0.86016 167 0 200 1024 After: Running: pwrite_u1k# bin/pwrite -E -C 200 -L -S -W -N pwrite_u1k -s 1k -I 500 -f /var/tmp/libmicro.1957/data prc thr usecs/call samples errors cnt/samp size pwrite_u1k 1 1 0.7699 190 0 200 1024 Thanks, Yi. Matthew Wilcox (Oracle) (2): iomap: hold state_lock over call to ifs_set_range_uptodate() iomap: protect read_bytes_pending with the state_lock Zhang Yi (2): iomap: drop unnecessary state_lock when setting ifs uptodate bits iomap: drop unnecessary state_lock when changing ifs dirty bits fs/iomap/buffered-io.c | 73 +++++++++++++++++++++++++----------------- 1 file changed, 43 insertions(+), 30 deletions(-) -- 2.39.2

1 4

[PATCH 0/2] Fix CVE-2024-41069
by Zheng Yejian 30 Jul '24

30 Jul '24

Amadeusz Sławiński (2): ASoC: topology: Fix references to freed memory ASoC: topology: Fix route memory corruption sound/soc/soc-topology.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) -- 2.25.1

1 2

[PATCH OLK-6.6 0/4] BMA: Fix DMA reset problem and change the version
by Peng Zhang 30 Jul '24

30 Jul '24

From: Wujiahai <wujiahai(a)huawei.com> 1. Resolved the problem that the DMA reset does not meet the expectation due to the mismatch between the register configuration and the communication transmission direction during DMA reset. 2. Change the iBMA driver version. Wujiahai (4): BMA/edma_drv: Fix DMA reset problem and change the version number. BMA/cdev_drv: Change the version number. BMA/veth_drv: Change the version number. BMA/kbox_drv: Change the version number. drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c | 2 +- drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.h | 2 +- drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c | 4 ++-- drivers/net/ethernet/huawei/bma/kbox_drv/kbox_include.h | 2 +- drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.h | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) -- 2.27.0

2 5

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 30 Jul '24

30 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/4] BMA: Fix DMA reset problem and change the version number
by Li Nan 30 Jul '24

30 Jul '24

From: Wujiahai <wujiahai(a)huawei.com> 1. Resolved the problem that the DMA reset does not meet the expectation due to the mismatch between the register configuration and the communication transmission direction during DMA reset. 2. Change the iBMA driver version. Wujiahai (4): BMA/edma_drv: Fix DMA reset problem and change the version number. BMA/cdev_drv: Change the version number. BMA/veth_drv: Change the version number. BMA/kbox_drv: Change the version number. drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c | 2 +- drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.h | 2 +- drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c | 4 ++-- drivers/net/ethernet/huawei/bma/kbox_drv/kbox_include.h | 2 +- drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.h | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) -- 2.27.0

2 5

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 30 Jul '24

30 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[openeuler:openEuler-1.0-LTS 15750/23378] fs/.tmp_select.o: warning: objtool: poll_select_finish()+0xc6: can't find switch jump table
by kernel test robot 30 Jul '24

30 Jul '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 87e97edb9d08052dcb1df91827fb9dd9edecf612 commit: 44ae3d3e5f1f99c0fd5f040e4da88b0c5b3ec76b [15750/23378] select: shift restore_saved_sigmask_unless() into poll_select_copy_remaining() config: x86_64-buildonly-randconfig-001-20240729 (https://download.01.org/0day-ci/archive/20240730/202407301459.O1t38ucj-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/20240730/202407301459.O1t38ucj-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/202407301459.O1t38ucj-lkp@intel.com/ All warnings (new ones prefixed by >>): >> fs/.tmp_select.o: warning: objtool: poll_select_finish()+0xc6: can't find switch jump table -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] filelock: Fix fcntl/close race recovery compat path
by Yifan Qiao 30 Jul '24

30 Jul '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v6.6.43 commit 73ae349534ebc377328e7d21891e589626c6e82c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF4 CVE: CVE-2024-41020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream. When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable(a)kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh(a)google.com> Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 76ad05f8070a..ae62ee373704 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2504,8 +2504,9 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by releasing the - * lock that was just acquired. There is no need to do that when we're + * Detect close/fcntl races and recover by zapping all POSIX locks + * associated with this file and our files_struct, just like on + * filp_flush(). There is no need to do that when we're * unlocking though, or for OFD locks. */ if (!error && file_lock->fl_type != F_UNLCK && @@ -2520,9 +2521,7 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, f = files_lookup_fd_locked(files, fd); spin_unlock(&files->file_lock); if (f != filp) { - file_lock->fl_type = F_UNLCK; - error = do_lock_file_wait(filp, cmd, file_lock); - WARN_ON_ONCE(error); + locks_remove_posix(filp, files); error = -EBADF; } } -- 2.39.2

2 1

[PATCH OLK-5.10 0/2] CVE-2024-41020
by Yifan Qiao 30 Jul '24

30 Jul '24

Eric W. Biederman (1): file: Factor files_lookup_fd_locked out of fcheck_files Jann Horn (1): filelock: Fix fcntl/close race recovery compat path include/linux/fdtable.h | 7 +++++++ fs/file.c | 2 +- fs/locks.c | 23 ++++++++++++----------- fs/proc/fd.c | 2 +- 4 files changed, 21 insertions(+), 13 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-41020
by Yifan Qiao 30 Jul '24

30 Jul '24

Eric W. Biederman (1): file: Factor files_lookup_fd_locked out of fcheck_files Jann Horn (1): filelock: Fix fcntl/close race recovery compat path include/linux/fdtable.h | 7 +++++++ fs/file.c | 2 +- fs/locks.c | 23 ++++++++++++----------- fs/proc/fd.c | 2 +- 4 files changed, 21 insertions(+), 13 deletions(-) -- 2.39.2

2 3

[PATCH OLK-5.10] pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
by Yang Yingliang 30 Jul '24

30 Jul '24

From: Hagar Hemdan <hagarhem(a)amazon.com> mainline inclusion from mainline-v6.10-rc6 commit adec57ff8e66aee632f3dd1f93787c13d112b7a1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP4 CVE: CVE-2024-42090 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Suggested-by: Maximilian Heyne <mheyne(a)amazon.de> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Link: https://lore.kernel.org/r/20240604085838.3344-1-hagarhem@amazon.com Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/pinctrl/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c index 82b3cd6903c8..8ecb8dc19208 100644 --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -1084,8 +1084,8 @@ static struct pinctrl *create_pinctrl(struct device *dev, * an -EPROBE_DEFER later, as that is the worst case. */ if (ret == -EPROBE_DEFER) { - pinctrl_free(p, false); mutex_unlock(&pinctrl_maps_mutex); + pinctrl_free(p, false); return ERR_PTR(ret); } } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
by Yang Yingliang 30 Jul '24

30 Jul '24

From: Hagar Hemdan <hagarhem(a)amazon.com> mainline inclusion from mainline-v6.10-rc6 commit adec57ff8e66aee632f3dd1f93787c13d112b7a1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP4 CVE: CVE-2024-42090 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Suggested-by: Maximilian Heyne <mheyne(a)amazon.de> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Link: https://lore.kernel.org/r/20240604085838.3344-1-hagarhem@amazon.com Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/pinctrl/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c index 82b3cd6903c8..8ecb8dc19208 100644 --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -1084,8 +1084,8 @@ static struct pinctrl *create_pinctrl(struct device *dev, * an -EPROBE_DEFER later, as that is the worst case. */ if (ret == -EPROBE_DEFER) { - pinctrl_free(p, false); mutex_unlock(&pinctrl_maps_mutex); + pinctrl_free(p, false); return ERR_PTR(ret); } } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
by Yang Yingliang 30 Jul '24

30 Jul '24

From: Hagar Hemdan <hagarhem(a)amazon.com> mainline inclusion from mainline-v6.10-rc6 commit adec57ff8e66aee632f3dd1f93787c13d112b7a1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP4 CVE: CVE-2024-42090 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Suggested-by: Maximilian Heyne <mheyne(a)amazon.de> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Link: https://lore.kernel.org/r/20240604085838.3344-1-hagarhem@amazon.com Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/pinctrl/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c index b50968f0ce2e..f8952d01fc2c 100644 --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -1078,8 +1078,8 @@ static struct pinctrl *create_pinctrl(struct device *dev, * an -EPROBE_DEFER later, as that is the worst case. */ if (ret == -EPROBE_DEFER) { - pinctrl_free(p, false); mutex_unlock(&pinctrl_maps_mutex); + pinctrl_free(p, false); return ERR_PTR(ret); } } -- 2.25.1

2 1

[PATCH OLK-6.6 0/3] ovl: simplify ovl_parse_param_lowerdir()
by Zhihao Cheng 30 Jul '24

30 Jul '24

Christian Brauner (1): ovl: pass string to ovl_parse_layer() Zhihao Cheng (2): ovl: fix wrong lowerdir number check for parameter Opt_lowerdir ovl: ovl_parse_param_lowerdir: Add missed '\n' for pr_err fs/overlayfs/params.c | 49 ++++++++++--------------------------------- 1 file changed, 11 insertions(+), 38 deletions(-) -- 2.31.1

2 4

[PATCH openEuler-22.03-LTS-SP1] filelock: Fix fcntl/close race recovery compat path
by Yifan Qiao 30 Jul '24

30 Jul '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v4.19.319 commit a561145f3ae973ebf3e0aee41624e92a6c5cb38d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF4 CVE: CVE-2024-41020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream. When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable(a)kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh(a)google.com> Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 6e118955b9b6..7b805e2a7f7a 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2530,8 +2530,9 @@ int fcntl_setlk(unsigned int fd, struct file *filp, unsigned int cmd, error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by releasing the - * lock that was just acquired. There is no need to do that when we're + * Detect close/fcntl races and recover by zapping all POSIX locks + * associated with this file and our files_struct, just like on + * filp_flush(). There is no need to do that when we're * unlocking though, or for OFD locks. */ if (!error && file_lock->fl_type != F_UNLCK && @@ -2545,9 +2546,7 @@ int fcntl_setlk(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - file_lock->fl_type = F_UNLCK; - error = do_lock_file_wait(filp, cmd, file_lock); - WARN_ON_ONCE(error); + locks_remove_posix(filp, &current->files); error = -EBADF; } } -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] filelock: Fix fcntl/close race recovery compat path
by Yifan Qiao 30 Jul '24

30 Jul '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v4.19.319 commit a561145f3ae973ebf3e0aee41624e92a6c5cb38d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF4 CVE: CVE-2024-41020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream. When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable(a)kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh(a)google.com> Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 9dc72fda5e4e..532b728a8675 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2429,8 +2429,9 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by releasing the - * lock that was just acquired. There is no need to do that when we're + * Detect close/fcntl races and recover by zapping all POSIX locks + * associated with this file and our files_struct, just like on + * filp_flush(). There is no need to do that when we're * unlocking though, or for OFD locks. */ if (!error && file_lock->fl_type != F_UNLCK && @@ -2444,9 +2445,7 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - file_lock->fl_type = F_UNLCK; - error = do_lock_file_wait(filp, cmd, file_lock); - WARN_ON_ONCE(error); + locks_remove_posix(filp, &current->files); error = -EBADF; } } -- 2.39.2

2 1

[PATCH OLK-6.6] firmware: cs_dsp: Fix overflow checking of wmfw header
by Yipeng Zou 30 Jul '24

30 Jul '24

From: Richard Fitzgerald <rf(a)opensource.cirrus.com> stable inclusion from stable-v6.10.15 commit 3019b86bce16fbb5bc1964f3544d0ce7d0137278 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEMJ CVE: CVE-2024-41039 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer. The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footer But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfw_adsp2_sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfw_adsp2_sizes. This patch splits the length check into three separate parts. Each of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked separately before they are used. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") Link: https://patch.msgid.link/20240627141432.93056-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/firmware/cirrus/cs_dsp.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/firmware/cirrus/cs_dsp.c b/drivers/firmware/cirrus/cs_dsp.c index 79d4254d1f9b..f0c3c4011411 100644 --- a/drivers/firmware/cirrus/cs_dsp.c +++ b/drivers/firmware/cirrus/cs_dsp.c @@ -1267,6 +1267,10 @@ static unsigned int cs_dsp_adsp1_parse_sizes(struct cs_dsp *dsp, const struct wmfw_adsp1_sizes *adsp1_sizes; adsp1_sizes = (void *)&firmware->data[pos]; + if (sizeof(*adsp1_sizes) > firmware->size - pos) { + cs_dsp_err(dsp, "%s: file truncated\n", file); + return 0; + } cs_dsp_dbg(dsp, "%s: %d DM, %d PM, %d ZM\n", file, le32_to_cpu(adsp1_sizes->dm), le32_to_cpu(adsp1_sizes->pm), @@ -1283,6 +1287,10 @@ static unsigned int cs_dsp_adsp2_parse_sizes(struct cs_dsp *dsp, const struct wmfw_adsp2_sizes *adsp2_sizes; adsp2_sizes = (void *)&firmware->data[pos]; + if (sizeof(*adsp2_sizes) > firmware->size - pos) { + cs_dsp_err(dsp, "%s: file truncated\n", file); + return 0; + } cs_dsp_dbg(dsp, "%s: %d XM, %d YM %d PM, %d ZM\n", file, le32_to_cpu(adsp2_sizes->xm), le32_to_cpu(adsp2_sizes->ym), @@ -1322,7 +1330,6 @@ static int cs_dsp_load(struct cs_dsp *dsp, const struct firmware *firmware, struct regmap *regmap = dsp->regmap; unsigned int pos = 0; const struct wmfw_header *header; - const struct wmfw_adsp1_sizes *adsp1_sizes; const struct wmfw_footer *footer; const struct wmfw_region *region; const struct cs_dsp_region *mem; @@ -1338,10 +1345,8 @@ static int cs_dsp_load(struct cs_dsp *dsp, const struct firmware *firmware, ret = -EINVAL; - pos = sizeof(*header) + sizeof(*adsp1_sizes) + sizeof(*footer); - if (pos >= firmware->size) { - cs_dsp_err(dsp, "%s: file too short, %zu bytes\n", - file, firmware->size); + if (sizeof(*header) >= firmware->size) { + ret = -EOVERFLOW; goto out_fw; } @@ -1369,13 +1374,16 @@ static int cs_dsp_load(struct cs_dsp *dsp, const struct firmware *firmware, pos = sizeof(*header); pos = dsp->ops->parse_sizes(dsp, file, pos, firmware); + if ((pos == 0) || (sizeof(*footer) > firmware->size - pos)) { + ret = -EOVERFLOW; + goto out_fw; + } footer = (void *)&firmware->data[pos]; pos += sizeof(*footer); if (le32_to_cpu(header->len) != pos) { - cs_dsp_err(dsp, "%s: unexpected header length %d\n", - file, le32_to_cpu(header->len)); + ret = -EOVERFLOW; goto out_fw; } @@ -1501,6 +1509,9 @@ static int cs_dsp_load(struct cs_dsp *dsp, const struct firmware *firmware, cs_dsp_buf_free(&buf_list); kfree(text); + if (ret == -EOVERFLOW) + cs_dsp_err(dsp, "%s: file content overflows file data\n", file); + return ret; } -- 2.34.1

2 1

[PATCH OLK-5.10] drm/radeon: fix UBSAN warning in kv_dpm.c
by Kaixiong Yu 30 Jul '24

30 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> stable inclusion from stable-v5.10.221 commit febe794b83693257f21a23d2e03ea695a62449c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR1V CVE: CVE-2024-40988 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a498df5421fd737d11bfd152428ba6b1c8538321 upstream. Adds bounds check for sumo_vid_mapping_entry. Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/gpu/drm/radeon/sumo_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/radeon/sumo_dpm.c b/drivers/gpu/drm/radeon/sumo_dpm.c index 45d04996adf5..a80e2edb7c0f 100644 --- a/drivers/gpu/drm/radeon/sumo_dpm.c +++ b/drivers/gpu/drm/radeon/sumo_dpm.c @@ -1621,6 +1621,8 @@ void sumo_construct_vid_mapping_table(struct radeon_device *rdev, for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { if (table[i].ulSupportedSCLK != 0) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; vid_mapping_table->entries[table[i].usVoltageIndex].vid_2bit = -- 2.25.1

2 1

[PATCH OLK-5.10] filelock: fix potential use-after-free in posix_lock_inode
by Yifan Qiao 30 Jul '24

30 Jul '24

From: Jeff Layton <jlayton(a)kernel.org> stable inclusion from stable-v5.10.222 commit 7d4c14f4b511fd4c0dc788084ae59b4656ace58b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKN CVE: CVE-2024-41049 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1b3ec4f7c03d4b07bad70697d7e2f4088d2cfe92 ] Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen. Fixes: 74f6f5912693 ("locks: fix KASAN: use-after-free in trace_event_raw_event_filelock_lock") Link: https://lore.kernel.org/linux-fsdevel/724ffb0a2962e912ea62bb0515deadf39c325… Reported-by: Light Hsieh (謝明燈) <Light.Hsieh(a)mediatek.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Link: https://lore.kernel.org/r/20240702-filelock-6-10-v1-1-96e766aadc98@kernel.o… Reviewed-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/locks.c b/fs/locks.c index 4e4b36c330f9..f4504008a2ea 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1337,9 +1337,9 @@ static int posix_lock_inode(struct inode *inode, struct file_lock *request, locks_wake_up_blocks(left); } out: + trace_posix_lock_inode(inode, request, error); spin_unlock(&ctx->flc_lock); percpu_up_read(&file_rwsem); - trace_posix_lock_inode(inode, request, error); /* * Free any unused locks. */ -- 2.39.2

2 1

[PATCH OLK-6.6] drm/radeon: fix UBSAN warning in kv_dpm.c
by Kaixiong Yu 30 Jul '24

30 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> stable inclusion from stable-v5.10.221 commit febe794b83693257f21a23d2e03ea695a62449c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR1V CVE: CVE-2024-40988 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a498df5421fd737d11bfd152428ba6b1c8538321 upstream. Adds bounds check for sumo_vid_mapping_entry. Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/gpu/drm/radeon/sumo_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/radeon/sumo_dpm.c b/drivers/gpu/drm/radeon/sumo_dpm.c index d49c145db437..f7f1ddc6cdd8 100644 --- a/drivers/gpu/drm/radeon/sumo_dpm.c +++ b/drivers/gpu/drm/radeon/sumo_dpm.c @@ -1621,6 +1621,8 @@ void sumo_construct_vid_mapping_table(struct radeon_device *rdev, for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { if (table[i].ulSupportedSCLK != 0) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; vid_mapping_table->entries[table[i].usVoltageIndex].vid_2bit = -- 2.25.1

2 1

[PATCH OLK-5.10] filelock: fix potential use-after-free in posix_lock_inode
by Yifan Qiao 30 Jul '24

30 Jul '24

From: Jeff Layton <jlayton(a)kernel.org> stable inclusion from stable-v5.10.222 commit 7d4c14f4b511fd4c0dc788084ae59b4656ace58b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKN CVE: CVE-2024-41049 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1b3ec4f7c03d4b07bad70697d7e2f4088d2cfe92 ] Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen. Fixes: 74f6f5912693 ("locks: fix KASAN: use-after-free in trace_event_raw_event_filelock_lock") Link: https://lore.kernel.org/linux-fsdevel/724ffb0a2962e912ea62bb0515deadf39c325… Reported-by: Light Hsieh (謝明燈) <Light.Hsieh(a)mediatek.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Link: https://lore.kernel.org/r/20240702-filelock-6-10-v1-1-96e766aadc98@kernel.o… Reviewed-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/locks.c b/fs/locks.c index 4e4b36c330f9..f4504008a2ea 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1337,9 +1337,9 @@ static int posix_lock_inode(struct inode *inode, struct file_lock *request, locks_wake_up_blocks(left); } out: + trace_posix_lock_inode(inode, request, error); spin_unlock(&ctx->flc_lock); percpu_up_read(&file_rwsem); - trace_posix_lock_inode(inode, request, error); /* * Free any unused locks. */ -- 2.39.2

2 1

[PATCH OLK-6.6] filelock: fix potential use-after-free in posix_lock_inode
by Yifan Qiao 30 Jul '24

30 Jul '24

From: Jeff Layton <jlayton(a)kernel.org> stable inclusion from stable-v6.6.41 commit 432b06b69d1d354a171f7499141116536579eb6a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEKN CVE: CVE-2024-41049 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1b3ec4f7c03d4b07bad70697d7e2f4088d2cfe92 ] Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen. Fixes: 74f6f5912693 ("locks: fix KASAN: use-after-free in trace_event_raw_event_filelock_lock") Link: https://lore.kernel.org/linux-fsdevel/724ffb0a2962e912ea62bb0515deadf39c325… Reported-by: Light Hsieh (謝明燈) <Light.Hsieh(a)mediatek.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Link: https://lore.kernel.org/r/20240702-filelock-6-10-v1-1-96e766aadc98@kernel.o… Reviewed-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/locks.c b/fs/locks.c index 76ad05f8070a..fb717dae9029 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1314,9 +1314,9 @@ static int posix_lock_inode(struct inode *inode, struct file_lock *request, locks_wake_up_blocks(left); } out: + trace_posix_lock_inode(inode, request, error); spin_unlock(&ctx->flc_lock); percpu_up_read(&file_rwsem); - trace_posix_lock_inode(inode, request, error); /* * Free any unused locks. */ -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/radeon: fix UBSAN warning in kv_dpm.c
by Kaixiong Yu 30 Jul '24

30 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> stable inclusion from stable-v5.10.221 commit febe794b83693257f21a23d2e03ea695a62449c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR1V CVE: CVE-2024-40988 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a498df5421fd737d11bfd152428ba6b1c8538321 upstream. Adds bounds check for sumo_vid_mapping_entry. Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Kaixiong Yu <yukaixiong(a)huawei.com> --- drivers/gpu/drm/radeon/sumo_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/radeon/sumo_dpm.c b/drivers/gpu/drm/radeon/sumo_dpm.c index b95d5d390caf..6bde7f119d9c 100644 --- a/drivers/gpu/drm/radeon/sumo_dpm.c +++ b/drivers/gpu/drm/radeon/sumo_dpm.c @@ -1619,6 +1619,8 @@ void sumo_construct_vid_mapping_table(struct radeon_device *rdev, for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) { if (table[i].ulSupportedSCLK != 0) { + if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES) + continue; vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit = table[i].usVoltageID; vid_mapping_table->entries[table[i].usVoltageIndex].vid_2bit = -- 2.25.1

2 1

[PATCH OLK-6.6] fs/ntfs3: Add a check for attr_names and oatbl
by Yifan Qiao 30 Jul '24

30 Jul '24

From: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> stable inclusion from stable-v6.6.43 commit f3124d51e4e7b56a732419d8dc270e807252334f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAG8T5 CVE: CVE-2024-41018 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 702d4930eb06dcfda85a2fa67e8a1a27bfa2a845 upstream. Added out-of-bound checking for *ane (ATTR_NAME_ENTRY). Reported-by: lei lu <llfamsec(a)gmail.com> Fixes: 865e7a7700d93 ("fs/ntfs3: Reduce stack usage") Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/ntfs3/fslog.c | 38 ++++++++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/fs/ntfs3/fslog.c b/fs/ntfs3/fslog.c index 4085fe30bf48..2e2348f8e285 100644 --- a/fs/ntfs3/fslog.c +++ b/fs/ntfs3/fslog.c @@ -3722,6 +3722,8 @@ int log_replay(struct ntfs_inode *ni, bool *initialized) u64 rec_lsn, checkpt_lsn = 0, rlsn = 0; struct ATTR_NAME_ENTRY *attr_names = NULL; + u32 attr_names_bytes = 0; + u32 oatbl_bytes = 0; struct RESTART_TABLE *dptbl = NULL; struct RESTART_TABLE *trtbl = NULL; const struct RESTART_TABLE *rt; @@ -3736,6 +3738,7 @@ int log_replay(struct ntfs_inode *ni, bool *initialized) struct NTFS_RESTART *rst = NULL; struct lcb *lcb = NULL; struct OPEN_ATTR_ENRTY *oe; + struct ATTR_NAME_ENTRY *ane; struct TRANSACTION_ENTRY *tr; struct DIR_PAGE_ENTRY *dp; u32 i, bytes_per_attr_entry; @@ -4314,17 +4317,40 @@ int log_replay(struct ntfs_inode *ni, bool *initialized) lcb = NULL; check_attribute_names2: - if (rst->attr_names_len && oatbl) { - struct ATTR_NAME_ENTRY *ane = attr_names; - while (ane->off) { + if (attr_names && oatbl) { + off = 0; + for (;;) { + /* Check we can use attribute name entry 'ane'. */ + static_assert(sizeof(*ane) == 4); + if (off + sizeof(*ane) > attr_names_bytes) { + /* just ignore the rest. */ + break; + } + + ane = Add2Ptr(attr_names, off); + t16 = le16_to_cpu(ane->off); + if (!t16) { + /* this is the only valid exit. */ + break; + } + + /* Check we can use open attribute entry 'oe'. */ + if (t16 + sizeof(*oe) > oatbl_bytes) { + /* just ignore the rest. */ + break; + } + /* TODO: Clear table on exit! */ - oe = Add2Ptr(oatbl, le16_to_cpu(ane->off)); + oe = Add2Ptr(oatbl, t16); t16 = le16_to_cpu(ane->name_bytes); + off += t16 + sizeof(*ane); + if (off > attr_names_bytes) { + /* just ignore the rest. */ + break; + } oe->name_len = t16 / sizeof(short); oe->ptr = ane->name; oe->is_attr_name = 2; - ane = Add2Ptr(ane, - sizeof(struct ATTR_NAME_ENTRY) + t16); } } -- 2.39.2

2 1

[PATCH OLK-6.6 0/2] fix tick broadcast issue
by Yu Liao 30 Jul '24

30 Jul '24

Yu Liao (2): Revert "tick/broadcast-hrtimer: Prevent the timer device on broadcast duty CPU from being disabled" tick/broadcast: Make takeover of broadcast hrtimer reliable kernel/time/tick-broadcast-hrtimer.c | 13 ------------- kernel/time/tick-broadcast.c | 23 +++++++++++++++++++++++ 2 files changed, 23 insertions(+), 13 deletions(-) -- 2.33.0

2 3

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 30 Jul '24

30 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 30 Jul '24

30 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 30 Jul '24

30 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 30 Jul '24

30 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 30 Jul '24

30 Jul '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): kvm: add coda feature Signed-off-by: JunBin Li <lijunbin4(a)huawei.com> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.25.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/4] BMA: Fix DMA reset problem and change the version number
by Li Nan 30 Jul '24

30 Jul '24

From: Wujiahai <wujiahai(a)huawei.com> 1. Resolved the problem that the DMA reset does not meet the expectation due to the mismatch between the register configuration and the communication transmission direction during DMA reset. 2. Change the iBMA driver version. Wujiahai (4): BMA/edma_drv: Fix DMA reset problem and change the version number. BMA/cdev_drv: Change the version number. BMA/veth_drv: Change the version number. BMA/kbox_drv: Change the version number. drivers/net/ethernet/huawei/bma/cdev_drv/bma_cdev.c | 2 +- drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.h | 2 +- drivers/net/ethernet/huawei/bma/edma_drv/edma_host.c | 4 ++-- drivers/net/ethernet/huawei/bma/kbox_drv/kbox_include.h | 2 +- drivers/net/ethernet/huawei/bma/veth_drv/veth_hb.h | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) -- 2.27.0

2 5

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 87e97edb9d08052dcb1df91827fb9dd9edecf612
by kernel test robot 30 Jul '24

30 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 87e97edb9d08052dcb1df91827fb9dd9edecf612 !10227 MIPS: smp: fill in sibling and core maps earlier elapsed time: 727m configs tested: 35 configs skipped: 139 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 defconfig gcc-14.1.0 arm64 randconfig-001-20240729 gcc-14.1.0 arm64 randconfig-002-20240729 gcc-14.1.0 arm64 randconfig-003-20240729 gcc-14.1.0 arm64 randconfig-004-20240729 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240729 clang-18 x86_64 buildonly-randconfig-002-20240729 gcc-13 x86_64 buildonly-randconfig-003-20240729 gcc-10 x86_64 buildonly-randconfig-004-20240729 gcc-10 x86_64 buildonly-randconfig-005-20240729 gcc-10 x86_64 buildonly-randconfig-006-20240729 gcc-10 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240729 gcc-13 x86_64 randconfig-002-20240729 clang-18 x86_64 randconfig-003-20240729 clang-18 x86_64 randconfig-004-20240729 clang-18 x86_64 randconfig-005-20240729 clang-18 x86_64 randconfig-006-20240729 clang-18 x86_64 randconfig-011-20240729 gcc-8 x86_64 randconfig-012-20240729 gcc-8 x86_64 randconfig-013-20240729 gcc-13 x86_64 randconfig-014-20240729 clang-18 x86_64 randconfig-015-20240729 gcc-13 x86_64 randconfig-016-20240729 clang-18 x86_64 randconfig-071-20240729 gcc-13 x86_64 randconfig-072-20240729 gcc-13 x86_64 randconfig-073-20240729 clang-18 x86_64 randconfig-074-20240729 gcc-8 x86_64 randconfig-075-20240729 gcc-12 x86_64 randconfig-076-20240729 gcc-13 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6] BUILD SUCCESS fbff37d503211903d1acab770e4b9ee263d9d49f
by kernel test robot 29 Jul '24

29 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: fbff37d503211903d1acab770e4b9ee263d9d49f !9904 ext4: improve buffered write with more than one blocks_per_folio Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag |-- arm64-defconfig | |-- WARNING:modpost:vmlinux:section-mismatch-in-reference:arm_smmu_device_probe-(section:.text)-arm_smmu_v3_plat_info-(section:.init.data) | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- arm64-randconfig-003-20240729 | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- arm64-randconfig-004-20240729 | `-- WARNING:modpost:vmlinux:section-mismatch-in-reference:arm_smmu_device_probe-(section:.text)-arm_smmu_v3_plat_info-(section:.init.data) |-- loongarch-allmodconfig | `-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument |-- loongarch-defconfig | |-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- loongarch-randconfig-001-20240729 | |-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and `-- x86_64-allyesconfig `-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_topology.c:warning:stack-frame-size-()-exceeds-limit-()-in-kfd_topology_add_device elapsed time: 729m configs tested: 40 configs skipped: 134 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-20 arm64 allnoconfig gcc-14.1.0 arm64 defconfig gcc-14.1.0 arm64 randconfig-001-20240729 clang-17 arm64 randconfig-002-20240729 clang-20 arm64 randconfig-003-20240729 gcc-14.1.0 arm64 randconfig-004-20240729 clang-20 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch defconfig gcc-14.1.0 loongarch randconfig-001-20240729 gcc-14.1.0 loongarch randconfig-002-20240729 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240729 clang-18 x86_64 buildonly-randconfig-002-20240729 gcc-13 x86_64 buildonly-randconfig-003-20240729 gcc-10 x86_64 buildonly-randconfig-004-20240729 gcc-10 x86_64 buildonly-randconfig-005-20240729 gcc-10 x86_64 buildonly-randconfig-006-20240729 gcc-10 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240729 gcc-13 x86_64 randconfig-002-20240729 clang-18 x86_64 randconfig-003-20240729 clang-18 x86_64 randconfig-004-20240729 clang-18 x86_64 randconfig-005-20240729 clang-18 x86_64 randconfig-006-20240729 clang-18 x86_64 randconfig-011-20240729 gcc-8 x86_64 randconfig-012-20240729 gcc-8 x86_64 randconfig-013-20240729 gcc-13 x86_64 randconfig-014-20240729 clang-18 x86_64 randconfig-015-20240729 gcc-13 x86_64 randconfig-016-20240729 clang-18 x86_64 randconfig-071-20240729 gcc-13 x86_64 randconfig-072-20240729 gcc-13 x86_64 randconfig-073-20240729 clang-18 x86_64 randconfig-074-20240729 gcc-8 x86_64 randconfig-075-20240729 gcc-12 x86_64 randconfig-076-20240729 gcc-13 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-6.6] iommu/arm-smmu-v3: Reducing the CMD_SYNC times
by Zhang Zekun 29 Jul '24

29 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9G9TI ---------------------------------------- Benifiting from the hardware same address blocking mechanism. We only need to send the CMD_SYNC when creating pte entry other than lvl 3, this can reduce the amounts of CMD_SYNC times sent to avoiding the errata. Detecting the hardware ability by read the SMMU_USER_CONFIG1. Fixes: 46f0c5798ba5 ("iommu/arm-smmu-v3: Enable iotlb_sync_map according to SMMU_IIDR") Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 52 +++++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 ++ drivers/iommu/io-pgtable-arm.c | 5 ++ 3 files changed, 60 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 16217647fd67..6fa7b0b3e90c 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -2203,6 +2203,14 @@ static void arm_smmu_tlb_inv_page_nosync(struct iommu_iotlb_gather *gather, static void arm_smmu_tlb_inv_walk(unsigned long iova, size_t size, size_t granule, void *cookie) { +#ifdef CONFIG_HISILICON_ERRATUM_162100602 + struct arm_smmu_domain *smmu_domain = cookie; + + if (!size && smmu_domain->smmu->options & ARM_SMMU_OPT_SYNC_BATCH) { + arm_smmu_tlb_inv_range_domain(iova, granule, granule, true, cookie); + return; + } +#endif arm_smmu_tlb_inv_range_domain(iova, size, granule, false, cookie); } @@ -2736,6 +2744,9 @@ static int arm_smmu_iotlb_sync_map(struct iommu_domain *domain, if (!(smmu_domain->smmu->options & ARM_SMMU_OPT_SYNC_MAP)) return 0; + if (smmu_domain->smmu->options & ARM_SMMU_OPT_SYNC_BATCH) + return 0; + granule_size = 1 << __ffs(smmu_domain->domain.pgsize_bitmap); /* Add a SYNC command to sync io-pgtale to avoid errors in pgtable prefetch*/ @@ -4241,6 +4252,45 @@ static void arm_smmu_get_httu(struct arm_smmu_device *smmu, u32 reg) fw_features); } +#ifdef CONFIG_HISILICON_ERRATUM_162100602 +static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) +{ + u32 reg, i; + + if (!(smmu->options & ARM_SMMU_OPT_SYNC_MAP)) + return; + + smmu->options |= ARM_SMMU_OPT_SYNC_MAP; + + reg = readl_relaxed(smmu->base + ARM_SMMU_USER_CFG1); + reg = reg & GENMASK(15, 0); + for (i = 0; i < 8; i++) { + unsigned long val; + + val = (reg >> 2 * i) & GENMASK(1, 0); + switch (PAGE_SIZE) { + case SZ_4K: + if (!val) + return; + break; + case SZ_16K: + if (!val || val == 0x1) + return; + break; + case SZ_64K: + if (!val || val == 0x1 || val == 0x3) + return; + break; + default: + return; + } + } + smmu->options |= ARM_SMMU_OPT_SYNC_BATCH; +} +#else +static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) {} +#endif + static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) { u32 reg; @@ -4455,6 +4505,8 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) smmu->oas = 48; } + hisi_smmu_check_errata(smmu); + if (arm_smmu_ops.pgsize_bitmap == -1UL) arm_smmu_ops.pgsize_bitmap = smmu->pgsize_bitmap; else diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 859d21729882..bc34d5a6aab9 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -139,6 +139,8 @@ #define ARM_SMMU_GERROR_IRQ_CFG1 0x70 #define ARM_SMMU_GERROR_IRQ_CFG2 0x74 +#define ARM_SMMU_USER_CFG1 0xe04 + #define ARM_SMMU_IDR6 0x190 #define IDR6_LOG2NUMP GENMASK(27, 24) #define IDR6_LOG2NUMQ GENMASK(19, 16) @@ -708,6 +710,7 @@ struct arm_smmu_device { #define ARM_SMMU_OPT_MSIPOLL (1 << 2) #define ARM_SMMU_OPT_CMDQ_FORCE_SYNC (1 << 3) #define ARM_SMMU_OPT_SYNC_MAP (1 << 4) +#define ARM_SMMU_OPT_SYNC_BATCH (1 << 5) u32 options; #ifdef CONFIG_ARM_SMMU_V3_ECMDQ diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index 79aa11d88c56..fb54baed3f49 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c @@ -407,6 +407,11 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, unsigned long iova, pte = arm_lpae_install_table(cptep, ptep, 0, data); if (pte) __arm_lpae_free_pages(cptep, tblsz, cfg, data->iop.cookie); + +#ifdef CONFIG_HISILICON_ERRATUM_162100602 + if (lvl <= 2) + io_pgtable_tlb_flush_walk(&data->iop, iova, 0, ARM_LPAE_GRANULE(data)); +#endif } else if (!cfg->coherent_walk && !(pte & ARM_LPAE_PTE_SW_SYNC)) { __arm_lpae_sync_pte(ptep, 1, cfg); } -- 2.17.1

2 1

[PATCH OLK-5.10 0/3] xfs: fix tail alignment
by Long Li 29 Jul '24

29 Jul '24

This patch set fix maxlen fallback to availble len, it cause tail is no alignment. Dave Chinner (3): xfs: only allow minlen allocations when near ENOSPC xfs: always tail align maxlen allocations xfs: align args->minlen for forced allocation alignment fs/xfs/libxfs/xfs_alloc.c | 31 +++++++++++++++++++------------ fs/xfs/libxfs/xfs_bmap.c | 28 +++++++++++++++++++++------- 2 files changed, 40 insertions(+), 19 deletions(-) -- 2.39.2

2 4

[PATCH openEuler-1.0-LTS v2] jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
by Baokun Li 29 Jul '24

29 Jul '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAG7MT CVE: NA Reference: https://lore.kernel.org/all/20240718115336.2554501-1-libaokun@huaweicloud.c… ---------------------------------------- In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space") Cc: stable(a)kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Conflicts: fs/jbd2/journal.c [Since disk deletion does not call ext4_shutdown, abort the journal when the jbd2 sb_buffer is unmapped to avoid a dead loop.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/jbd2/checkpoint.c | 7 +++++-- fs/jbd2/journal.c | 2 ++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index b35f0b63baf0..ab6c0b9c5336 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -96,8 +96,11 @@ void __jbd2_log_wait_for_space(journal_t *journal) write_unlock(&journal->j_state_lock); if (chkpt) { jbd2_log_do_checkpoint(journal); - } else if (jbd2_cleanup_journal_tail(journal) == 0) { - /* We were able to recover space; yay! */ + } else if (jbd2_cleanup_journal_tail(journal) <= 0) { + /* + * We were able to recover space or the + * journal was aborted due to an error. + */ ; } else if (tid) { /* diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index 4462b6ec32b7..bf83e1c64aa4 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -1431,6 +1431,8 @@ static int jbd2_write_superblock(journal_t *journal, int write_flags) /* Buffer got discarded which means block device got invalidated */ if (!buffer_mapped(bh)) { unlock_buffer(bh); + if (!is_journal_aborted(journal)) + jbd2_journal_abort(journal, -EIO); return -EIO; } -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1 v2] jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
by Baokun Li 29 Jul '24

29 Jul '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAG7MT Reference: https://lore.kernel.org/all/20240718115336.2554501-1-libaokun@huaweicloud.c… ---------------------------------------- In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space") Cc: stable(a)kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Conflicts: fs/jbd2/journal.c [Since disk deletion does not call ext4_shutdown, abort the journal when the jbd2 sb_buffer is unmapped to avoid a dead loop.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/jbd2/checkpoint.c | 7 +++++-- fs/jbd2/journal.c | 2 ++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index b7e1a2bdd7fb..727f3505280c 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -98,8 +98,11 @@ __releases(&journal->j_state_lock) write_unlock(&journal->j_state_lock); if (chkpt) { jbd2_log_do_checkpoint(journal); - } else if (jbd2_cleanup_journal_tail(journal) == 0) { - /* We were able to recover space; yay! */ + } else if (jbd2_cleanup_journal_tail(journal) <= 0) { + /* + * We were able to recover space or the + * journal was aborted due to an error. + */ ; } else if (tid) { /* diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index 13506e2ae3e8..9bbd9c69ba64 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -1619,6 +1619,8 @@ static int jbd2_write_superblock(journal_t *journal, int write_flags) /* Buffer got discarded which means block device got invalidated */ if (!buffer_mapped(bh)) { unlock_buffer(bh); + if (!is_journal_aborted(journal)) + jbd2_journal_abort(journal, -EIO); return -EIO; } -- 2.31.1

2 1

[PATCH OLK-5.10 v2] jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
by Baokun Li 29 Jul '24

29 Jul '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAG7MT Reference: https://lore.kernel.org/all/20240718115336.2554501-1-libaokun@huaweicloud.c… ---------------------------------------- In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space") Cc: stable(a)kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Conflicts: fs/jbd2/journal.c [Since disk deletion does not call ext4_shutdown, abort the journal when the jbd2 sb_buffer is unmapped to avoid a dead loop.] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/jbd2/checkpoint.c | 7 +++++-- fs/jbd2/journal.c | 2 ++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index b7e1a2bdd7fb..727f3505280c 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -98,8 +98,11 @@ __releases(&journal->j_state_lock) write_unlock(&journal->j_state_lock); if (chkpt) { jbd2_log_do_checkpoint(journal); - } else if (jbd2_cleanup_journal_tail(journal) == 0) { - /* We were able to recover space; yay! */ + } else if (jbd2_cleanup_journal_tail(journal) <= 0) { + /* + * We were able to recover space or the + * journal was aborted due to an error. + */ ; } else if (tid) { /* diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index 6e2848b10aaf..7775ad53b291 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -1621,6 +1621,8 @@ static int jbd2_write_superblock(journal_t *journal, int write_flags) /* Buffer got discarded which means block device got invalidated */ if (!buffer_mapped(bh)) { unlock_buffer(bh); + if (!is_journal_aborted(journal)) + jbd2_journal_abort(journal, -EIO); return -EIO; } -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
by Zhang Changzhong 29 Jul '24

29 Jul '24

From: Alex Deucher <alexander.deucher(a)amd.com> mainline inclusion from mainline-v6.9 commit be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAEF52 CVE: CVE-2024-41011 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. Fixes: d8e408a82704 ("drm/amdkfd: Expose HDP registers to user space") Reviewed-by: Felix Kuehling <felix.kuehling(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Conflicts: drivers/gpu/drm/amd/amdkfd/kfd_chardev.c [Commit 73fa13b6a511 ("drm/amdkfd: CRIU Implement KFD restore ioctl") is not merged] Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c index 2a99edf..4155010 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c @@ -1304,7 +1304,7 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file *filep, goto err_unlock; } offset = amdgpu_amdkfd_get_mmio_remap_phys_addr(dev->kgd); - if (!offset) { + if (!offset || (PAGE_SIZE > 4096)) { err = -ENOMEM; goto err_unlock; } @@ -1962,6 +1962,9 @@ static int kfd_mmio_mmap(struct kfd_dev *dev, struct kfd_process *process, if (vma->vm_end - vma->vm_start != PAGE_SIZE) return -EINVAL; + if (PAGE_SIZE > 4096) + return -EINVAL; + address = amdgpu_amdkfd_get_mmio_remap_phys_addr(dev->kgd); vma->vm_flags |= VM_IO | VM_DONTCOPY | VM_DONTEXPAND | VM_NORESERVE | -- 2.9.5

2 1