From: Greg Kroah-Hartman Date: Sat, 3 Apr 2021 09:00:36 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.4.265~46 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c2fc142009b4e6f7ada081cbfd5b9ef85db62c9b;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: drm-amdgpu-check-alignment-on-cpu-page-for-bo-map.patch drm-amdgpu-fix-offset-calculation-in-amdgpu_vm_bo_clear_mappings.patch drm-amdkfd-dqm-fence-memory-corruption.patch mm-fix-race-by-making-init_zero_pfn-early_initcall.patch reiserfs-update-reiserfs_xattrs_initialized-condition.patch --- diff --git a/queue-5.10/drm-amdgpu-check-alignment-on-cpu-page-for-bo-map.patch b/queue-5.10/drm-amdgpu-check-alignment-on-cpu-page-for-bo-map.patch new file mode 100644 index 00000000000..f9b962f4d21 --- /dev/null +++ b/queue-5.10/drm-amdgpu-check-alignment-on-cpu-page-for-bo-map.patch @@ -0,0 +1,49 @@ +From e3512fb67093fabdf27af303066627b921ee9bd8 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?X=E2=84=B9=20Ruoyao?= +Date: Tue, 30 Mar 2021 23:33:34 +0800 +Subject: drm/amdgpu: check alignment on CPU page for bo map +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Xℹ Ruoyao + +commit e3512fb67093fabdf27af303066627b921ee9bd8 upstream. + +The page table of AMDGPU requires an alignment to CPU page so we should +check ioctl parameters for it. Return -EINVAL if some parameter is +unaligned to CPU page, instead of corrupt the page table sliently. + +Reviewed-by: Christian König +Signed-off-by: Xi Ruoyao +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +@@ -2223,8 +2223,8 @@ int amdgpu_vm_bo_map(struct amdgpu_devic + uint64_t eaddr; + + /* validate the parameters */ +- if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK || +- size == 0 || size & AMDGPU_GPU_PAGE_MASK) ++ if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || ++ size == 0 || size & ~PAGE_MASK) + return -EINVAL; + + /* make sure object fit at this offset */ +@@ -2289,8 +2289,8 @@ int amdgpu_vm_bo_replace_map(struct amdg + int r; + + /* validate the parameters */ +- if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK || +- size == 0 || size & AMDGPU_GPU_PAGE_MASK) ++ if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || ++ size == 0 || size & ~PAGE_MASK) + return -EINVAL; + + /* make sure object fit at this offset */ diff --git a/queue-5.10/drm-amdgpu-fix-offset-calculation-in-amdgpu_vm_bo_clear_mappings.patch b/queue-5.10/drm-amdgpu-fix-offset-calculation-in-amdgpu_vm_bo_clear_mappings.patch new file mode 100644 index 00000000000..64a41480bcc --- /dev/null +++ b/queue-5.10/drm-amdgpu-fix-offset-calculation-in-amdgpu_vm_bo_clear_mappings.patch @@ -0,0 +1,35 @@ +From 5e61b84f9d3ddfba73091f9fbc940caae1c9eb22 Mon Sep 17 00:00:00 2001 +From: Nirmoy Das +Date: Fri, 26 Mar 2021 16:08:10 +0100 +Subject: drm/amdgpu: fix offset calculation in amdgpu_vm_bo_clear_mappings() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Nirmoy Das + +commit 5e61b84f9d3ddfba73091f9fbc940caae1c9eb22 upstream. + +Offset calculation wasn't correct as start addresses are in pfn +not in bytes. + +CC: stable@vger.kernel.org +Signed-off-by: Nirmoy Das +Reviewed-by: Christian König +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +@@ -2435,7 +2435,7 @@ int amdgpu_vm_bo_clear_mappings(struct a + after->start = eaddr + 1; + after->last = tmp->last; + after->offset = tmp->offset; +- after->offset += after->start - tmp->start; ++ after->offset += (after->start - tmp->start) << PAGE_SHIFT; + after->flags = tmp->flags; + after->bo_va = tmp->bo_va; + list_add(&after->list, &tmp->bo_va->invalids); diff --git a/queue-5.10/drm-amdkfd-dqm-fence-memory-corruption.patch b/queue-5.10/drm-amdkfd-dqm-fence-memory-corruption.patch new file mode 100644 index 00000000000..dad7cb64d80 --- /dev/null +++ b/queue-5.10/drm-amdkfd-dqm-fence-memory-corruption.patch @@ -0,0 +1,146 @@ +From e92049ae4548ba09e53eaa9c8f6964b07ea274c9 Mon Sep 17 00:00:00 2001 +From: Qu Huang +Date: Thu, 28 Jan 2021 20:14:25 +0800 +Subject: drm/amdkfd: dqm fence memory corruption + +From: Qu Huang + +commit e92049ae4548ba09e53eaa9c8f6964b07ea274c9 upstream. + +Amdgpu driver uses 4-byte data type as DQM fence memory, +and transmits GPU address of fence memory to microcode +through query status PM4 message. However, query status +PM4 message definition and microcode processing are all +processed according to 8 bytes. Fence memory only allocates +4 bytes of memory, but microcode does write 8 bytes of memory, +so there is a memory corruption. + +Changes since v1: + * Change dqm->fence_addr as a u64 pointer to fix this issue, +also fix up query_status and amdkfd_fence_wait_timeout function +uses 64 bit fence value to make them consistent. + +Signed-off-by: Qu Huang +Reviewed-by: Felix Kuehling +Signed-off-by: Felix Kuehling +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c | 2 +- + drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 6 +++--- + drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 2 +- + drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 2 +- + drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c | 2 +- + drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c | 2 +- + drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 8 ++++---- + 7 files changed, 12 insertions(+), 12 deletions(-) + +--- a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c +@@ -155,7 +155,7 @@ static int dbgdev_diq_submit_ib(struct k + + /* Wait till CP writes sync code: */ + status = amdkfd_fence_wait_timeout( +- (unsigned int *) rm_state, ++ rm_state, + QUEUESTATE__ACTIVE, 1500); + + kfd_gtt_sa_free(dbgdev->dev, mem_obj); +--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c +@@ -1167,7 +1167,7 @@ static int start_cpsch(struct device_que + if (retval) + goto fail_allocate_vidmem; + +- dqm->fence_addr = dqm->fence_mem->cpu_ptr; ++ dqm->fence_addr = (uint64_t *)dqm->fence_mem->cpu_ptr; + dqm->fence_gpu_addr = dqm->fence_mem->gpu_addr; + + init_interrupts(dqm); +@@ -1340,8 +1340,8 @@ out: + return retval; + } + +-int amdkfd_fence_wait_timeout(unsigned int *fence_addr, +- unsigned int fence_value, ++int amdkfd_fence_wait_timeout(uint64_t *fence_addr, ++ uint64_t fence_value, + unsigned int timeout_ms) + { + unsigned long end_jiffies = msecs_to_jiffies(timeout_ms) + jiffies; +--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h +@@ -192,7 +192,7 @@ struct device_queue_manager { + uint16_t vmid_pasid[VMID_NUM]; + uint64_t pipelines_addr; + uint64_t fence_gpu_addr; +- unsigned int *fence_addr; ++ uint64_t *fence_addr; + struct kfd_mem_obj *fence_mem; + bool active_runlist; + int sched_policy; +--- a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c +@@ -345,7 +345,7 @@ fail_create_runlist_ib: + } + + int pm_send_query_status(struct packet_manager *pm, uint64_t fence_address, +- uint32_t fence_value) ++ uint64_t fence_value) + { + uint32_t *buffer, size; + int retval = 0; +--- a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c +@@ -283,7 +283,7 @@ static int pm_unmap_queues_v9(struct pac + } + + static int pm_query_status_v9(struct packet_manager *pm, uint32_t *buffer, +- uint64_t fence_address, uint32_t fence_value) ++ uint64_t fence_address, uint64_t fence_value) + { + struct pm4_mes_query_status *packet; + +--- a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_vi.c +@@ -263,7 +263,7 @@ static int pm_unmap_queues_vi(struct pac + } + + static int pm_query_status_vi(struct packet_manager *pm, uint32_t *buffer, +- uint64_t fence_address, uint32_t fence_value) ++ uint64_t fence_address, uint64_t fence_value) + { + struct pm4_mes_query_status *packet; + +--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h +@@ -1006,8 +1006,8 @@ int pqm_get_wave_state(struct process_qu + u32 *ctl_stack_used_size, + u32 *save_area_used_size); + +-int amdkfd_fence_wait_timeout(unsigned int *fence_addr, +- unsigned int fence_value, ++int amdkfd_fence_wait_timeout(uint64_t *fence_addr, ++ uint64_t fence_value, + unsigned int timeout_ms); + + /* Packet Manager */ +@@ -1043,7 +1043,7 @@ struct packet_manager_funcs { + uint32_t filter_param, bool reset, + unsigned int sdma_engine); + int (*query_status)(struct packet_manager *pm, uint32_t *buffer, +- uint64_t fence_address, uint32_t fence_value); ++ uint64_t fence_address, uint64_t fence_value); + int (*release_mem)(uint64_t gpu_addr, uint32_t *buffer); + + /* Packet sizes */ +@@ -1065,7 +1065,7 @@ int pm_send_set_resources(struct packet_ + struct scheduling_resources *res); + int pm_send_runlist(struct packet_manager *pm, struct list_head *dqm_queues); + int pm_send_query_status(struct packet_manager *pm, uint64_t fence_address, +- uint32_t fence_value); ++ uint64_t fence_value); + + int pm_send_unmap_queue(struct packet_manager *pm, enum kfd_queue_type type, + enum kfd_unmap_queues_filter mode, diff --git a/queue-5.10/mm-fix-race-by-making-init_zero_pfn-early_initcall.patch b/queue-5.10/mm-fix-race-by-making-init_zero_pfn-early_initcall.patch new file mode 100644 index 00000000000..2559601b591 --- /dev/null +++ b/queue-5.10/mm-fix-race-by-making-init_zero_pfn-early_initcall.patch @@ -0,0 +1,87 @@ +From e720e7d0e983bf05de80b231bccc39f1487f0f16 Mon Sep 17 00:00:00 2001 +From: Ilya Lipnitskiy +Date: Mon, 29 Mar 2021 21:42:08 -0700 +Subject: mm: fix race by making init_zero_pfn() early_initcall +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ilya Lipnitskiy + +commit e720e7d0e983bf05de80b231bccc39f1487f0f16 upstream. + +There are code paths that rely on zero_pfn to be fully initialized +before core_initcall. For example, wq_sysfs_init() is a core_initcall +function that eventually results in a call to kernel_execve, which +causes a page fault with a subsequent mmput. If zero_pfn is not +initialized by then it may not get cleaned up properly and result in an +error: + + BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1 + +Here is an analysis of the race as seen on a MIPS device. On this +particular MT7621 device (Ubiquiti ER-X), zero_pfn is PFN 0 until +initialized, at which point it becomes PFN 5120: + + 1. wq_sysfs_init calls into kobject_uevent_env at core_initcall: + kobject_uevent_env+0x7e4/0x7ec + kset_register+0x68/0x88 + bus_register+0xdc/0x34c + subsys_virtual_register+0x34/0x78 + wq_sysfs_init+0x1c/0x4c + do_one_initcall+0x50/0x1a8 + kernel_init_freeable+0x230/0x2c8 + kernel_init+0x10/0x100 + ret_from_kernel_thread+0x14/0x1c + + 2. kobject_uevent_env() calls call_usermodehelper_exec() which executes + kernel_execve asynchronously. + + 3. Memory allocations in kernel_execve cause a page fault, bumping the + MM reference counter: + add_mm_counter_fast+0xb4/0xc0 + handle_mm_fault+0x6e4/0xea0 + __get_user_pages.part.78+0x190/0x37c + __get_user_pages_remote+0x128/0x360 + get_arg_page+0x34/0xa0 + copy_string_kernel+0x194/0x2a4 + kernel_execve+0x11c/0x298 + call_usermodehelper_exec_async+0x114/0x194 + + 4. In case zero_pfn has not been initialized yet, zap_pte_range does + not decrement the MM_ANONPAGES RSS counter and the BUG message is + triggered shortly afterwards when __mmdrop checks the ref counters: + __mmdrop+0x98/0x1d0 + free_bprm+0x44/0x118 + kernel_execve+0x160/0x1d8 + call_usermodehelper_exec_async+0x114/0x194 + ret_from_kernel_thread+0x14/0x1c + +To avoid races such as described above, initialize init_zero_pfn at +early_initcall level. Depending on the architecture, ZERO_PAGE is +either constant or gets initialized even earlier, at paging_init, so +there is no issue with initializing zero_pfn earlier. + +Link: https://lkml.kernel.org/r/CALCv0x2YqOXEAy2Q=hafjhHCtTHVodChv1qpM=niAXOpqEbt7w@mail.gmail.com +Signed-off-by: Ilya Lipnitskiy +Cc: Hugh Dickins +Cc: "Eric W. Biederman" +Cc: stable@vger.kernel.org +Tested-by: 周琰杰 (Zhou Yanjie) +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -154,7 +154,7 @@ static int __init init_zero_pfn(void) + zero_pfn = page_to_pfn(ZERO_PAGE(0)); + return 0; + } +-core_initcall(init_zero_pfn); ++early_initcall(init_zero_pfn); + + void mm_trace_rss_stat(struct mm_struct *mm, int member, long count) + { diff --git a/queue-5.10/reiserfs-update-reiserfs_xattrs_initialized-condition.patch b/queue-5.10/reiserfs-update-reiserfs_xattrs_initialized-condition.patch new file mode 100644 index 00000000000..887ab22e38d --- /dev/null +++ b/queue-5.10/reiserfs-update-reiserfs_xattrs_initialized-condition.patch @@ -0,0 +1,52 @@ +From 5e46d1b78a03d52306f21f77a4e4a144b6d31486 Mon Sep 17 00:00:00 2001 +From: Tetsuo Handa +Date: Sun, 21 Mar 2021 23:37:49 +0900 +Subject: reiserfs: update reiserfs_xattrs_initialized() condition + +From: Tetsuo Handa + +commit 5e46d1b78a03d52306f21f77a4e4a144b6d31486 upstream. + +syzbot is reporting NULL pointer dereference at reiserfs_security_init() +[1], for commit ab17c4f02156c4f7 ("reiserfs: fixup xattr_root caching") +is assuming that REISERFS_SB(s)->xattr_root != NULL in +reiserfs_xattr_jcreate_nblocks() despite that commit made +REISERFS_SB(sb)->priv_root != NULL && REISERFS_SB(s)->xattr_root == NULL +case possible. + +I guess that commit 6cb4aff0a77cc0e6 ("reiserfs: fix oops while creating +privroot with selinux enabled") wanted to check xattr_root != NULL +before reiserfs_xattr_jcreate_nblocks(), for the changelog is talking +about the xattr root. + + The issue is that while creating the privroot during mount + reiserfs_security_init calls reiserfs_xattr_jcreate_nblocks which + dereferences the xattr root. The xattr root doesn't exist, so we get + an oops. + +Therefore, update reiserfs_xattrs_initialized() to check both the +privroot and the xattr root. + +Link: https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46cde # [1] +Reported-and-tested-by: syzbot +Signed-off-by: Tetsuo Handa +Fixes: 6cb4aff0a77c ("reiserfs: fix oops while creating privroot with selinux enabled") +Acked-by: Jeff Mahoney +Acked-by: Jan Kara +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + fs/reiserfs/xattr.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/reiserfs/xattr.h ++++ b/fs/reiserfs/xattr.h +@@ -43,7 +43,7 @@ void reiserfs_security_free(struct reise + + static inline int reiserfs_xattrs_initialized(struct super_block *sb) + { +- return REISERFS_SB(sb)->priv_root != NULL; ++ return REISERFS_SB(sb)->priv_root && REISERFS_SB(sb)->xattr_root; + } + + #define xattr_size(size) ((size) + sizeof(struct reiserfs_xattr_header)) diff --git a/queue-5.10/series b/queue-5.10/series index 210a2dc2459..90f8001f36b 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -69,3 +69,8 @@ pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch tracing-fix-stack-trace-event-size.patch s390-vdso-copy-tod_steering_delta-value-to-vdso_data-page.patch s390-vdso-fix-tod_steering_delta-type.patch +mm-fix-race-by-making-init_zero_pfn-early_initcall.patch +drm-amdkfd-dqm-fence-memory-corruption.patch +drm-amdgpu-fix-offset-calculation-in-amdgpu_vm_bo_clear_mappings.patch +drm-amdgpu-check-alignment-on-cpu-page-for-bo-map.patch +reiserfs-update-reiserfs_xattrs_initialized-condition.patch