- Kernel - mailweb.openeuler.org

[openeuler:OLK-5.10] BUILD SUCCESS 4fee6fdef7d687d6ce43289fd7e7f96fde039af0
by kernel test robot 24 Feb '24

24 Feb '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 4fee6fdef7d687d6ce43289fd7e7f96fde039af0 !4662 v3 CVE-2023-52435 elapsed time: 822m configs tested: 11 configs skipped: 131 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240224 gcc arm64 randconfig-002-20240224 gcc arm64 randconfig-003-20240224 clang arm64 randconfig-004-20240224 clang x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 defconfig gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH V5 OLK-6.6 00/13] Backport vDPA migration support patches
by Jiang Dongxu 23 Feb '24

23 Feb '24

From: shaodenghui <shaodenghui(a)huawei.com> Backport vDPA migration support patches merged on branch OLK-5.10 V5: fix compile error of kernel-6.6 new vdpa driver eni_vdpa V4: add CONFIG_VHOST_VDPA_MIGRATION to control vdpa migration code compile or not. V3: fix compile error of kernel-6.6 new vdpa driver pds_vdpa V2: fix compile error of kernel-6.6 new vdpa driver vduse and snet_vdpa jiangdongxu (13): vdpa: add log operations vhost-vdpa: add uAPI for logging vdpa: add device state operations vhost-vdpa: add uAPI for device buffer vdpa: add vdpa device migration status ops vhost-vdpa: add uAPI for device migration status vhost: add VHOST feature VHOST_BACKEND_F_BYTEMAPLOG vhost-vdpa: Allow transparent MSI IOV vhost-vdpa: fix msi irq request err vhost-vdpa: allow set feature VHOST_F_LOG_ALL when been negotiated. vhost-vdpa: add reset state params to indicate reset level vdpa: add vmstate header file vdpa: add CONFIG_VHOST_VDPA_MIGRATION arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + drivers/vdpa/alibaba/eni_vdpa.c | 2 +- drivers/vdpa/ifcvf/ifcvf_main.c | 2 +- drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +- drivers/vdpa/pds/vdpa_dev.c | 2 +- drivers/vdpa/solidrun/snet_main.c | 2 +- drivers/vdpa/vdpa_sim/vdpa_sim.c | 2 +- drivers/vdpa/vdpa_user/vduse_dev.c | 2 +- drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +- drivers/vhost/Kconfig | 11 ++ drivers/vhost/vdpa.c | 238 ++++++++++++++++++++++--- drivers/virtio/virtio_vdpa.c | 2 +- include/linux/vdpa.h | 56 +++++- include/linux/vdpa_vmstate.h | 182 +++++++++++++++++++ include/uapi/linux/vhost.h | 12 ++ include/uapi/linux/vhost_types.h | 19 ++ 17 files changed, 506 insertions(+), 32 deletions(-) create mode 100644 include/linux/vdpa_vmstate.h -- 2.27.0

2 14

[PATCH OLK-6.6] kvm: kabi: KABI reservation for RME
by Guangwei Zhou 23 Feb '24

23 Feb '24

driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I92TT5 CVE: NA ---------------------------------------------------------------------- Reserve KABI for struct kvm_arch and struct kvm_vcpu_arch for ARMv9 RME feature. Signed-off-by: Guangwei Zhou <zhouguangwei5(a)huawei.com> --- arch/arm64/include/asm/kvm_host.h | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index bd7552746f9e..69d4d9466a4f 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -27,6 +27,7 @@ #include <asm/fpsimd.h> #include <asm/kvm.h> #include <asm/kvm_asm.h> +#include <linux/kabi.h> #define __KVM_HAVE_ARCH_INTC_INITIALIZED @@ -279,6 +280,15 @@ struct kvm_arch { * the associated pKVM instance in the hypervisor. */ struct kvm_protected_vm pkvm; + + KABI_RESERVE(1) + KABI_RESERVE(2) + KABI_RESERVE(3) + KABI_RESERVE(4) + KABI_RESERVE(5) + KABI_RESERVE(6) + KABI_RESERVE(7) + KABI_RESERVE(8) }; struct kvm_vcpu_fault_info { @@ -591,6 +601,26 @@ struct kvm_vcpu_arch { /* Per-vcpu CCSIDR override or NULL */ u32 *ccsidr; + + KABI_RESERVE(1) + KABI_RESERVE(2) + KABI_RESERVE(3) + KABI_RESERVE(4) + KABI_RESERVE(5) + KABI_RESERVE(6) + KABI_RESERVE(7) + KABI_RESERVE(8) + KABI_RESERVE(9) + KABI_RESERVE(10) + KABI_RESERVE(11) + KABI_RESERVE(12) + KABI_RESERVE(13) + KABI_RESERVE(14) + KABI_RESERVE(15) + KABI_RESERVE(16) + KABI_RESERVE(17) + KABI_RESERVE(18) + KABI_RESERVE(19) }; /* -- 2.33.0

2 1

[PATCH OLK-5.10] uio: Fix use-after-free in uio_open
by Guo Mengqi 23 Feb '24

23 Feb '24

From: Guanghui Feng <guanghuifeng(a)linux.alibaba.com> stable inclusion from stable-v5.10.209 commit 5e0be1229ae199ebb90b33102f74a0f22d152570 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I92HXN CVE: CVE-2023-52439 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0c9ae0b8605078eafc3bea053cc78791e97ba2e2 upstream. core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock. Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered") Cc: stable <stable(a)kernel.org> Signed-off-by: Guanghui Feng <guanghuifeng(a)linux.alibaba.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Link: https://lore.kernel.org/r/1703152663-59949-1-git-send-email-guanghuifeng@li… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/uio/uio.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index be06f1a961c2..f453b3c7ee42 100644 --- a/drivers/uio/uio.c +++ b/drivers/uio/uio.c @@ -464,13 +464,13 @@ static int uio_open(struct inode *inode, struct file *filep) mutex_lock(&minor_lock); idev = idr_find(&uio_idr, iminor(inode)); - mutex_unlock(&minor_lock); if (!idev) { ret = -ENODEV; + mutex_unlock(&minor_lock); goto out; } - get_device(&idev->dev); + mutex_unlock(&minor_lock); if (!try_module_get(idev->owner)) { ret = -ENODEV; @@ -1062,9 +1062,8 @@ void uio_unregister_device(struct uio_info *info) wake_up_interruptible(&idev->wait); kill_fasync(&idev->async_queue, SIGIO, POLL_HUP); - device_unregister(&idev->dev); - uio_free_minor(minor); + device_unregister(&idev->dev); return; } -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] uio: Fix use-after-free in uio_open
by Guo Mengqi 23 Feb '24

23 Feb '24

From: Guanghui Feng <guanghuifeng(a)linux.alibaba.com> stable inclusion from stable-v4.19.306 commit 3174e0f7de1ba392dc191625da83df02d695b60c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I92HXN CVE: CVE-2023-52439 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0c9ae0b8605078eafc3bea053cc78791e97ba2e2 upstream. core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock. Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered") Cc: stable <stable(a)kernel.org> Signed-off-by: Guanghui Feng <guanghuifeng(a)linux.alibaba.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Link: https://lore.kernel.org/r/1703152663-59949-1-git-send-email-guanghuifeng@li… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/uio/uio.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index f43498e5cfb8..facccb36f692 100644 --- a/drivers/uio/uio.c +++ b/drivers/uio/uio.c @@ -464,13 +464,13 @@ static int uio_open(struct inode *inode, struct file *filep) mutex_lock(&minor_lock); idev = idr_find(&uio_idr, iminor(inode)); - mutex_unlock(&minor_lock); if (!idev) { ret = -ENODEV; + mutex_unlock(&minor_lock); goto out; } - get_device(&idev->dev); + mutex_unlock(&minor_lock); if (!try_module_get(idev->owner)) { ret = -ENODEV; @@ -1024,9 +1024,8 @@ void uio_unregister_device(struct uio_info *info) wake_up_interruptible(&idev->wait); kill_fasync(&idev->async_queue, SIGIO, POLL_HUP); - device_unregister(&idev->dev); - uio_free_minor(minor); + device_unregister(&idev->dev); return; } -- 2.17.1

2 1

[PATCH OLK-6.6 0/3] audit: Backport mainline patches
by GUO Zihua 23 Feb '24

23 Feb '24

This series backports mainline bugfixes for audit. Jan Kara (3): audit_tree: Remove mark->lock locking audit: Fix possible spurious -ENOSPC error audit: Fix possible tagging failures kernel/audit_tree.c | 61 ++++++++++++++++++++------------------------- 1 file changed, 27 insertions(+), 34 deletions(-) -- 2.34.1

2 4

[PATCH OLK-6.6 0/1] keys: safe concurrent user->{session,uid}_keyring access
by GUO Zihua 23 Feb '24

23 Feb '24

This patch backports mainline bugfix commit 0b9dc6c9f01c ("keys: safe concurrent user->{session,uid}_keyring access") Jann Horn (1): keys: safe concurrent user->{session,uid}_keyring access include/linux/sched/user.h | 7 +++++++ security/keys/process_keys.c | 31 +++++++++++++++++-------------- security/keys/request_key.c | 5 +++-- 3 files changed, 27 insertions(+), 16 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/1] keys: safe concurrent user->{session,uid}_keyring access
by GUO Zihua 23 Feb '24

23 Feb '24

This patch backports mainline bugfix commit 0b9dc6c9f01c ("keys: safe concurrent user->{session,uid}_keyring access") Jann Horn (1): keys: safe concurrent user->{session,uid}_keyring access include/linux/sched/user.h | 7 +++++++ security/keys/process_keys.c | 31 +++++++++++++++++-------------- security/keys/request_key.c | 5 +++-- 3 files changed, 27 insertions(+), 16 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/3] audit: Backport mainline patches
by GUO Zihua 23 Feb '24

23 Feb '24

Backported mainline bugfix for audit. Jan Kara (3): audit_tree: Remove mark->lock locking audit: Fix possible spurious -ENOSPC error audit: Fix possible tagging failures kernel/audit_tree.c | 61 ++++++++++++++++++++------------------------- 1 file changed, 27 insertions(+), 34 deletions(-) -- 2.34.1

2 4

[PATCH OLK-6.6 1/5] driver/svm: support SVSP feature, interface definition
by Yuan Can 23 Feb '24

23 Feb '24

From: Zhou Guanghui <zhouguanghui1(a)huawei.com> ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I931MI CVE: NA ----------------------------------------------------------------- In the SVA scenario, the master device of the SMMU can access the address space of the process by the operation of binding process. The page table of the process is shared by the MMU and SMMU, In this case, if some addrss range cannot be accessed through the MMU, access to this address range needs to be isolated from the process page table. If the default domain of the SMMU is used, the isolation can be achieved. However, the address space created by default domain do not like the address space of the process which can be shared by multiple SMMUs. Therefore, we add a shadow virtual space of process. This address space is used only by the SMMU. Signed-off-by: Zhou Guanghui <zhouguanghui1(a)huawei.com> --- arch/arm64/Kconfig | 15 +++++++++++++++ kernel/fork.c | 1 + mm/mmap.c | 1 + 3 files changed, 17 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 67bc2ad13453..3e84b2572827 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -2455,6 +2455,21 @@ config DMI However, even with this option, the resultant kernel should continue to boot on existing non-UEFI platforms. +config ASCEND_SVSP + bool "Enable support for SVSP" + default n + depends on ARM_SMMU_V3_SVA + help + SVSP means Shadow Virtual Space of Process, which is an IO space used for + master device of SMMU. + + This space is only used for the master device, since the target address + after traslation by MMU is not an accessible physical address, but can + accessible by SMMU. + + Therefore, in the sva scenario, an svsp is created for each target process + address space. + endmenu # "Boot options" config COMPAT diff --git a/kernel/fork.c b/kernel/fork.c index 00e5886c9e04..735bc670b49e 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1373,6 +1373,7 @@ struct mm_struct *mm_alloc(void) memset(mm, 0, sizeof(*mm)); return mm_init(mm, current, current_user_ns()); } +EXPORT_SYMBOL_GPL(mm_alloc); static inline void __mmput(struct mm_struct *mm) { diff --git a/mm/mmap.c b/mm/mmap.c index 21d1fc39bf21..5d78ebaeed60 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2684,6 +2684,7 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len, return do_vmi_munmap(&vmi, mm, start, len, uf, false); } +EXPORT_SYMBOL(do_munmap); static unsigned long __mmap_region(struct mm_struct *mm, struct file *file, unsigned long addr, -- 2.17.1

3 7