- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 0/2] Fix CVE-2024-42160
by Zheng Zucheng 06 Aug '24

06 Aug '24

Fix CVE-2024-42160 Chao Yu (1): f2fs: check validation of fault attrs in f2fs_build_fault_attr() Nathan Chancellor (1): f2fs: Add inline to f2fs_build_fault_attr() stub fs/f2fs/f2fs.h | 12 ++++++++---- fs/f2fs/super.c | 27 ++++++++++++++++++++------- fs/f2fs/sysfs.c | 14 ++++++++++---- 3 files changed, 38 insertions(+), 15 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] Fix CVE-2024-42160
by Zheng Zucheng 06 Aug '24

06 Aug '24

Fix CVE-2024-42160 Chao Yu (1): f2fs: check validation of fault attrs in f2fs_build_fault_attr() Nathan Chancellor (1): f2fs: Add inline to f2fs_build_fault_attr() stub fs/f2fs/f2fs.h | 12 ++++++++---- fs/f2fs/super.c | 27 ++++++++++++++++++++------- fs/f2fs/sysfs.c | 14 ++++++++++---- 3 files changed, 38 insertions(+), 15 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6 0/3] CVE-2024-41045
by Pu Lehui 06 Aug '24

06 Aug '24

Benjamin Tissoires (2): bpf: replace bpf_timer_set_callback with a generic helper bpf: replace bpf_timer_cancel_and_free with a generic helper Kumar Kartikeya Dwivedi (1): bpf: Defer work in bpf_timer_cancel_and_free kernel/bpf/helpers.c | 130 +++++++++++++++++++++++++++++-------------- 1 file changed, 89 insertions(+), 41 deletions(-) -- 2.34.1

2 4

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

06 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): part1 arch/arm64/include/asm/kvm_tmi.h | 93 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 150 +++- arch/arm64/kvm/virtcca_cvm.c | 2 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + drivers/pci/access.c | 33 + drivers/pci/msi/msi.c | 90 +- drivers/vfio/pci/vfio_pci_core.c | 5 + drivers/vfio/pci/vfio_pci_rdwr.c | 61 ++ drivers/vfio/vfio_iommu_type1.c | 17 + drivers/vfio/vfio_main.c | 18 + include/linux/iommu.h | 9 + include/linux/iopoll.h | 38 + include/linux/pci.h | 4 + include/linux/vfio.h | 5 + include/uapi/linux/vfio.h | 3 + virt/kvm/vfio.c | 121 ++- virt/kvm/vfio.h | 10 + 22 files changed, 1828 insertions(+), 16 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 2

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

06 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): part1 arch/arm64/include/asm/kvm_tmi.h | 93 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 150 +++- arch/arm64/kvm/virtcca_cvm.c | 2 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + drivers/pci/access.c | 33 + drivers/pci/msi/msi.c | 90 +- drivers/vfio/pci/vfio_pci_core.c | 5 + drivers/vfio/pci/vfio_pci_rdwr.c | 61 ++ drivers/vfio/vfio_iommu_type1.c | 17 + drivers/vfio/vfio_main.c | 18 + include/linux/iommu.h | 9 + include/linux/iopoll.h | 38 + include/linux/pci.h | 4 + include/linux/vfio.h | 5 + include/uapi/linux/vfio.h | 3 + virt/kvm/vfio.c | 121 ++- virt/kvm/vfio.h | 10 + 22 files changed, 1828 insertions(+), 16 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] coda part 1
by y00878127 06 Aug '24

06 Aug '24

From: Xiangkai Yang <yangxiangkai(a)huawei.com> virtCCA feature Xiangkai Yang (1): coda part1 arch/arm64/include/asm/kvm_tmi.h | 88 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 152 +++- arch/arm64/kvm/virtcca_cvm.c | 10 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + include/linux/iommu.h | 4 + include/linux/iopoll.h | 38 + 11 files changed, 1471 insertions(+), 6 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 2

[openeuler:OLK-6.6 12699/13217] arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23000000: Unevaluated properties are not allowed ('dma-coherent', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', '...
by kernel test robot 06 Aug '24

06 Aug '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: d59a335bf0dd2aac9debe211a0a07fbeaf605fed commit: 79effa9d33aed236955bd5d6ea9588b16958803b [12699/13217] arm64: dts: qcom: sa8775p: mark ethernet devices as DMA-coherent :::::: branch date: 5 hours ago :::::: commit date: 2 days ago config: arm64-randconfig-051-20240805 (https://download.01.org/0day-ci/archive/20240806/202408060203.7OzdIHxS-lkp@…) compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project 423aec6573df4424f90555468128e17073ddc69e) dtschema version: 2024.6.dev8+gf13c181 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240806/202408060203.7OzdIHxS-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/r/202408060203.7OzdIHxS-lkp@intel.com/ dtcheck warnings: (new ones prefixed by >>) arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: rsc@18200000: 'power-domains' is a required property from schema $id: http://devicetree.org/schemas/soc/qcom/qcom,rpmh-rsc.yaml# arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23000000: rx-queues-config:queue0:snps,priority: [1] is not of type 'integer' from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23000000: rx-queues-config:queue3:snps,priority: [12] is not of type 'integer' from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23000000: snps,pbl: [32] is not of type 'integer' from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23000000: snps,pbl: [32] is not one of [1, 2, 4, 8, 16, 32] from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# >> arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23000000: Unevaluated properties are not allowed ('dma-coherent', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', 'snps,ps-speed', 'snps,tso', 'tx-fifo-depth', 'tx-queues-config' were unexpected) from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23040000: rx-queues-config:queue0:snps,priority: [1] is not of type 'integer' from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23040000: rx-queues-config:queue3:snps,priority: [12] is not of type 'integer' from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23040000: snps,pbl: [32] is not of type 'integer' from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23040000: snps,pbl: [32] is not one of [1, 2, 4, 8, 16, 32] from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# >> arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23040000: Unevaluated properties are not allowed ('dma-coherent', 'mdio', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', 'snps,ps-speed', 'snps,tso', 'tx-fifo-depth', 'tx-queues-config' were unexpected) from schema $id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 0/1] coda part 1
by y00878127 06 Aug '24

06 Aug '24

From: Xiangkai Yang <yangxiangkai(a)huawei.com> virtCCA feature Xiangkai Yang (1): part1 arch/arm64/include/asm/kvm_tmi.h | 88 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 152 +++- arch/arm64/kvm/virtcca_cvm.c | 10 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + include/linux/iommu.h | 4 + include/linux/iopoll.h | 38 + 11 files changed, 1471 insertions(+), 6 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 2

[PATCH OLK-6.6] btrfs: qgroup: fix quota root leak after quota disable failure
by Wang Zhaolong 06 Aug '24

06 Aug '24

From: Filipe Manana <fdmanana(a)suse.com> mainline inclusion from mainline-v6.10-rc6 commit a7e4c6a3031c74078dba7fa36239d0f4fe476c53 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN9 CVE: CVE-2024-41078 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps). Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted. Reviewed-by: Boris Burkov <boris(a)bur.io> Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/btrfs/qgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index 99ea2c6d3194..223dfbf00993 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -1228,7 +1228,7 @@ int btrfs_quota_enable(struct btrfs_fs_info *fs_info) int btrfs_quota_disable(struct btrfs_fs_info *fs_info) { - struct btrfs_root *quota_root; + struct btrfs_root *quota_root = NULL; struct btrfs_trans_handle *trans = NULL; int ret = 0; @@ -1323,9 +1323,9 @@ int btrfs_quota_disable(struct btrfs_fs_info *fs_info) btrfs_free_tree_block(trans, btrfs_root_id(quota_root), quota_root->node, 0, 1); - btrfs_put_root(quota_root); out: + btrfs_put_root(quota_root); mutex_unlock(&fs_info->qgroup_ioctl_lock); if (ret && trans) btrfs_end_transaction(trans); -- 2.34.3

2 1

[PATCH OLK-5.10] btrfs: qgroup: fix quota root leak after quota disable failure
by Wang Zhaolong 06 Aug '24

06 Aug '24

From: Filipe Manana <fdmanana(a)suse.com> stable inclusion from stable-v5.10.223 commit 94818bdb00ef34a996a06aa63d11f591074cb757 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN9 CVE: CVE-2024-41078 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a7e4c6a3031c74078dba7fa36239d0f4fe476c53 ] If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps). Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted. Reviewed-by: Boris Burkov <boris(a)bur.io> Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/btrfs/qgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index 7aae7a57f2b2..d59fab19659f 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -1197,7 +1197,7 @@ int btrfs_quota_enable(struct btrfs_fs_info *fs_info) int btrfs_quota_disable(struct btrfs_fs_info *fs_info) { - struct btrfs_root *quota_root; + struct btrfs_root *quota_root = NULL; struct btrfs_trans_handle *trans = NULL; int ret = 0; @@ -1277,9 +1277,9 @@ int btrfs_quota_disable(struct btrfs_fs_info *fs_info) btrfs_tree_unlock(quota_root->node); btrfs_free_tree_block(trans, quota_root, quota_root->node, 0, 1); - btrfs_put_root(quota_root); out: + btrfs_put_root(quota_root); mutex_unlock(&fs_info->qgroup_ioctl_lock); if (ret && trans) btrfs_end_transaction(trans); -- 2.34.3

2 1

[PATCH openEuler-22.03-LTS-SP1] btrfs: qgroup: fix quota root leak after quota disable failure
by Wang Zhaolong 06 Aug '24

06 Aug '24

From: Filipe Manana <fdmanana(a)suse.com> stable inclusion from stable-v5.10.223 commit 94818bdb00ef34a996a06aa63d11f591074cb757 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEN9 CVE: CVE-2024-41078 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a7e4c6a3031c74078dba7fa36239d0f4fe476c53 ] If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps). Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted. Reviewed-by: Boris Burkov <boris(a)bur.io> Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/btrfs/qgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index 7aae7a57f2b2..d59fab19659f 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -1197,7 +1197,7 @@ int btrfs_quota_enable(struct btrfs_fs_info *fs_info) int btrfs_quota_disable(struct btrfs_fs_info *fs_info) { - struct btrfs_root *quota_root; + struct btrfs_root *quota_root = NULL; struct btrfs_trans_handle *trans = NULL; int ret = 0; @@ -1277,9 +1277,9 @@ int btrfs_quota_disable(struct btrfs_fs_info *fs_info) btrfs_tree_unlock(quota_root->node); btrfs_free_tree_block(trans, quota_root, quota_root->node, 0, 1); - btrfs_put_root(quota_root); out: + btrfs_put_root(quota_root); mutex_unlock(&fs_info->qgroup_ioctl_lock); if (ret && trans) btrfs_end_transaction(trans); -- 2.34.3

2 1

[PATCH openEuler-22.03-LTS-SP1 v2 0/2] CVE-2024-41016
by Yu Liao 06 Aug '24

06 Aug '24

Ferry Meng (2): ocfs2: add bounds checking to ocfs2_xattr_find_entry() ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry() fs/ocfs2/xattr.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 0/1] coda part 1
by y00878127 06 Aug '24

06 Aug '24

From: Xiangkai Yang <yangxiangkai(a)huawei.com> virtCCA feature Xiangkai Yang (1): part1 arch/arm64/include/asm/kvm_tmi.h | 88 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 152 +++- arch/arm64/kvm/virtcca_cvm.c | 11 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + include/linux/iommu.h | 4 + include/linux/iopoll.h | 38 + 11 files changed, 1472 insertions(+), 6 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.27.0

2 2

[PATCH OLK-5.10 v2 0/2] CVE-2024-41016
by Yu Liao 06 Aug '24

06 Aug '24

Ferry Meng (2): ocfs2: add bounds checking to ocfs2_xattr_find_entry() ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry() fs/ocfs2/xattr.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-22.03-LTS-SP1] jfs: xattr: fix buffer overflow for invalid xattr
by Xia Fukun 06 Aug '24

06 Aug '24

From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> mainline inclusion from mainline-v6.10-rc1 commit 7c55b78818cfb732680c4a72ab270cc2d2ee3d0f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0FK CVE: CVE-2024-40902 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log. Reported-by: syzbot+9dfe490c8176301c1d06(a)syzkaller.appspotmail.com Cc: Dave Kleikamp <shaggy(a)kernel.org> Link: https://lore.kernel.org/r/2024051433-slider-cloning-98f9@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- fs/jfs/xattr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c index db41e7803163e..7ae54f78a5b0b 100644 --- a/fs/jfs/xattr.c +++ b/fs/jfs/xattr.c @@ -557,9 +557,11 @@ static int ea_get(struct inode *inode, struct ea_buffer *ea_buf, int min_size) size_check: if (EALIST_SIZE(ea_buf->xattr) != ea_size) { + int size = min_t(int, EALIST_SIZE(ea_buf->xattr), ea_size); + printk(KERN_ERR "ea_get: invalid extended attribute\n"); print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, - ea_buf->xattr, ea_size, 1); + ea_buf->xattr, size, 1); ea_release(inode, ea_buf); rc = -EIO; goto clean_up; -- 2.34.1

2 1

[PATCH OLK-6.6] irqchip/mbigen: Fix mbigen node address layout
by Yipeng Zou 06 Aug '24

06 Aug '24

linux-next inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAI2U3 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/… -------------------------------- The mbigen interrupt chip has its per node registers located in a contiguous region of page sized chunks. The code maps them into virtual address space as a contiguous region and determines the address of a node by using the node ID as index. mbigen chip |-----------------|------------|--------------| mgn_node_0 mgn_node_1 ... mgn_node_i |--------------| |--------------| |----------------------| [0x0000, 0x0x0FFF] [0x1000, 0x1FFF] [i*0x1000, (i+1)*0x1000 - 1] This works correctly up to 10 nodes, but then fails because the 11th's array slot is used for the MGN_CLEAR registers. mbigen chip |-----------|--------|--------|---------------|--------| mgn_node_0 mgn_node_1 ... mgn_clear_register ... mgn_node_i |-----------------| [0xA000, 0xAFFF] Skip the MGN_CLEAR register space when calculating the offset for node IDs greater than or equal to ten. Fixes: a6c2f87b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lore.kernel.org/all/20240730014400.1751530-1-zouyipeng@huawei.com Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/irqchip/irq-mbigen.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c index c75cd0fa213b..4e603fa73c33 100644 --- a/drivers/irqchip/irq-mbigen.c +++ b/drivers/irqchip/irq-mbigen.c @@ -300,6 +300,20 @@ static int vtimer_mbigen_set_type(unsigned int cpu_id) } #endif +static inline unsigned int get_mbigen_node_offset(unsigned int nid) +{ + unsigned int offset = nid * MBIGEN_NODE_OFFSET; + + /* + * To avoid touched clear register in unexpected way, we need to directly + * skip clear register when access to more than 10 mbigen nodes. + */ + if (nid >= (REG_MBIGEN_CLEAR_OFFSET / MBIGEN_NODE_OFFSET)) + offset += MBIGEN_NODE_OFFSET; + + return offset; +} + static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq) { unsigned int nid, pin; @@ -313,8 +327,7 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq) nid = hwirq / IRQS_PER_MBIGEN_NODE + 1; pin = hwirq % IRQS_PER_MBIGEN_NODE; - return pin * 4 + nid * MBIGEN_NODE_OFFSET - + REG_MBIGEN_LPI_VEC_OFFSET; + return pin * 4 + get_mbigen_node_offset(nid) + REG_MBIGEN_LPI_VEC_OFFSET; } static inline void get_mbigen_type_reg(irq_hw_number_t hwirq, @@ -338,8 +351,7 @@ static inline void get_mbigen_type_reg(irq_hw_number_t hwirq, *mask = 1 << (irq_ofst % 32); ofst = irq_ofst / 32 * 4; - *addr = ofst + nid * MBIGEN_NODE_OFFSET - + REG_MBIGEN_LPI_TYPE_OFFSET; + *addr = ofst + get_mbigen_node_offset(nid) + REG_MBIGEN_LPI_TYPE_OFFSET; } static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq, -- 2.34.1

2 1

[PATCH OLK-5.10] jfs: xattr: fix buffer overflow for invalid xattr
by Xia Fukun 06 Aug '24

06 Aug '24

From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> mainline inclusion from mainline-v6.10-rc1 commit 7c55b78818cfb732680c4a72ab270cc2d2ee3d0f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAD0FK CVE: CVE-2024-40902 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log. Reported-by: syzbot+9dfe490c8176301c1d06(a)syzkaller.appspotmail.com Cc: Dave Kleikamp <shaggy(a)kernel.org> Link: https://lore.kernel.org/r/2024051433-slider-cloning-98f9@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- fs/jfs/xattr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c index db41e7803163e..7ae54f78a5b0b 100644 --- a/fs/jfs/xattr.c +++ b/fs/jfs/xattr.c @@ -557,9 +557,11 @@ static int ea_get(struct inode *inode, struct ea_buffer *ea_buf, int min_size) size_check: if (EALIST_SIZE(ea_buf->xattr) != ea_size) { + int size = min_t(int, EALIST_SIZE(ea_buf->xattr), ea_size); + printk(KERN_ERR "ea_get: invalid extended attribute\n"); print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, - ea_buf->xattr, ea_size, 1); + ea_buf->xattr, size, 1); ea_release(inode, ea_buf); rc = -EIO; goto clean_up; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] media: mediatek: vcodec: Only free buffer VA that is not NULL
by Zheng Yejian 06 Aug '24

06 Aug '24

From: Fei Shao <fshao(a)chromium.org> mainline inclusion from mainline-v6.10-rc1 commit eb005c801ec70ff4307727bd3bd6e8280169ef32 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAH97R CVE: CVE-2023-52888 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice. We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings. Fixes: 2cc93862d484 ("[media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver") Conflicts: drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c [Resolve conflicts due to lack of several refactor codes] Signed-off-by: Fei Shao <fshao(a)chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p(a)collabora.com> Signed-off-by: Sebastian Fricke <sebastian.fricke(a)collabora.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c index d0123dfc5f93..aadeac1131b0 100644 --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c @@ -231,11 +231,12 @@ static void h264_enc_free_work_buf(struct venc_h264_inst *inst) * other buffers need to be freed by AP. */ for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) { - if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME) + if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME && inst->work_bufs[i].va) mtk_vcodec_mem_free(inst->ctx, &inst->work_bufs[i]); } - mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf); + if (inst->pps_buf.va) + mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf); mtk_vcodec_debug_leave(inst); } -- 2.25.1

2 1

[PATCH OLK-5.10] media: mediatek: vcodec: Only free buffer VA that is not NULL
by Zheng Yejian 06 Aug '24

06 Aug '24

From: Fei Shao <fshao(a)chromium.org> mainline inclusion from mainline-v6.10-rc1 commit eb005c801ec70ff4307727bd3bd6e8280169ef32 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAH97R CVE: CVE-2023-52888 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice. We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings. Fixes: 2cc93862d484 ("[media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver") Conflicts: drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c [Resolve conflicts due to lack of several refactor codes] Signed-off-by: Fei Shao <fshao(a)chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p(a)collabora.com> Signed-off-by: Sebastian Fricke <sebastian.fricke(a)collabora.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c index d0123dfc5f93..aadeac1131b0 100644 --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c @@ -231,11 +231,12 @@ static void h264_enc_free_work_buf(struct venc_h264_inst *inst) * other buffers need to be freed by AP. */ for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) { - if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME) + if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME && inst->work_bufs[i].va) mtk_vcodec_mem_free(inst->ctx, &inst->work_bufs[i]); } - mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf); + if (inst->pps_buf.va) + mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf); mtk_vcodec_debug_leave(inst); } -- 2.25.1

2 1

[PATCH OLK-5.10] irqchip/mbigen: Fix mbigen node address layout
by Yipeng Zou 06 Aug '24

06 Aug '24

linux-next inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAI2U3 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/… -------------------------------- The mbigen interrupt chip has its per node registers located in a contiguous region of page sized chunks. The code maps them into virtual address space as a contiguous region and determines the address of a node by using the node ID as index. mbigen chip |-----------------|------------|--------------| mgn_node_0 mgn_node_1 ... mgn_node_i |--------------| |--------------| |----------------------| [0x0000, 0x0x0FFF] [0x1000, 0x1FFF] [i*0x1000, (i+1)*0x1000 - 1] This works correctly up to 10 nodes, but then fails because the 11th's array slot is used for the MGN_CLEAR registers. mbigen chip |-----------|--------|--------|---------------|--------| mgn_node_0 mgn_node_1 ... mgn_clear_register ... mgn_node_i |-----------------| [0xA000, 0xAFFF] Skip the MGN_CLEAR register space when calculating the offset for node IDs greater than or equal to ten. Fixes: a6c2f87b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation functions") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lore.kernel.org/all/20240730014400.1751530-1-zouyipeng@huawei.com Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/irqchip/irq-mbigen.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c index 16090b620496..8f5cf7bb79a7 100644 --- a/drivers/irqchip/irq-mbigen.c +++ b/drivers/irqchip/irq-mbigen.c @@ -291,6 +291,20 @@ static int vtimer_mbigen_set_type(unsigned int cpu_id) return 0; } +static inline unsigned int get_mbigen_node_offset(unsigned int nid) +{ + unsigned int offset = nid * MBIGEN_NODE_OFFSET; + + /* + * To avoid touched clear register in unexpected way, we need to directly + * skip clear register when access to more than 10 mbigen nodes. + */ + if (nid >= (REG_MBIGEN_CLEAR_OFFSET / MBIGEN_NODE_OFFSET)) + offset += MBIGEN_NODE_OFFSET; + + return offset; +} + static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq) { unsigned int nid, pin; @@ -302,8 +316,7 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq) nid = hwirq / IRQS_PER_MBIGEN_NODE + 1; pin = hwirq % IRQS_PER_MBIGEN_NODE; - return pin * 4 + nid * MBIGEN_NODE_OFFSET - + REG_MBIGEN_LPI_VEC_OFFSET; + return pin * 4 + get_mbigen_node_offset(nid) + REG_MBIGEN_LPI_VEC_OFFSET; } static inline void get_mbigen_type_reg(irq_hw_number_t hwirq, @@ -325,8 +338,7 @@ static inline void get_mbigen_type_reg(irq_hw_number_t hwirq, *mask = 1 << (irq_ofst % 32); ofst = irq_ofst / 32 * 4; - *addr = ofst + nid * MBIGEN_NODE_OFFSET - + REG_MBIGEN_LPI_TYPE_OFFSET; + *addr = ofst + get_mbigen_node_offset(nid) + REG_MBIGEN_LPI_TYPE_OFFSET; } static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq, -- 2.34.1

2 1

[PATCH OLK-6.6] ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
by Yu Liao 06 Aug '24

06 Aug '24

From: Ferry Meng <mengferry(a)linux.alibaba.com> mainline inclusion from mainline-v6.11-rc1 commit af77c4fc1871847b528d58b7fdafb4aa1f6a9262 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAG8SI CVE: CVE-2024-41016 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images. Link: https://lkml.kernel.org/r/20240520024024.1976129-2-joseph.qi@linux.alibaba.… Signed-off-by: Ferry Meng <mengferry(a)linux.alibaba.com> Signed-off-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Reported-by: lei lu <llfamsec(a)gmail.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Mark Fasheh <mark(a)fasheh.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- fs/ocfs2/xattr.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c index b562cfef888a..b211dc17af3e 100644 --- a/fs/ocfs2/xattr.c +++ b/fs/ocfs2/xattr.c @@ -1068,7 +1068,7 @@ static int ocfs2_xattr_find_entry(int name_index, { struct ocfs2_xattr_entry *entry; size_t name_len; - int i, cmp = 1; + int i, name_offset, cmp = 1; if (name == NULL) return -EINVAL; @@ -1079,10 +1079,15 @@ static int ocfs2_xattr_find_entry(int name_index, cmp = name_index - ocfs2_xattr_get_type(entry); if (!cmp) cmp = name_len - entry->xe_name_len; - if (!cmp) - cmp = memcmp(name, (xs->base + - le16_to_cpu(entry->xe_name_offset)), - name_len); + if (!cmp) { + name_offset = le16_to_cpu(entry->xe_name_offset); + if ((xs->base + name_offset + name_len) > xs->end) { + ocfs2_error(inode->i_sb, + "corrupted xattr entries"); + return -EFSCORRUPTED; + } + cmp = memcmp(name, (xs->base + name_offset), name_len); + } if (cmp == 0) break; entry += 1; -- 2.25.1

2 1

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

06 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): part1 arch/arm64/include/asm/kvm_tmi.h | 93 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 150 +++- arch/arm64/kvm/virtcca_cvm.c | 2 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + drivers/vfio/pci/vfio_pci_core.c | 5 + drivers/vfio/pci/vfio_pci_rdwr.c | 61 ++ drivers/vfio/vfio_iommu_type1.c | 17 + drivers/vfio/vfio_main.c | 18 + include/linux/iommu.h | 9 + include/linux/iopoll.h | 38 + include/linux/pci.h | 4 + include/linux/vfio.h | 5 + include/uapi/linux/vfio.h | 3 + virt/kvm/vfio.c | 121 ++- virt/kvm/vfio.h | 10 + 20 files changed, 1714 insertions(+), 7 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 2

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS WITH WARNING f10f25f5188cddb47d7a8a4ddf63c200b33e5b49
by kernel test robot 06 Aug '24

06 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: f10f25f5188cddb47d7a8a4ddf63c200b33e5b49 !10693 drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes Warning reports: https://lore.kernel.org/oe-kbuild-all/202408060608.ESB5dO3f-lkp@intel.com Warning: (recently discovered and may have been fixed) drivers/crypto/hisilicon/rde/rde_main.c:576:6: warning: no previous prototype for 'hisi_rde_hw_error_log' [-Wmissing-prototypes] drivers/crypto/hisilicon/rde/rde_main.c:607:5: warning: no previous prototype for 'hisi_rde_get_hw_err_status' [-Wmissing-prototypes] drivers/crypto/hisilicon/rde/rde_main.c:612:6: warning: no previous prototype for 'hisi_rde_clear_hw_err_status' [-Wmissing-prototypes] Warning ids grouped by kconfigs: recent_errors `-- arm64-randconfig-002-20240806 |-- drivers-crypto-hisilicon-rde-rde_main.c:warning:no-previous-prototype-for-hisi_rde_clear_hw_err_status |-- drivers-crypto-hisilicon-rde-rde_main.c:warning:no-previous-prototype-for-hisi_rde_get_hw_err_status `-- drivers-crypto-hisilicon-rde-rde_main.c:warning:no-previous-prototype-for-hisi_rde_hw_error_log elapsed time: 738m configs tested: 35 configs skipped: 139 tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 defconfig gcc-14.1.0 arm64 randconfig-001-20240806 gcc-14.1.0 arm64 randconfig-002-20240806 gcc-14.1.0 arm64 randconfig-003-20240806 gcc-14.1.0 arm64 randconfig-004-20240806 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240806 clang-18 x86_64 buildonly-randconfig-002-20240806 clang-18 x86_64 buildonly-randconfig-003-20240806 clang-18 x86_64 buildonly-randconfig-004-20240806 clang-18 x86_64 buildonly-randconfig-005-20240806 gcc-12 x86_64 buildonly-randconfig-006-20240806 gcc-12 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240806 gcc-12 x86_64 randconfig-002-20240806 gcc-11 x86_64 randconfig-003-20240806 gcc-12 x86_64 randconfig-004-20240806 clang-18 x86_64 randconfig-005-20240806 clang-18 x86_64 randconfig-006-20240806 clang-18 x86_64 randconfig-011-20240806 gcc-12 x86_64 randconfig-012-20240806 gcc-12 x86_64 randconfig-013-20240806 clang-18 x86_64 randconfig-014-20240806 gcc-12 x86_64 randconfig-015-20240806 gcc-12 x86_64 randconfig-016-20240806 gcc-12 x86_64 randconfig-071-20240806 gcc-12 x86_64 randconfig-072-20240806 clang-18 x86_64 randconfig-073-20240806 gcc-11 x86_64 randconfig-074-20240806 gcc-12 x86_64 randconfig-075-20240806 gcc-12 x86_64 randconfig-076-20240806 clang-18 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 REGRESSION d59a335bf0dd2aac9debe211a0a07fbeaf605fed
by kernel test robot 06 Aug '24

06 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: d59a335bf0dd2aac9debe211a0a07fbeaf605fed !10639 s390/mm: Fix VM_FAULT_HWPOISON handling in do_exception() Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202408060639.d1BhjbnX-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) arch/arm64/kvm/arm.c:138:7: warning: variable 'r' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] arch/arm64/kvm/tmi.c:131:5: warning: no previous prototype for function 'tmi_tmm_inf_test' [-Wmissing-prototypes] arch/arm64/kvm/virtcca_cvm.c:244:5: warning: no previous prototype for function 'kvm_cvm_create_ttt_levels' [-Wmissing-prototypes] arch/arm64/kvm/virtcca_cvm.c:311:5: warning: no previous prototype for function 'kvm_cvm_populate_par_region' [-Wmissing-prototypes] arch/arm64/kvm/virtcca_cvm.c:70:6: warning: no previous prototype for function 'kvm_cvm_supports_sve' [-Wmissing-prototypes] arch/arm64/kvm/virtcca_cvm.c:75:6: warning: no previous prototype for function 'kvm_cvm_supports_pmu' [-Wmissing-prototypes] arch/arm64/kvm/virtcca_cvm.c:80:5: warning: no previous prototype for function 'kvm_cvm_ipa_limit' [-Wmissing-prototypes] arch/arm64/kvm/virtcca_cvm.c:85:5: warning: no previous prototype for function 'kvm_cvm_get_num_brps' [-Wmissing-prototypes] arch/arm64/kvm/virtcca_cvm.c:90:5: warning: no previous prototype for function 'kvm_cvm_get_num_wrps' [-Wmissing-prototypes] Unverified Error/Warning (likely false positive, please contact us if interested): arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23000000: Unevaluated properties are not allowed ('dma-coherent', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', 'snps,ps-speed', 'snps,tso', 'tx-fifo-depth', 'tx-queues-config' were unexpected) arch/arm64/boot/dts/qcom/sa8775p-ride.dtb: ethernet@23040000: Unevaluated properties are not allowed ('dma-coherent', 'mdio', 'phy-handle', 'phy-mode', 'power-domains', 'rx-fifo-depth', 'rx-queues-config', 'snps,mtl-rx-config', 'snps,mtl-tx-config', 'snps,pbl', 'snps,ps-speed', 'snps,tso', 'tx-fifo-depth', 'tx-queues-config' were unexpected) vmlinux.o: warning: objtool: amd_set_spi_freq() falls through to next function amd_spi_busy_wait() Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | |-- arch-arm64-kvm-arm.c:warning:variable-r-is-used-uninitialized-whenever-if-condition-is-false | |-- arch-arm64-kvm-tmi.c:warning:no-previous-prototype-for-function-tmi_tmm_inf_test | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_create_ttt_levels | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_get_num_brps | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_get_num_wrps | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_ipa_limit | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_populate_par_region | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_supports_pmu | `-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_supports_sve |-- arm64-defconfig | `-- 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-051-20240805 | |-- arch-arm64-boot-dts-qcom-sa8775p-ride.dtb:ethernet:Unevaluated-properties-are-not-allowed-(-dma-coherent-mdio-phy-handle-phy-mode-power-domains-rx-fifo-depth-rx-queues-config-snps-mtl-rx-config-snps-m | `-- arch-arm64-boot-dts-qcom-sa8775p-ride.dtb:ethernet:Unevaluated-properties-are-not-allowed-(-dma-coherent-phy-handle-phy-mode-power-domains-rx-fifo-depth-rx-queues-config-snps-mtl-rx-config-snps-mtl-tx |-- 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-20240806 | `-- 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 |-- x86_64-allyesconfig | `-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_topology.c:warning:stack-frame-size-()-exceeds-limit-()-in-kfd_topology_add_device |-- x86_64-buildonly-randconfig-006-20240805 | `-- kernel-sched-isolation.c:error:use-of-undeclared-identifier-setup_max_cpus `-- x86_64-randconfig-161-20240805 `-- vmlinux.o:warning:objtool:amd_set_spi_freq-falls-through-to-next-function-amd_spi_busy_wait() elapsed time: 743m configs tested: 40 configs skipped: 134 tested configs: arm64 allmodconfig clang-20 arm64 allnoconfig gcc-14.1.0 arm64 defconfig gcc-14.1.0 arm64 randconfig-001-20240806 clang-20 arm64 randconfig-002-20240806 clang-20 arm64 randconfig-003-20240806 clang-14 arm64 randconfig-004-20240806 gcc-14.1.0 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch defconfig gcc-14.1.0 loongarch randconfig-001-20240806 gcc-14.1.0 loongarch randconfig-002-20240806 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240805 gcc-12 x86_64 buildonly-randconfig-002-20240805 clang-18 x86_64 buildonly-randconfig-003-20240805 clang-18 x86_64 buildonly-randconfig-004-20240805 clang-18 x86_64 buildonly-randconfig-005-20240805 gcc-11 x86_64 buildonly-randconfig-006-20240805 clang-18 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240805 gcc-12 x86_64 randconfig-002-20240805 gcc-12 x86_64 randconfig-003-20240805 clang-18 x86_64 randconfig-004-20240805 gcc-12 x86_64 randconfig-005-20240805 clang-18 x86_64 randconfig-006-20240805 gcc-12 x86_64 randconfig-011-20240805 clang-18 x86_64 randconfig-012-20240805 clang-18 x86_64 randconfig-013-20240805 gcc-12 x86_64 randconfig-014-20240805 gcc-12 x86_64 randconfig-015-20240805 clang-18 x86_64 randconfig-016-20240805 clang-18 x86_64 randconfig-071-20240805 clang-18 x86_64 randconfig-072-20240805 gcc-12 x86_64 randconfig-073-20240805 clang-18 x86_64 randconfig-074-20240805 clang-18 x86_64 randconfig-075-20240805 clang-18 x86_64 randconfig-076-20240805 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

(no subject)
by fuju 06 Aug '24

06 Aug '24

附件为开源项目tee-gp-proxy: This project aims to provide an implementation for RPC invoking TEE to facilitate the use of Kunpeng confidential computing in cloud scennarios. (gitee.com)<https://gitee.com/openeuler/tee-gp-proxy> 的补丁代码，不涉及秘密信息。

1 0

[PATCH OLK-6.6 0/1] coda part 1
by y00878127 06 Aug '24

06 Aug '24

From: Xiangkai Yang <yangxiangkai(a)huawei.com> virtCCA feature Xiangkai Yang (1): part1 arch/arm64/include/asm/kvm_tmi.h | 93 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 150 +++- arch/arm64/kvm/virtcca_cvm.c | 2 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + include/linux/iommu.h | 4 + include/linux/iopoll.h | 38 + 11 files changed, 1466 insertions(+), 6 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.27.0

2 2

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

06 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): part1 arch/arm64/include/asm/kvm_tmi.h | 93 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 150 +++- arch/arm64/kvm/virtcca_cvm.c | 2 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + drivers/vfio/pci/vfio_pci_core.c | 5 + drivers/vfio/pci/vfio_pci_rdwr.c | 61 ++ drivers/vfio/vfio_iommu_type1.c | 17 + drivers/vfio/vfio_main.c | 18 + include/linux/iommu.h | 9 + include/linux/iopoll.h | 38 + include/linux/pci.h | 4 + include/linux/vfio.h | 5 + include/uapi/linux/vfio.h | 3 + virt/kvm/vfio.c | 121 ++- virt/kvm/vfio.h | 10 + 20 files changed, 1714 insertions(+), 7 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

1 0

[PATCH openEuler-22.03-LTS-SP1] net/dpaa2: Avoid explicit cpumask var allocation on stack
by Zhang Changzhong 06 Aug '24

06 Aug '24

From: Dawei Li <dawei.li(a)shingroup.cn> stable inclusion from stable-v5.10.221 commit 763896ab62a672d728f5eb10ac90d98c607a8509 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEPB CVE: CVE-2024-42093 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d33fe1714a44ff540629b149d8fab4ac6967585c ] For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li <dawei.li(a)shingroup.cn> Link: https://lore.kernel.org/r/20240331053441.1276826-3-dawei.li@shingroup.cn Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c index 07ba043..fa202fe 100644 --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c @@ -2383,11 +2383,14 @@ static int dpaa2_eth_xdp_xmit(struct net_device *net_dev, int n, static int update_xps(struct dpaa2_eth_priv *priv) { struct net_device *net_dev = priv->net_dev; - struct cpumask xps_mask; - struct dpaa2_eth_fq *fq; int i, num_queues, netdev_queues; + struct dpaa2_eth_fq *fq; + cpumask_var_t xps_mask; int err = 0; + if (!alloc_cpumask_var(&xps_mask, GFP_KERNEL)) + return -ENOMEM; + num_queues = dpaa2_eth_queue_count(priv); netdev_queues = (net_dev->num_tc ? : 1) * num_queues; @@ -2397,16 +2400,17 @@ static int update_xps(struct dpaa2_eth_priv *priv) for (i = 0; i < netdev_queues; i++) { fq = &priv->fq[i % num_queues]; - cpumask_clear(&xps_mask); - cpumask_set_cpu(fq->target_cpu, &xps_mask); + cpumask_clear(xps_mask); + cpumask_set_cpu(fq->target_cpu, xps_mask); - err = netif_set_xps_queue(net_dev, &xps_mask, i); + err = netif_set_xps_queue(net_dev, xps_mask, i); if (err) { netdev_warn_once(net_dev, "Error setting XPS queue\n"); break; } } + free_cpumask_var(xps_mask); return err; } -- 2.9.5

2 1

[PATCH OLK-5.10] net/dpaa2: Avoid explicit cpumask var allocation on stack
by Zhang Changzhong 06 Aug '24

06 Aug '24

From: Dawei Li <dawei.li(a)shingroup.cn> stable inclusion from stable-v5.10.221 commit 763896ab62a672d728f5eb10ac90d98c607a8509 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEPB CVE: CVE-2024-42093 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d33fe1714a44ff540629b149d8fab4ac6967585c ] For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li <dawei.li(a)shingroup.cn> Link: https://lore.kernel.org/r/20240331053441.1276826-3-dawei.li@shingroup.cn Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c index 07ba043..fa202fe 100644 --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c @@ -2383,11 +2383,14 @@ static int dpaa2_eth_xdp_xmit(struct net_device *net_dev, int n, static int update_xps(struct dpaa2_eth_priv *priv) { struct net_device *net_dev = priv->net_dev; - struct cpumask xps_mask; - struct dpaa2_eth_fq *fq; int i, num_queues, netdev_queues; + struct dpaa2_eth_fq *fq; + cpumask_var_t xps_mask; int err = 0; + if (!alloc_cpumask_var(&xps_mask, GFP_KERNEL)) + return -ENOMEM; + num_queues = dpaa2_eth_queue_count(priv); netdev_queues = (net_dev->num_tc ? : 1) * num_queues; @@ -2397,16 +2400,17 @@ static int update_xps(struct dpaa2_eth_priv *priv) for (i = 0; i < netdev_queues; i++) { fq = &priv->fq[i % num_queues]; - cpumask_clear(&xps_mask); - cpumask_set_cpu(fq->target_cpu, &xps_mask); + cpumask_clear(xps_mask); + cpumask_set_cpu(fq->target_cpu, xps_mask); - err = netif_set_xps_queue(net_dev, &xps_mask, i); + err = netif_set_xps_queue(net_dev, xps_mask, i); if (err) { netdev_warn_once(net_dev, "Error setting XPS queue\n"); break; } } + free_cpumask_var(xps_mask); return err; } -- 2.9.5

2 1

[openeuler:OLK-5.10] BUILD SUCCESS cdac497b81fbc43cdf369eef5d2b98f6df151ebc
by kernel test robot 06 Aug '24

06 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: cdac497b81fbc43cdf369eef5d2b98f6df151ebc !10697 mm: prevent derefencing NULL ptr in pfn_section_valid() elapsed time: 731m 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 clang-20 arm64 allnoconfig gcc-14.1.0 arm64 defconfig gcc-14.1.0 arm64 randconfig-001-20240806 clang-20 arm64 randconfig-002-20240806 clang-20 arm64 randconfig-003-20240806 clang-14 arm64 randconfig-004-20240806 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240806 clang-18 x86_64 buildonly-randconfig-002-20240806 clang-18 x86_64 buildonly-randconfig-003-20240806 clang-18 x86_64 buildonly-randconfig-004-20240806 clang-18 x86_64 buildonly-randconfig-005-20240806 gcc-12 x86_64 buildonly-randconfig-006-20240806 gcc-12 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240806 gcc-12 x86_64 randconfig-002-20240806 gcc-11 x86_64 randconfig-003-20240806 gcc-12 x86_64 randconfig-004-20240806 clang-18 x86_64 randconfig-005-20240806 clang-18 x86_64 randconfig-006-20240806 clang-18 x86_64 randconfig-011-20240806 gcc-12 x86_64 randconfig-012-20240806 gcc-12 x86_64 randconfig-013-20240806 clang-18 x86_64 randconfig-014-20240806 gcc-12 x86_64 randconfig-015-20240806 gcc-12 x86_64 randconfig-016-20240806 gcc-12 x86_64 randconfig-071-20240806 gcc-12 x86_64 randconfig-072-20240806 clang-18 x86_64 randconfig-073-20240806 gcc-11 x86_64 randconfig-074-20240806 gcc-12 x86_64 randconfig-075-20240806 gcc-12 x86_64 randconfig-076-20240806 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1] ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
by Yu Liao 06 Aug '24

06 Aug '24

From: Ferry Meng <mengferry(a)linux.alibaba.com> mainline inclusion from mainline-v6.11-rc1 commit af77c4fc1871847b528d58b7fdafb4aa1f6a9262 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAG8SI CVE: CVE-2024-41016 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images. Link: https://lkml.kernel.org/r/20240520024024.1976129-2-joseph.qi@linux.alibaba.… Signed-off-by: Ferry Meng <mengferry(a)linux.alibaba.com> Signed-off-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Reported-by: lei lu <llfamsec(a)gmail.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Mark Fasheh <mark(a)fasheh.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- fs/ocfs2/xattr.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c index 10df2e1dfef7..fbbb2a88ffec 100644 --- a/fs/ocfs2/xattr.c +++ b/fs/ocfs2/xattr.c @@ -1074,7 +1074,7 @@ static int ocfs2_xattr_find_entry(int name_index, { struct ocfs2_xattr_entry *entry; size_t name_len; - int i, cmp = 1; + int i, name_offset, cmp = 1; if (name == NULL) return -EINVAL; @@ -1085,10 +1085,15 @@ static int ocfs2_xattr_find_entry(int name_index, cmp = name_index - ocfs2_xattr_get_type(entry); if (!cmp) cmp = name_len - entry->xe_name_len; - if (!cmp) - cmp = memcmp(name, (xs->base + - le16_to_cpu(entry->xe_name_offset)), - name_len); + if (!cmp) { + name_offset = le16_to_cpu(entry->xe_name_offset); + if ((xs->base + name_offset + name_len) > xs->end) { + ocfs2_error(inode->i_sb, + "corrupted xattr entries"); + return -EFSCORRUPTED; + } + cmp = memcmp(name, (xs->base + name_offset), name_len); + } if (cmp == 0) break; entry += 1; -- 2.25.1

2 1

[PATCH OLK-5.10] ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
by Yu Liao 06 Aug '24

06 Aug '24

From: Ferry Meng <mengferry(a)linux.alibaba.com> mainline inclusion from mainline-v6.11-rc1 commit af77c4fc1871847b528d58b7fdafb4aa1f6a9262 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAG8SI CVE: CVE-2024-41016 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images. Link: https://lkml.kernel.org/r/20240520024024.1976129-2-joseph.qi@linux.alibaba.… Signed-off-by: Ferry Meng <mengferry(a)linux.alibaba.com> Signed-off-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Reported-by: lei lu <llfamsec(a)gmail.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Mark Fasheh <mark(a)fasheh.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- fs/ocfs2/xattr.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c index 10df2e1dfef7..fbbb2a88ffec 100644 --- a/fs/ocfs2/xattr.c +++ b/fs/ocfs2/xattr.c @@ -1074,7 +1074,7 @@ static int ocfs2_xattr_find_entry(int name_index, { struct ocfs2_xattr_entry *entry; size_t name_len; - int i, cmp = 1; + int i, name_offset, cmp = 1; if (name == NULL) return -EINVAL; @@ -1085,10 +1085,15 @@ static int ocfs2_xattr_find_entry(int name_index, cmp = name_index - ocfs2_xattr_get_type(entry); if (!cmp) cmp = name_len - entry->xe_name_len; - if (!cmp) - cmp = memcmp(name, (xs->base + - le16_to_cpu(entry->xe_name_offset)), - name_len); + if (!cmp) { + name_offset = le16_to_cpu(entry->xe_name_offset); + if ((xs->base + name_offset + name_len) > xs->end) { + ocfs2_error(inode->i_sb, + "corrupted xattr entries"); + return -EFSCORRUPTED; + } + cmp = memcmp(name, (xs->base + name_offset), name_len); + } if (cmp == 0) break; entry += 1; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] filelock: Remove locks reliably when fcntl/close race is detected
by Long Li 06 Aug '24

06 Aug '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v5.10.222 commit 5661b9c7ec189406c2dde00837aaa4672efb6240 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAF3IR CVE: CVE-2024-41012 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit 3cad1bc010416c6dd780643476bc59ed742436b9 upstream. When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. In theory (but AFAIK not in practice), posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in enforcing mode and only works from some security contexts. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). 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/20240702-fs-lock-recover-2-v1-1-edd456f63789@goog… Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> [stable fixup: ->c.flc_type was ->fl_type in older kernels] Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/locks.c [Conflicts due to function refactor in fcntl_setlk()] Signed-off-by: Long Li <leo.lilong(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 6280fbb613de..6bd1fbe42ada 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 OLK-5.10] filelock: Remove locks reliably when fcntl/close race is detected
by Long Li 06 Aug '24

06 Aug '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v5.10.222 commit 5661b9c7ec189406c2dde00837aaa4672efb6240 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAF3IR CVE: CVE-2024-41012 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit 3cad1bc010416c6dd780643476bc59ed742436b9 upstream. When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. In theory (but AFAIK not in practice), posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in enforcing mode and only works from some security contexts. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). 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/20240702-fs-lock-recover-2-v1-1-edd456f63789@goog… Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> [stable fixup: ->c.flc_type was ->fl_type in older kernels] Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/locks.c [Conflicts due to function refactor in fcntl_setlk()] Signed-off-by: Long Li <leo.lilong(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 6f27ec4f58da..5549b5a54ffd 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 OLK-6.6 0/1] kvm : add coda feature
by l00500167 06 Aug '24

06 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): part1 arch/arm64/include/asm/kvm_tmi.h | 93 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 150 +++- arch/arm64/kvm/virtcca_cvm.c | 2 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + drivers/vfio/pci/vfio_pci_core.c | 5 + drivers/vfio/pci/vfio_pci_rdwr.c | 61 ++ drivers/vfio/vfio_iommu_type1.c | 17 + drivers/vfio/vfio_main.c | 18 + include/linux/iommu.h | 9 + include/linux/iopoll.h | 38 + include/linux/pci.h | 4 + include/linux/vfio.h | 5 + include/uapi/linux/vfio.h | 3 + virt/kvm/vfio.c | 121 ++- virt/kvm/vfio.h | 10 + 20 files changed, 1714 insertions(+), 7 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

1 1

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

06 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): smmu secure init arch/arm64/include/asm/kvm_tmi.h | 93 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 150 +++- arch/arm64/kvm/virtcca_cvm.c | 2 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 811 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 175 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + include/linux/iommu.h | 4 + include/linux/iopoll.h | 38 + 11 files changed, 1466 insertions(+), 6 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 2

[openeuler:OLK-6.6 12414/13217] arch/arm64/kvm/arm.c:138:7: warning: variable 'r' is used uninitialized whenever 'if' condition is false
by kernel test robot 06 Aug '24

06 Aug '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: d59a335bf0dd2aac9debe211a0a07fbeaf605fed commit: 67e11ee6347c43a97e8987b03a5b3534cd8095d9 [12414/13217] kvm: add virtcca cvm host feature config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20240806/202408060639.d1BhjbnX-lkp@…) compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project 423aec6573df4424f90555468128e17073ddc69e) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240806/202408060639.d1BhjbnX-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/202408060639.d1BhjbnX-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from arch/arm64/kvm/arm.c:9: In file included from include/linux/entry-kvm.h:6: In file included from include/linux/resume_user_mode.h:8: In file included from include/linux/memcontrol.h:20: In file included from include/linux/mm.h:2242: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ >> arch/arm64/kvm/arm.c:138:7: warning: variable 'r' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] 138 | if (static_branch_unlikely(&virtcca_cvm_is_available)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/jump_label.h:504:40: note: expanded from macro 'static_branch_unlikely' 504 | #define static_branch_unlikely(x) \ | ^ 505 | ({ \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 506 | bool branch; \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 507 | if (__builtin_types_compatible_p(typeof(*x), struct static_key_true)) \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 508 | branch = arch_static_branch_jump(&(x)->key, false); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 509 | else if (__builtin_types_compatible_p(typeof(*x), struct static_key_false)) \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 510 | branch = arch_static_branch(&(x)->key, false); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 511 | else \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 512 | branch = ____wrong_branch_error(); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 513 | unlikely_notrace(branch); \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 514 | }) | ~~ arch/arm64/kvm/arm.c:147:9: note: uninitialized use occurs here 147 | return r; | ^ arch/arm64/kvm/arm.c:138:3: note: remove the 'if' if its condition is always true 138 | if (static_branch_unlikely(&virtcca_cvm_is_available)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 139 | r = kvm_cvm_enable_cap(kvm, cap); arch/arm64/kvm/arm.c:92:7: note: initialize the variable 'r' to silence this warning 92 | int r; | ^ | = 0 6 warnings generated. -- In file included from arch/arm64/kvm/tmi.c:6: In file included from arch/arm64/include/asm/kvm_tmi.h:8: In file included from include/linux/kvm_host.h:16: In file included from include/linux/mm.h:2242: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ >> arch/arm64/kvm/tmi.c:131:5: warning: no previous prototype for function 'tmi_tmm_inf_test' [-Wmissing-prototypes] 131 | u64 tmi_tmm_inf_test(u64 x1, u64 x2, u64 x3, u64 x4, u64 x5) | ^ arch/arm64/kvm/tmi.c:131:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 131 | u64 tmi_tmm_inf_test(u64 x1, u64 x2, u64 x3, u64 x4, u64 x5) | ^ | static 6 warnings generated. -- In file included from arch/arm64/kvm/virtcca_cvm.c:5: In file included from include/linux/kvm_host.h:16: In file included from include/linux/mm.h:2242: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ >> arch/arm64/kvm/virtcca_cvm.c:70:6: warning: no previous prototype for function 'kvm_cvm_supports_sve' [-Wmissing-prototypes] 70 | bool kvm_cvm_supports_sve(void) | ^ arch/arm64/kvm/virtcca_cvm.c:70:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 70 | bool kvm_cvm_supports_sve(void) | ^ | static >> arch/arm64/kvm/virtcca_cvm.c:75:6: warning: no previous prototype for function 'kvm_cvm_supports_pmu' [-Wmissing-prototypes] 75 | bool kvm_cvm_supports_pmu(void) | ^ arch/arm64/kvm/virtcca_cvm.c:75:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 75 | bool kvm_cvm_supports_pmu(void) | ^ | static >> arch/arm64/kvm/virtcca_cvm.c:80:5: warning: no previous prototype for function 'kvm_cvm_ipa_limit' [-Wmissing-prototypes] 80 | u32 kvm_cvm_ipa_limit(void) | ^ arch/arm64/kvm/virtcca_cvm.c:80:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 80 | u32 kvm_cvm_ipa_limit(void) | ^ | static >> arch/arm64/kvm/virtcca_cvm.c:85:5: warning: no previous prototype for function 'kvm_cvm_get_num_brps' [-Wmissing-prototypes] 85 | u32 kvm_cvm_get_num_brps(void) | ^ arch/arm64/kvm/virtcca_cvm.c:85:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 85 | u32 kvm_cvm_get_num_brps(void) | ^ | static >> arch/arm64/kvm/virtcca_cvm.c:90:5: warning: no previous prototype for function 'kvm_cvm_get_num_wrps' [-Wmissing-prototypes] 90 | u32 kvm_cvm_get_num_wrps(void) | ^ arch/arm64/kvm/virtcca_cvm.c:90:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 90 | u32 kvm_cvm_get_num_wrps(void) | ^ | static >> arch/arm64/kvm/virtcca_cvm.c:244:5: warning: no previous prototype for function 'kvm_cvm_create_ttt_levels' [-Wmissing-prototypes] 244 | int kvm_cvm_create_ttt_levels(struct kvm *kvm, struct virtcca_cvm *cvm, | ^ arch/arm64/kvm/virtcca_cvm.c:244:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 244 | int kvm_cvm_create_ttt_levels(struct kvm *kvm, struct virtcca_cvm *cvm, | ^ | static >> arch/arm64/kvm/virtcca_cvm.c:311:5: warning: no previous prototype for function 'kvm_cvm_populate_par_region' [-Wmissing-prototypes] 311 | int kvm_cvm_populate_par_region(struct kvm *kvm, u64 numa_set, | ^ arch/arm64/kvm/virtcca_cvm.c:311:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 311 | int kvm_cvm_populate_par_region(struct kvm *kvm, u64 numa_set, | ^ | static 12 warnings generated. vim +138 arch/arm64/kvm/arm.c 88 89 int kvm_vm_ioctl_enable_cap(struct kvm *kvm, 90 struct kvm_enable_cap *cap) 91 { 92 int r; 93 u64 new_cap; 94 95 if (cap->flags) 96 return -EINVAL; 97 98 switch (cap->cap) { 99 case KVM_CAP_ARM_NISV_TO_USER: 100 r = 0; 101 set_bit(KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER, 102 &kvm->arch.flags); 103 break; 104 case KVM_CAP_ARM_MTE: 105 mutex_lock(&kvm->lock); 106 if (!system_supports_mte() || kvm->created_vcpus) { 107 r = -EINVAL; 108 } else { 109 r = 0; 110 set_bit(KVM_ARCH_FLAG_MTE_ENABLED, &kvm->arch.flags); 111 } 112 mutex_unlock(&kvm->lock); 113 break; 114 case KVM_CAP_ARM_SYSTEM_SUSPEND: 115 r = 0; 116 set_bit(KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED, &kvm->arch.flags); 117 break; 118 case KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE: 119 new_cap = cap->args[0]; 120 121 mutex_lock(&kvm->slots_lock); 122 /* 123 * To keep things simple, allow changing the chunk 124 * size only when no memory slots have been created. 125 */ 126 if (!kvm_are_all_memslots_empty(kvm)) { 127 r = -EINVAL; 128 } else if (new_cap && !kvm_is_block_size_supported(new_cap)) { 129 r = -EINVAL; 130 } else { 131 r = 0; 132 kvm->arch.mmu.split_page_chunk_size = new_cap; 133 } 134 mutex_unlock(&kvm->slots_lock); 135 break; 136 #ifdef CONFIG_HISI_VIRTCCA_HOST 137 case KVM_CAP_ARM_TMM: > 138 if (static_branch_unlikely(&virtcca_cvm_is_available)) 139 r = kvm_cvm_enable_cap(kvm, cap); 140 break; 141 #endif 142 default: 143 r = -EINVAL; 144 break; 145 } 146 147 return r; 148 } 149 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 13192/23440] drivers/crypto/hisilicon/rde/rde_main.c:576:6: warning: no previous prototype for 'hisi_rde_hw_error_log'
by kernel test robot 06 Aug '24

06 Aug '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: f10f25f5188cddb47d7a8a4ddf63c200b33e5b49 commit: 73d33f5c59dc3824444baca6a458427f4de3d8fa [13192/23440] qm: Move all the same logic functions of hisilicon crypto to qm config: arm64-randconfig-002-20240806 (https://download.01.org/0day-ci/archive/20240806/202408060608.ESB5dO3f-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240806/202408060608.ESB5dO3f-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/202408060608.ESB5dO3f-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/crypto/hisilicon/rde/rde_main.c:576:6: warning: no previous prototype for 'hisi_rde_hw_error_log' [-Wmissing-prototypes] 576 | void hisi_rde_hw_error_log(struct hisi_qm *qm, u32 err_sts) | ^~~~~~~~~~~~~~~~~~~~~ >> drivers/crypto/hisilicon/rde/rde_main.c:607:5: warning: no previous prototype for 'hisi_rde_get_hw_err_status' [-Wmissing-prototypes] 607 | u32 hisi_rde_get_hw_err_status(struct hisi_qm *qm) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/crypto/hisilicon/rde/rde_main.c:612:6: warning: no previous prototype for 'hisi_rde_clear_hw_err_status' [-Wmissing-prototypes] 612 | void hisi_rde_clear_hw_err_status(struct hisi_qm *qm, u32 err_sts) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ vim +/hisi_rde_hw_error_log +576 drivers/crypto/hisilicon/rde/rde_main.c 575 > 576 void hisi_rde_hw_error_log(struct hisi_qm *qm, u32 err_sts) 577 { 578 const struct hisi_rde_hw_error *err = rde_hw_error; 579 struct device *dev = &qm->pdev->dev; 580 u32 err_val; 581 582 while (err->msg) { 583 if (err->int_msk & err_sts) 584 dev_err_ratelimited(dev, 585 "[%s] [Error status=0x%x] found.\n", 586 err->msg, err->int_msk); 587 err++; 588 } 589 590 if (HRDE_ECC_2BIT_ERR & err_sts) { 591 err_val = (readl(qm->io_base + HRDE_ERR_CNT) & 592 HRDE_ECC_2BIT_CNT_MSK); 593 dev_err_ratelimited(dev, 594 "Rde ecc 2bit sram num=0x%x.\n", err_val); 595 } 596 597 if (HRDE_STATE_INT_ERR & err_sts) { 598 err_val = readl(qm->io_base + HRDE_AM_CURR_PORT_STS); 599 dev_err_ratelimited(dev, 600 "Rde ooo cur port sts=0x%x.\n", err_val); 601 err_val = readl(qm->io_base + HRDE_MASTER_TRANS_RET); 602 dev_err_ratelimited(dev, 603 "Rde ooo outstanding sts=0x%x.\n", err_val); 604 } 605 } 606 > 607 u32 hisi_rde_get_hw_err_status(struct hisi_qm *qm) 608 { 609 return readl(qm->io_base + HRDE_INT_STATUS); 610 } 611 > 612 void hisi_rde_clear_hw_err_status(struct hisi_qm *qm, u32 err_sts) 613 { 614 writel(err_sts, qm->io_base + HRDE_INT_SOURCE); 615 } 616 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

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

05 Aug '24

From: JunBin Li <lijunbin4(a)huawei.com> virtCCA feature JunBin Li (1): smmu secure init arch/arm64/include/asm/kvm_tmi.h | 81 +- arch/arm64/include/asm/kvm_tmm.h | 22 + arch/arm64/kvm/tmi.c | 140 ++- arch/arm64/kvm/virtcca_cvm.c | 2 +- drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 809 ++++++++++++++++++ drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h | 160 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 178 +++- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 16 + include/linux/iommu.h | 4 + include/linux/iopoll.h | 38 + 11 files changed, 1446 insertions(+), 5 deletions(-) create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.h -- 2.25.1

2 2

[PATCH OLK-6.6] filelock: Remove locks reliably when fcntl/close race is detected
by Long Li 05 Aug '24

05 Aug '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v6.6.41 commit 5f5d0799eb0a01d550c21b7894e26b2d9db55763 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAF3IR CVE: CVE-2024-41012 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit 3cad1bc010416c6dd780643476bc59ed742436b9 upstream. When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. In theory (but AFAIK not in practice), posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in enforcing mode and only works from some security contexts. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). 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/20240702-fs-lock-recover-2-v1-1-edd456f63789@goog… Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> [stable fixup: ->c.flc_type was ->fl_type in older kernels] Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Long Li <leo.lilong(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..a7df032d0437 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2381,8 +2381,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 && @@ -2397,9 +2398,7 @@ int fcntl_setlk(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 openEuler-1.0-LTS] filelock: Remove locks reliably when fcntl/close race is detected
by Long Li 05 Aug '24

05 Aug '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v4.19.316 commit d30ff33040834c3b9eee29740acd92f9c7ba2250 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAF3IR CVE: CVE-2024-41012 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit 3cad1bc010416c6dd780643476bc59ed742436b9 upstream. When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. In theory (but AFAIK not in practice), posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in enforcing mode and only works from some security contexts. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). 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/20240702-fs-lock-recover-2-v1-1-edd456f63789@goog… Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> [stable fixup: ->c.flc_type was ->fl_type in older kernels] Signed-off-by: Jann Horn <jannh(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Long Li <leo.lilong(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..557568e03188 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2298,8 +2298,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 && @@ -2313,9 +2314,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 OLK-6.6 0/2] Backport vmalloc 2 bugfix
by Peng Zhang 05 Aug '24

05 Aug '24

From: ZhangPeng <zhangpeng362(a)huawei.com> Backport vmalloc 2 bugfix for OLK-6.6. Uladzislau Rezki (Sony) (1): mm: vmalloc: fix lockdep warning rulinhuang (1): mm/vmalloc: eliminated the lock contention from twice to once mm/vmalloc.c | 123 +++++++++++++++++++++++++++------------------------ 1 file changed, 65 insertions(+), 58 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-22.03-LTS-SP1] net/iucv: Avoid explicit cpumask var allocation on stack
by Zhang Changzhong 05 Aug '24

05 Aug '24

From: Dawei Li <dawei.li(a)shingroup.cn> stable inclusion from stable-v5.10.221 commit 9dadab0db7d904413ea1cdaa13f127da05c31e71 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP9 CVE: CVE-2024-42094 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit be4e1304419c99a164b4c0e101c7c2a756b635b9 ] For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li <dawei.li(a)shingroup.cn> Reviewed-by: Alexandra Winter <wintera(a)linux.ibm.com> Link: https://lore.kernel.org/r/20240331053441.1276826-2-dawei.li@shingroup.cn Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- net/iucv/iucv.c | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/net/iucv/iucv.c b/net/iucv/iucv.c index 349c6ac..da8213b 100644 --- a/net/iucv/iucv.c +++ b/net/iucv/iucv.c @@ -517,7 +517,7 @@ static void iucv_setmask_mp(void) */ static void iucv_setmask_up(void) { - cpumask_t cpumask; + static cpumask_t cpumask; int cpu; /* Disable all cpu but the first in cpu_irq_cpumask. */ @@ -625,23 +625,33 @@ static int iucv_cpu_online(unsigned int cpu) static int iucv_cpu_down_prep(unsigned int cpu) { - cpumask_t cpumask; + cpumask_var_t cpumask; + int ret = 0; if (!iucv_path_table) return 0; - cpumask_copy(&cpumask, &iucv_buffer_cpumask); - cpumask_clear_cpu(cpu, &cpumask); - if (cpumask_empty(&cpumask)) + if (!alloc_cpumask_var(&cpumask, GFP_KERNEL)) + return -ENOMEM; + + cpumask_copy(cpumask, &iucv_buffer_cpumask); + cpumask_clear_cpu(cpu, cpumask); + if (cpumask_empty(cpumask)) { /* Can't offline last IUCV enabled cpu. */ - return -EINVAL; + ret = -EINVAL; + goto __free_cpumask; + } iucv_retrieve_cpu(NULL); if (!cpumask_empty(&iucv_irq_cpumask)) - return 0; + goto __free_cpumask; + smp_call_function_single(cpumask_first(&iucv_buffer_cpumask), iucv_allow_cpu, NULL, 1); - return 0; + +__free_cpumask: + free_cpumask_var(cpumask); + return ret; } /** -- 2.9.5

2 1

[PATCH OLK-5.10] net/iucv: Avoid explicit cpumask var allocation on stack
by Zhang Changzhong 05 Aug '24

05 Aug '24

From: Dawei Li <dawei.li(a)shingroup.cn> stable inclusion from stable-v5.10.221 commit 9dadab0db7d904413ea1cdaa13f127da05c31e71 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP9 CVE: CVE-2024-42094 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit be4e1304419c99a164b4c0e101c7c2a756b635b9 ] For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li <dawei.li(a)shingroup.cn> Reviewed-by: Alexandra Winter <wintera(a)linux.ibm.com> Link: https://lore.kernel.org/r/20240331053441.1276826-2-dawei.li@shingroup.cn Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- net/iucv/iucv.c | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/net/iucv/iucv.c b/net/iucv/iucv.c index 6f84978..9d6449f 100644 --- a/net/iucv/iucv.c +++ b/net/iucv/iucv.c @@ -517,7 +517,7 @@ static void iucv_setmask_mp(void) */ static void iucv_setmask_up(void) { - cpumask_t cpumask; + static cpumask_t cpumask; int cpu; /* Disable all cpu but the first in cpu_irq_cpumask. */ @@ -625,23 +625,33 @@ static int iucv_cpu_online(unsigned int cpu) static int iucv_cpu_down_prep(unsigned int cpu) { - cpumask_t cpumask; + cpumask_var_t cpumask; + int ret = 0; if (!iucv_path_table) return 0; - cpumask_copy(&cpumask, &iucv_buffer_cpumask); - cpumask_clear_cpu(cpu, &cpumask); - if (cpumask_empty(&cpumask)) + if (!alloc_cpumask_var(&cpumask, GFP_KERNEL)) + return -ENOMEM; + + cpumask_copy(cpumask, &iucv_buffer_cpumask); + cpumask_clear_cpu(cpu, cpumask); + if (cpumask_empty(cpumask)) { /* Can't offline last IUCV enabled cpu. */ - return -EINVAL; + ret = -EINVAL; + goto __free_cpumask; + } iucv_retrieve_cpu(NULL); if (!cpumask_empty(&iucv_irq_cpumask)) - return 0; + goto __free_cpumask; + smp_call_function_single(cpumask_first(&iucv_buffer_cpumask), iucv_allow_cpu, NULL, 1); - return 0; + +__free_cpumask: + free_cpumask_var(cpumask); + return ret; } /** -- 2.9.5

2 1

[PATCH OLK-5.10 v2 0/3] blk-wbt: don't throttle swap writes in direct reclaim
by Yu Kuai 05 Aug '24

05 Aug '24

Baokun Li (1): blk-wbt: don't throttle swap writes in direct reclaim Christoph Hellwig (1): blk-wbt: move private information from blk-wbt.h to blk-wbt.c Tom Rix (1): blk-wbt: remove wbt_track stub block/blk-mq-sched.c | 1 + block/blk-settings.c | 1 + block/blk-sysfs.c | 1 + block/blk-wbt.c | 91 ++++++++++++++++++++++++++++++++++++++++---- block/blk-wbt.h | 89 ------------------------------------------- block/elevator.c | 1 + 6 files changed, 88 insertions(+), 96 deletions(-) -- 2.39.2

2 4

[PATCH OLK-5.10] scsi: qedf: Make qedf_execute_tmf() non-preemptible
by Yu Liao 05 Aug '24

05 Aug '24

From: John Meneghini <jmeneghi(a)redhat.com> stable inclusion from stable-v5.10.222 commit 5ceb40cdee721e13cbe15a0515cacf984e11236b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGTJ2 CVE: CVE-2024-42124 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0d8b637c9c5eeaa1a4e3dfb336f3ff918eb64fec ] Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel. [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf] Tested-by: Guangwu Zhang <guazhang(a)redhat.com> Cc: Saurav Kashyap <skashyap(a)marvell.com> Cc: Nilesh Javali <njavali(a)marvell.com> Signed-off-by: John Meneghini <jmeneghi(a)redhat.com> Link: https://lore.kernel.org/r/20240403150155.412954-1-jmeneghi@redhat.com Acked-by: Saurav Kashyap <skashyap(a)marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- drivers/scsi/qedf/qedf_io.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/qedf/qedf_io.c b/drivers/scsi/qedf/qedf_io.c index 1f8e81296beb..70f920f4b7a1 100644 --- a/drivers/scsi/qedf/qedf_io.c +++ b/drivers/scsi/qedf/qedf_io.c @@ -2351,9 +2351,6 @@ static int qedf_execute_tmf(struct qedf_rport *fcport, struct scsi_cmnd *sc_cmd, io_req->fcport = fcport; io_req->cmd_type = QEDF_TASK_MGMT_CMD; - /* Record which cpu this request is associated with */ - io_req->cpu = smp_processor_id(); - /* Set TM flags */ io_req->io_req_flags = QEDF_READ; io_req->data_xfer_len = 0; @@ -2375,6 +2372,9 @@ static int qedf_execute_tmf(struct qedf_rport *fcport, struct scsi_cmnd *sc_cmd, spin_lock_irqsave(&fcport->rport_lock, flags); + /* Record which cpu this request is associated with */ + io_req->cpu = smp_processor_id(); + sqe_idx = qedf_get_sqe_idx(fcport); sqe = &fcport->sq[sqe_idx]; memset(sqe, 0, sizeof(struct fcoe_wqe)); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] scsi: qedf: Make qedf_execute_tmf() non-preemptible
by Yu Liao 05 Aug '24

05 Aug '24

From: John Meneghini <jmeneghi(a)redhat.com> stable inclusion from stable-v5.10.222 commit 5ceb40cdee721e13cbe15a0515cacf984e11236b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGTJ2 CVE: CVE-2024-42124 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0d8b637c9c5eeaa1a4e3dfb336f3ff918eb64fec ] Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel. [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf] Tested-by: Guangwu Zhang <guazhang(a)redhat.com> Cc: Saurav Kashyap <skashyap(a)marvell.com> Cc: Nilesh Javali <njavali(a)marvell.com> Signed-off-by: John Meneghini <jmeneghi(a)redhat.com> Link: https://lore.kernel.org/r/20240403150155.412954-1-jmeneghi@redhat.com Acked-by: Saurav Kashyap <skashyap(a)marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- drivers/scsi/qedf/qedf_io.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/qedf/qedf_io.c b/drivers/scsi/qedf/qedf_io.c index 1f8e81296beb..70f920f4b7a1 100644 --- a/drivers/scsi/qedf/qedf_io.c +++ b/drivers/scsi/qedf/qedf_io.c @@ -2351,9 +2351,6 @@ static int qedf_execute_tmf(struct qedf_rport *fcport, struct scsi_cmnd *sc_cmd, io_req->fcport = fcport; io_req->cmd_type = QEDF_TASK_MGMT_CMD; - /* Record which cpu this request is associated with */ - io_req->cpu = smp_processor_id(); - /* Set TM flags */ io_req->io_req_flags = QEDF_READ; io_req->data_xfer_len = 0; @@ -2375,6 +2372,9 @@ static int qedf_execute_tmf(struct qedf_rport *fcport, struct scsi_cmnd *sc_cmd, spin_lock_irqsave(&fcport->rport_lock, flags); + /* Record which cpu this request is associated with */ + io_req->cpu = smp_processor_id(); + sqe_idx = qedf_get_sqe_idx(fcport); sqe = &fcport->sq[sqe_idx]; memset(sqe, 0, sizeof(struct fcoe_wqe)); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] net/iucv: Avoid explicit cpumask var allocation on stack
by Zhang Changzhong 05 Aug '24

05 Aug '24

From: Dawei Li <dawei.li(a)shingroup.cn> stable inclusion from stable-v4.19.317 commit 2b085521be5292016097b5e7ca81b26be3f7098d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEP9 CVE: CVE-2024-42094 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit be4e1304419c99a164b4c0e101c7c2a756b635b9 ] For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. Signed-off-by: Dawei Li <dawei.li(a)shingroup.cn> Reviewed-by: Alexandra Winter <wintera(a)linux.ibm.com> Link: https://lore.kernel.org/r/20240331053441.1276826-2-dawei.li@shingroup.cn Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- net/iucv/iucv.c | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/net/iucv/iucv.c b/net/iucv/iucv.c index eb502c6..aed216f 100644 --- a/net/iucv/iucv.c +++ b/net/iucv/iucv.c @@ -578,7 +578,7 @@ static void iucv_setmask_mp(void) */ static void iucv_setmask_up(void) { - cpumask_t cpumask; + static cpumask_t cpumask; int cpu; /* Disable all cpu but the first in cpu_irq_cpumask. */ @@ -686,23 +686,33 @@ static int iucv_cpu_online(unsigned int cpu) static int iucv_cpu_down_prep(unsigned int cpu) { - cpumask_t cpumask; + cpumask_var_t cpumask; + int ret = 0; if (!iucv_path_table) return 0; - cpumask_copy(&cpumask, &iucv_buffer_cpumask); - cpumask_clear_cpu(cpu, &cpumask); - if (cpumask_empty(&cpumask)) + if (!alloc_cpumask_var(&cpumask, GFP_KERNEL)) + return -ENOMEM; + + cpumask_copy(cpumask, &iucv_buffer_cpumask); + cpumask_clear_cpu(cpu, cpumask); + if (cpumask_empty(cpumask)) { /* Can't offline last IUCV enabled cpu. */ - return -EINVAL; + ret = -EINVAL; + goto __free_cpumask; + } iucv_retrieve_cpu(NULL); if (!cpumask_empty(&iucv_irq_cpumask)) - return 0; + goto __free_cpumask; + smp_call_function_single(cpumask_first(&iucv_buffer_cpumask), iucv_allow_cpu, NULL, 1); - return 0; + +__free_cpumask: + free_cpumask_var(cpumask); + return ret; } /** -- 2.9.5

2 1

[PATCH OLK-6.6] btrfs: zoned: fix use-after-free in do_zone_finish()
by Wang Zhaolong 05 Aug '24

05 Aug '24

From: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> mainline inclusion from mainline-v6.11-rc1 commit 1ec17ef59168a1a6f1105f5dc517f783839a5302 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5G2 CVE: CVE-2024-26944 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0xb3/0x4e0 [btrfs] device_list_add.constprop.0+0x993/0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs] btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400) The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb This UAF happens because we're accessing stale zone information of a already removed btrfs_device in do_zone_finish(). The sequence of events is as follows: btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- device freed cleaner_kthread btrfs_delete_unused_bgs btrfs_zone_finish do_zone_finish <-- refers the freed device The reason for this is that we're using a cached pointer to the chunk_map from the block group, but on device replace this cached pointer can contain stale device entries. The staleness comes from the fact, that btrfs_block_group::physical_map is not a pointer to a btrfs_chunk_map but a memory copy of it. Also take the fs_info::dev_replace::rwsem to prevent btrfs_dev_replace_update_device_in_mapping_tree() from changing the device underneath us again. Note: btrfs_dev_replace_update_device_in_mapping_tree() is holding fs_info::mapping_tree_lock, but as this is a spinning read/write lock we cannot take it as the call to blkdev_zone_mgmt() requires a memory allocation which may not sleep. But btrfs_dev_replace_update_device_in_mapping_tree() is always called with the fs_info::dev_replace::rwsem held in write mode. Many thanks to Shinichiro for analyzing the bug. Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> CC: stable(a)vger.kernel.org # 6.8 Reviewed-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/zoned.c [The current code does not introduce the struct btrfs_chunk_map] Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/btrfs/zoned.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c index 2784f6cb4482..8c0ad5dc06f6 100644 --- a/fs/btrfs/zoned.c +++ b/fs/btrfs/zoned.c @@ -1476,11 +1476,7 @@ int btrfs_load_block_group_zone_info(struct btrfs_block_group *cache, bool new) map = em->map_lookup; - cache->physical_map = kmemdup(map, map_lookup_size(map->num_stripes), GFP_NOFS); - if (!cache->physical_map) { - ret = -ENOMEM; - goto out; - } + cache->physical_map = map; zone_info = kcalloc(map->num_stripes, sizeof(*zone_info), GFP_NOFS); if (!zone_info) { @@ -1583,7 +1579,6 @@ int btrfs_load_block_group_zone_info(struct btrfs_block_group *cache, bool new) } bitmap_free(active); kfree(zone_info); - free_extent_map(em); return ret; } @@ -2084,6 +2079,7 @@ static int do_zone_finish(struct btrfs_block_group *block_group, bool fully_writ struct map_lookup *map; const bool is_metadata = (block_group->flags & (BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_SYSTEM)); + struct btrfs_dev_replace *dev_replace = &fs_info->dev_replace; int ret = 0; int i; @@ -2159,6 +2155,7 @@ static int do_zone_finish(struct btrfs_block_group *block_group, bool fully_writ btrfs_clear_data_reloc_bg(block_group); spin_unlock(&block_group->lock); + down_read(&dev_replace->rwsem); map = block_group->physical_map; for (i = 0; i < map->num_stripes; i++) { struct btrfs_device *device = map->stripes[i].dev; @@ -2173,13 +2170,16 @@ static int do_zone_finish(struct btrfs_block_group *block_group, bool fully_writ zinfo->zone_size >> SECTOR_SHIFT, GFP_NOFS); - if (ret) + if (ret) { + up_read(&dev_replace->rwsem); return ret; + } if (!(block_group->flags & BTRFS_BLOCK_GROUP_DATA)) zinfo->reserved_active_zones++; btrfs_dev_clear_active_zone(device, physical); } + up_read(&dev_replace->rwsem); if (!fully_written) btrfs_dec_block_group_ro(block_group); -- 2.34.3

2 1

[PATCH OLK-5.10 0/2] blk-wbt: don't throttle swap writes in direct reclaim
by Yu Kuai 05 Aug '24

05 Aug '24

Baokun Li (1): blk-wbt: don't throttle swap writes in direct reclaim Christoph Hellwig (1): blk-wbt: move private information from blk-wbt.h to blk-wbt.c block/blk-mq-sched.c | 1 + block/blk-settings.c | 1 + block/blk-sysfs.c | 1 + block/blk-wbt.c | 91 ++++++++++++++++++++++++++++++++++++++++---- block/blk-wbt.h | 86 ----------------------------------------- block/elevator.c | 1 + 6 files changed, 88 insertions(+), 93 deletions(-) -- 2.39.2

2 3