May 2021 - Kernel - mailweb.openeuler.org

[PATCH kernel-4.19] ext4: cleanup in-core orphan list if ext4_truncate() failed to get a transaction handle
by Yang Yingliang 22 May '21

22 May '21

From: Zhang Yi <yi.zhang(a)huawei.com> hulk inclusion category: bugfix bugzilla: 51864 CVE: NA --------------------------- In ext4_orphan_cleanup(), if ext4_truncate() failed to get a transaction handle, it didn't remove the inode from the in-core orphan list, which may probably trigger below error dump in ext4_destroy_inode() during the final iput() and could lead to memory corruption on the later orphan list changes. EXT4-fs (sda): Inode 6291467 (00000000b8247c67): orphan list check failed! 00000000b8247c67: 0001f30a 00000004 00000000 00000023 ............#... 00000000e24cde71: 00000006 014082a3 00000000 00000000 ......@......... 0000000072c6a5ee: 00000000 00000000 00000000 00000000 ................ ... This patch fix this by cleanup in-core orphan list manually if ext4_truncate() return error. Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Signed-off-by: yangerkun <yangerkun(a)huawei.com> Reviewed-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/ext4/super.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 50fb70caa0e9f..fcb1f5d3b09ec 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2871,8 +2871,15 @@ static void ext4_orphan_cleanup(struct super_block *sb, inode_lock(inode); truncate_inode_pages(inode->i_mapping, inode->i_size); ret = ext4_truncate(inode); - if (ret) + if (ret) { + /* + * We need to clean up the in-core orphan list + * manually if ext4_truncate() failed to get a + * transaction handle. + */ + ext4_orphan_del(NULL, inode); ext4_std_error(inode->i_sb, ret); + } inode_unlock(inode); nr_truncates++; } else { -- 2.25.1

1 0

[PATCH kernel-4.19] mm: enhance variables check and sync for pin mem
by Yang Yingliang 22 May '21

22 May '21

From: Jingxian He <hejingxian(a)huawei.com> hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ Enhance variables check and sync for pin mem as followings: 1) Remove unused variable in set_fork_pid; 2) Remove unused calling of access_ok, which is called in copy_from_user; 3) Enhance page_map_entry_start check in pin_mem_area; 4) Keep get_page_map_info and create_page_map_info for internal use, and increase get_page_map_info_by_pid and create_page_map_info_by_pid for external use, which is protected by spinlock; 5) Use spin_lock_irqsave instead of spin_lock. Signed-off-by: Jingxian He <hejingxian(a)huawei.com> Reviewed-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/char/pin_memory.c | 7 ------ include/linux/pin_mem.h | 4 +-- mm/pin_mem.c | 51 +++++++++++++++++++++++++++++---------- 3 files changed, 40 insertions(+), 22 deletions(-) diff --git a/drivers/char/pin_memory.c b/drivers/char/pin_memory.c index 05fa7cfde03b2..4b3a6c8b31de9 100644 --- a/drivers/char/pin_memory.c +++ b/drivers/char/pin_memory.c @@ -98,8 +98,6 @@ static int set_pin_mem_area(unsigned long arg) struct pin_mem_area_set pmas; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(pmas))) - return -EFAULT; if (copy_from_user(&pmas, buf, sizeof(pmas))) return -EINVAL; if (pmas.area_num > MAX_PIN_MEM_AREA_NUM) { @@ -119,8 +117,6 @@ static int pin_mem_remap(unsigned long arg) void __user *buf = (void __user *)arg; struct pid *pid_s; - if (!access_ok(buf, sizeof(int))) - return -EINVAL; if (copy_from_user(&pid, buf, sizeof(int))) return -EINVAL; @@ -157,11 +153,8 @@ static int pin_mem_remap(unsigned long arg) static int set_fork_pid(unsigned long arg) { int pid; - struct page_map_info *pmi = NULL; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(int))) - goto fault; if (copy_from_user(&pid, buf, sizeof(int))) goto fault; current->fork_pid = pid; diff --git a/include/linux/pin_mem.h b/include/linux/pin_mem.h index 21422f8b0349c..6c54482a42a11 100644 --- a/include/linux/pin_mem.h +++ b/include/linux/pin_mem.h @@ -64,8 +64,8 @@ struct redirect_info { unsigned int redirect_index[0]; }; -extern struct page_map_info *get_page_map_info(int pid); -extern struct page_map_info *create_page_map_info(int pid); +extern struct page_map_info *get_page_map_info_by_pid(int pid); +extern struct page_map_info *create_page_map_info_by_pid(int pid); extern vm_fault_t do_mem_remap(int pid, struct mm_struct *mm); extern vm_fault_t do_anon_page_remap(struct vm_area_struct *vma, unsigned long address, pmd_t *pmd, struct page *page); diff --git a/mm/pin_mem.c b/mm/pin_mem.c index c657ae7f64860..d035934724cdc 100644 --- a/mm/pin_mem.c +++ b/mm/pin_mem.c @@ -72,7 +72,7 @@ static int __init setup_redirect_space_size(char *str) } early_param("redirect_space_size", setup_redirect_space_size); -struct page_map_info *create_page_map_info(int pid) +static struct page_map_info *create_page_map_info(int pid) { struct page_map_info *new; @@ -93,9 +93,20 @@ struct page_map_info *create_page_map_info(int pid) pin_pid_num++; return new; } -EXPORT_SYMBOL_GPL(create_page_map_info); -struct page_map_info *get_page_map_info(int pid) +struct page_map_info *create_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = create_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(create_page_map_info_by_pid); + +static struct page_map_info *get_page_map_info(int pid) { int i; @@ -108,7 +119,18 @@ struct page_map_info *get_page_map_info(int pid) } return NULL; } -EXPORT_SYMBOL_GPL(get_page_map_info); + +struct page_map_info *get_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = get_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(get_page_map_info_by_pid); static struct page *find_head_page(struct page *page) { @@ -380,12 +402,12 @@ static void reserve_user_space_map_pages(void) } } } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); return; free_pages: free_user_map_pages(index, i, j); - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } @@ -672,10 +694,11 @@ int pin_mem_area(struct task_struct *task, struct mm_struct *mm, pid = task->pid; spin_lock_irqsave(&page_map_entry_lock, flags); nr_pages = ((end_addr - start_addr) / PAGE_SIZE); - if ((unsigned long)page_map_entry_start + nr_pages * sizeof(struct page *) >= - page_map_entry_end) { + if ((unsigned long)page_map_entry_start + + nr_pages * sizeof(unsigned long) + + sizeof(struct page_map_entry) >= page_map_entry_end) { pr_warn("Page map entry use up!\n"); - ret = -EFAULT; + ret = -ENOMEM; goto finish; } @@ -965,13 +988,15 @@ vm_fault_t do_mem_remap(int pid, struct mm_struct *mm) if (reserve_user_map_pages_fail || !mm) return -EFAULT; + + spin_lock_irqsave(&page_map_entry_lock, flags); pmi = get_page_map_info(pid); + if (pmi) + pmi->disable_free_page = true; + spin_unlock_irqrestore(&page_map_entry_lock, flags); if (!pmi) return -EFAULT; - spin_lock_irqsave(&page_map_entry_lock, flags); - pmi->disable_free_page = true; - spin_unlock(&page_map_entry_lock); down_write(&mm->mmap_sem); pme = pmi->pme; vma = mm->mmap; @@ -1067,7 +1092,7 @@ void clear_pin_memory_record(void) pin_pid_num = 0; page_map_entry_start = __page_map_entry_start; } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } EXPORT_SYMBOL_GPL(clear_pin_memory_record); -- 2.25.1

1 0

[PATCH kernel-4.19 1/3] Ascend/memcg: Use CONFIG_ASCEND_FEATURES for customized interfaces
by Yang Yingliang 22 May '21

22 May '21

From: Zhou Guanghui <zhouguanghui1(a)huawei.com> ascend inclusion category: feature bugzilla: NA CVE: NA ------------------------------------------------------------- The following functions are used only in the ascend scenario: hugetlb_get_hstate, hugetlb_alloc_hugepage, hugetlb_insert_hugepage_pte, hugetlb_insert_hugepage_pte_by_pa Remove unused interface hugetlb_insert_hugepage Signed-off-by: Zhou Guanghui <zhouguanghui1(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- include/linux/hugetlb.h | 37 +++++++++++++++++++++++++++---------- mm/hugetlb.c | 37 +------------------------------------ 2 files changed, 28 insertions(+), 46 deletions(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index eefa6d42140d3..230f2eb6c4474 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -375,17 +375,31 @@ struct page *alloc_migrate_huge_page(struct hstate *h, gfp_t gfp_mask, int huge_add_to_page_cache(struct page *page, struct address_space *mapping, pgoff_t idx); -#ifdef CONFIG_ARM64 +#ifdef CONFIG_ASCEND_FEATURES const struct hstate *hugetlb_get_hstate(void); struct page *hugetlb_alloc_hugepage(int nid); int hugetlb_insert_hugepage_pte(struct mm_struct *mm, unsigned long addr, pgprot_t prot, struct page *hpage); -#endif int hugetlb_insert_hugepage_pte_by_pa(struct mm_struct *mm, unsigned long vir_addr, pgprot_t prot, unsigned long phy_addr); -int hugetlb_insert_hugepage(struct vm_area_struct *vma, unsigned long addr, - struct page *hpage, pgprot_t prot); +#else +static inline const struct hstate *hugetlb_get_hstate(void) +{ + return NULL; +} + +static inline struct page *hugetlb_alloc_hugepage(int nid) +{ + return NULL; +} + +static inline int hugetlb_insert_hugepage_pte(struct mm_struct *mm, + unsigned long addr, pgprot_t prot, struct page *hpage) +{ + return -EPERM; +} +#endif /* arch callback */ int __init __alloc_bootmem_huge_page(struct hstate *h); @@ -637,12 +651,6 @@ static inline void set_huge_swap_pte_at(struct mm_struct *mm, unsigned long addr { } -static inline int hugetlb_insert_hugepage_pte_by_pa(struct mm_struct *mm, - unsigned long vir_addr, - pgprot_t prot, unsigned long phy_addr) -{ - return 0; -} #endif /* CONFIG_HUGETLB_PAGE */ static inline spinlock_t *huge_pte_lock(struct hstate *h, @@ -655,6 +663,15 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h, return ptl; } +#ifndef CONFIG_ASCEND_FEATURES +static inline int hugetlb_insert_hugepage_pte_by_pa(struct mm_struct *mm, + unsigned long vir_addr, + pgprot_t prot, unsigned long phy_addr) +{ + return -EPERM; +} +#endif + #ifdef CONFIG_ASCEND_SHARE_POOL pte_t make_huge_pte(struct vm_area_struct *vma, struct page *page, int writable); #endif diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 019dbae493e57..5c219f848db45 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5234,7 +5234,7 @@ void move_hugetlb_state(struct page *oldpage, struct page *newpage, int reason) } } -#ifdef CONFIG_ARM64 +#ifdef CONFIG_ASCEND_FEATURES const struct hstate *hugetlb_get_hstate(void) { return &default_hstate; @@ -5335,41 +5335,6 @@ int hugetlb_insert_hugepage_pte_by_pa(struct mm_struct *mm, } EXPORT_SYMBOL_GPL(hugetlb_insert_hugepage_pte_by_pa); -int hugetlb_insert_hugepage(struct vm_area_struct *vma, unsigned long addr, - struct page *hpage, pgprot_t prot) -{ - struct hstate *h = hstate_vma(vma); - int anon_rmap = 0; - spinlock_t *ptl; - pte_t *ptep; - pte_t pte; - struct mm_struct *mm = vma->vm_mm; - - ptep = hugetlb_huge_pte_alloc(mm, addr, huge_page_size(h)); - if (!ptep) - return -ENXIO; - - get_page(hpage); - - ptl = huge_pte_lock(h, mm, ptep); - if (anon_rmap) { - ClearPagePrivate(hpage); - hugepage_add_new_anon_rmap(hpage, vma, addr); - } else { - page_dup_rmap(hpage, true); - } - - pte = make_huge_pte(vma, hpage, ((vma->vm_flags & VM_WRITE) - && (vma->vm_flags & VM_SHARED))); - set_huge_pte_at(mm, addr, ptep, pte); - - hugetlb_count_add(pages_per_huge_page(h), mm); - - spin_unlock(ptl); - - return 0; -} - #ifdef CONFIG_ASCEND_CHARGE_MIGRATE_HUGEPAGES static int __init ascend_enable_charge_migrate_hugepages(char *s) -- 2.25.1

1 2

[PATCH kernel-4.19] bluetooth: eliminate the potential race condition when removing the HCI controller
by Yang Yingliang 22 May '21

22 May '21

From: Lin Ma <linma(a)zju.edu.cn> mainline inclusion from mainline-v5.13-rc1 commit e2cb6b891ad2b8caa9131e3be70f45243df82a80 category: bugfix bugzilla: NA CVE: CVE-2021-32399 -------------------------------- There is a possible race condition vulnerability between issuing a HCI command and removing the cont. Specifically, functions hci_req_sync() and hci_dev_do_close() can race each other like below: thread-A in hci_req_sync() | thread-B in hci_dev_do_close() | hci_req_sync_lock(hdev); test_bit(HCI_UP, &hdev->flags); | ... | test_and_clear_bit(HCI_UP, &hdev->flags) hci_req_sync_lock(hdev); | | In this commit we alter the sequence in function hci_req_sync(). Hence, the thread-A cannot issue th. Signed-off-by: Lin Ma <linma(a)zju.edu.cn> Cc: Marcel Holtmann <marcel(a)holtmann.org> Fixes: 7c6a329e4447 ("[Bluetooth] Fix regression from using default link policy") Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/bluetooth/hci_request.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index a8ddd211e94c2..76bd6b1227240 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -271,12 +271,16 @@ int hci_req_sync(struct hci_dev *hdev, int (*req)(struct hci_request *req, { int ret; - if (!test_bit(HCI_UP, &hdev->flags)) - return -ENETDOWN; - /* Serialize all requests */ hci_req_sync_lock(hdev); - ret = __hci_req_sync(hdev, req, opt, timeout, hci_status); + /* check the state after obtaing the lock to protect the HCI_UP + * against any races from hci_dev_do_close when the controller + * gets removed. + */ + if (test_bit(HCI_UP, &hdev->flags)) + ret = __hci_req_sync(hdev, req, opt, timeout, hci_status); + else + ret = -ENETDOWN; hci_req_sync_unlock(hdev); return ret; -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS v2] mm: enhance variables check and sync for pin mem
by Cheng Jian 21 May '21

21 May '21

From: Jingxian He <hejingxian(a)huawei.com> hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ Enhance variables check and sync for pin mem as followings: 1) Remove unused variable in set_fork_pid; 2) Remove unused calling of access_ok, which is called in copy_from_user; 3) Enhance page_map_entry_start check in pin_mem_area; 4) Keep get_page_map_info and create_page_map_info for internal use, and increase get_page_map_info_by_pid and create_page_map_info_by_pid for external use, which is protected by spinlock; 5) Use spin_lock_irqsave instead of spin_lock. Signed-off-by: Jingxian He <hejingxian(a)huawei.com> Reviewed-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Signed-off-by: Cheng Jian <cj.chengjian(a)huawei.com> --- drivers/char/pin_memory.c | 7 ------ include/linux/pin_mem.h | 4 +-- mm/pin_mem.c | 51 +++++++++++++++++++++++++++++---------- 3 files changed, 40 insertions(+), 22 deletions(-) diff --git a/drivers/char/pin_memory.c b/drivers/char/pin_memory.c index 12ae7627bdf0..e6ed26c18135 100644 --- a/drivers/char/pin_memory.c +++ b/drivers/char/pin_memory.c @@ -98,8 +98,6 @@ static int set_pin_mem_area(unsigned long arg) struct pin_mem_area_set pmas; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(pmas))) - return -EFAULT; if (copy_from_user(&pmas, buf, sizeof(pmas))) return -EINVAL; if (pmas.area_num > MAX_PIN_MEM_AREA_NUM) { @@ -119,8 +117,6 @@ static int pin_mem_remap(unsigned long arg) void __user *buf = (void __user *)arg; struct pid *pid_s; - if (!access_ok(buf, sizeof(int))) - return -EINVAL; if (copy_from_user(&pid, buf, sizeof(int))) return -EINVAL; @@ -157,11 +153,8 @@ static int pin_mem_remap(unsigned long arg) static int set_fork_pid(unsigned long arg) { int pid; - struct page_map_info *pmi = NULL; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(int))) - goto fault; if (copy_from_user(&pid, buf, sizeof(int))) goto fault; current->fork_pid_union.fork_pid = pid; diff --git a/include/linux/pin_mem.h b/include/linux/pin_mem.h index 21422f8b0349..6c54482a42a1 100644 --- a/include/linux/pin_mem.h +++ b/include/linux/pin_mem.h @@ -64,8 +64,8 @@ struct redirect_info { unsigned int redirect_index[0]; }; -extern struct page_map_info *get_page_map_info(int pid); -extern struct page_map_info *create_page_map_info(int pid); +extern struct page_map_info *get_page_map_info_by_pid(int pid); +extern struct page_map_info *create_page_map_info_by_pid(int pid); extern vm_fault_t do_mem_remap(int pid, struct mm_struct *mm); extern vm_fault_t do_anon_page_remap(struct vm_area_struct *vma, unsigned long address, pmd_t *pmd, struct page *page); diff --git a/mm/pin_mem.c b/mm/pin_mem.c index c657ae7f6486..d035934724cd 100644 --- a/mm/pin_mem.c +++ b/mm/pin_mem.c @@ -72,7 +72,7 @@ static int __init setup_redirect_space_size(char *str) } early_param("redirect_space_size", setup_redirect_space_size); -struct page_map_info *create_page_map_info(int pid) +static struct page_map_info *create_page_map_info(int pid) { struct page_map_info *new; @@ -93,9 +93,20 @@ struct page_map_info *create_page_map_info(int pid) pin_pid_num++; return new; } -EXPORT_SYMBOL_GPL(create_page_map_info); -struct page_map_info *get_page_map_info(int pid) +struct page_map_info *create_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = create_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(create_page_map_info_by_pid); + +static struct page_map_info *get_page_map_info(int pid) { int i; @@ -108,7 +119,18 @@ struct page_map_info *get_page_map_info(int pid) } return NULL; } -EXPORT_SYMBOL_GPL(get_page_map_info); + +struct page_map_info *get_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = get_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(get_page_map_info_by_pid); static struct page *find_head_page(struct page *page) { @@ -380,12 +402,12 @@ static void reserve_user_space_map_pages(void) } } } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); return; free_pages: free_user_map_pages(index, i, j); - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } @@ -672,10 +694,11 @@ int pin_mem_area(struct task_struct *task, struct mm_struct *mm, pid = task->pid; spin_lock_irqsave(&page_map_entry_lock, flags); nr_pages = ((end_addr - start_addr) / PAGE_SIZE); - if ((unsigned long)page_map_entry_start + nr_pages * sizeof(struct page *) >= - page_map_entry_end) { + if ((unsigned long)page_map_entry_start + + nr_pages * sizeof(unsigned long) + + sizeof(struct page_map_entry) >= page_map_entry_end) { pr_warn("Page map entry use up!\n"); - ret = -EFAULT; + ret = -ENOMEM; goto finish; } @@ -965,13 +988,15 @@ vm_fault_t do_mem_remap(int pid, struct mm_struct *mm) if (reserve_user_map_pages_fail || !mm) return -EFAULT; + + spin_lock_irqsave(&page_map_entry_lock, flags); pmi = get_page_map_info(pid); + if (pmi) + pmi->disable_free_page = true; + spin_unlock_irqrestore(&page_map_entry_lock, flags); if (!pmi) return -EFAULT; - spin_lock_irqsave(&page_map_entry_lock, flags); - pmi->disable_free_page = true; - spin_unlock(&page_map_entry_lock); down_write(&mm->mmap_sem); pme = pmi->pme; vma = mm->mmap; @@ -1067,7 +1092,7 @@ void clear_pin_memory_record(void) pin_pid_num = 0; page_map_entry_start = __page_map_entry_start; } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } EXPORT_SYMBOL_GPL(clear_pin_memory_record); -- 2.25.1

1 0

[PATCH openEuler-1.0-LTS] mm: enhance variables check and sync for pin mem
by Cheng Jian 21 May '21

21 May '21

From: Jingxian He <hejingxian(a)huawei.com> hulk inclusion category: feature bugzilla: 48159 CVE: N/A ------------------------------ Enhance variables check and sync for pin mem as followings: 1) Remove unused variable in set_fork_pid; 2) Remove unused calling of access_ok, which is called in copy_from_user; 3) Enhance page_map_entry_start check in pin_mem_area; 4) Keep get_page_map_info and create_page_map_info for internal use, and increase get_page_map_info_by_pid and create_page_map_info_by_pid for external use, which is protected by spinlock; 5) Use spin_lock_irqsave instead of spin_lock. Signed-off-by: Jingxian He <hejingxian(a)huawei.com> Reviewed-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Signed-off-by: Cheng Jian <cj.chengjian(a)huawei.com> --- drivers/char/pin_memory.c | 7 ------ include/linux/pin_mem.h | 4 +-- mm/pin_mem.c | 51 +++++++++++++++++++++++++++++---------- 3 files changed, 40 insertions(+), 22 deletions(-) diff --git a/drivers/char/pin_memory.c b/drivers/char/pin_memory.c index 05fa7cfde03b..4b3a6c8b31de 100644 --- a/drivers/char/pin_memory.c +++ b/drivers/char/pin_memory.c @@ -98,8 +98,6 @@ static int set_pin_mem_area(unsigned long arg) struct pin_mem_area_set pmas; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(pmas))) - return -EFAULT; if (copy_from_user(&pmas, buf, sizeof(pmas))) return -EINVAL; if (pmas.area_num > MAX_PIN_MEM_AREA_NUM) { @@ -119,8 +117,6 @@ static int pin_mem_remap(unsigned long arg) void __user *buf = (void __user *)arg; struct pid *pid_s; - if (!access_ok(buf, sizeof(int))) - return -EINVAL; if (copy_from_user(&pid, buf, sizeof(int))) return -EINVAL; @@ -157,11 +153,8 @@ static int pin_mem_remap(unsigned long arg) static int set_fork_pid(unsigned long arg) { int pid; - struct page_map_info *pmi = NULL; void __user *buf = (void __user *)arg; - if (!access_ok(buf, sizeof(int))) - goto fault; if (copy_from_user(&pid, buf, sizeof(int))) goto fault; current->fork_pid = pid; diff --git a/include/linux/pin_mem.h b/include/linux/pin_mem.h index 21422f8b0349..6c54482a42a1 100644 --- a/include/linux/pin_mem.h +++ b/include/linux/pin_mem.h @@ -64,8 +64,8 @@ struct redirect_info { unsigned int redirect_index[0]; }; -extern struct page_map_info *get_page_map_info(int pid); -extern struct page_map_info *create_page_map_info(int pid); +extern struct page_map_info *get_page_map_info_by_pid(int pid); +extern struct page_map_info *create_page_map_info_by_pid(int pid); extern vm_fault_t do_mem_remap(int pid, struct mm_struct *mm); extern vm_fault_t do_anon_page_remap(struct vm_area_struct *vma, unsigned long address, pmd_t *pmd, struct page *page); diff --git a/mm/pin_mem.c b/mm/pin_mem.c index c657ae7f6486..d035934724cd 100644 --- a/mm/pin_mem.c +++ b/mm/pin_mem.c @@ -72,7 +72,7 @@ static int __init setup_redirect_space_size(char *str) } early_param("redirect_space_size", setup_redirect_space_size); -struct page_map_info *create_page_map_info(int pid) +static struct page_map_info *create_page_map_info(int pid) { struct page_map_info *new; @@ -93,9 +93,20 @@ struct page_map_info *create_page_map_info(int pid) pin_pid_num++; return new; } -EXPORT_SYMBOL_GPL(create_page_map_info); -struct page_map_info *get_page_map_info(int pid) +struct page_map_info *create_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = create_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(create_page_map_info_by_pid); + +static struct page_map_info *get_page_map_info(int pid) { int i; @@ -108,7 +119,18 @@ struct page_map_info *get_page_map_info(int pid) } return NULL; } -EXPORT_SYMBOL_GPL(get_page_map_info); + +struct page_map_info *get_page_map_info_by_pid(int pid) +{ + unsigned long flags; + struct page_map_info *ret; + + spin_lock_irqsave(&page_map_entry_lock, flags); + ret = get_page_map_info(pid); + spin_unlock_irqrestore(&page_map_entry_lock, flags); + return ret; +} +EXPORT_SYMBOL_GPL(get_page_map_info_by_pid); static struct page *find_head_page(struct page *page) { @@ -380,12 +402,12 @@ static void reserve_user_space_map_pages(void) } } } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); return; free_pages: free_user_map_pages(index, i, j); - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } @@ -672,10 +694,11 @@ int pin_mem_area(struct task_struct *task, struct mm_struct *mm, pid = task->pid; spin_lock_irqsave(&page_map_entry_lock, flags); nr_pages = ((end_addr - start_addr) / PAGE_SIZE); - if ((unsigned long)page_map_entry_start + nr_pages * sizeof(struct page *) >= - page_map_entry_end) { + if ((unsigned long)page_map_entry_start + + nr_pages * sizeof(unsigned long) + + sizeof(struct page_map_entry) >= page_map_entry_end) { pr_warn("Page map entry use up!\n"); - ret = -EFAULT; + ret = -ENOMEM; goto finish; } @@ -965,13 +988,15 @@ vm_fault_t do_mem_remap(int pid, struct mm_struct *mm) if (reserve_user_map_pages_fail || !mm) return -EFAULT; + + spin_lock_irqsave(&page_map_entry_lock, flags); pmi = get_page_map_info(pid); + if (pmi) + pmi->disable_free_page = true; + spin_unlock_irqrestore(&page_map_entry_lock, flags); if (!pmi) return -EFAULT; - spin_lock_irqsave(&page_map_entry_lock, flags); - pmi->disable_free_page = true; - spin_unlock(&page_map_entry_lock); down_write(&mm->mmap_sem); pme = pmi->pme; vma = mm->mmap; @@ -1067,7 +1092,7 @@ void clear_pin_memory_record(void) pin_pid_num = 0; page_map_entry_start = __page_map_entry_start; } - spin_unlock(&page_map_entry_lock); + spin_unlock_irqrestore(&page_map_entry_lock, flags); } EXPORT_SYMBOL_GPL(clear_pin_memory_record); -- 2.25.1

1 0

Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请
by Xie XiuQi 19 May '21

19 May '21

Hi, On 2021/3/25 9:43, zhenpengzheng(a)net-swift.com wrote: > > to Leizhen, > > have these two patches been merged into kernel-4.19 and openEuler-1.0-LTS branches? This patch is in my queue and under testing, which would be merged before April 15. Thanks. > > regards, > zhenpeng > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > **************************************************************** > > 郑振鹏(zheng zhenpeng) > > 北京网迅科技有限公司杭州分公司软件工程师 > > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > > Beijing WangXun Technology Co., Ltd. Software Engineer. > > Room A507, HuaXing Times Square, No.478 West Wensan Road. > > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > > > > Office: +86(0571)89807901-8014 > > Mobile: +86-13656681762 > > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > > **************************************************************** > > > *发件人：* Xie XiuQi <mailto:xiexiuqi@huawei.com> > *发送时间：* 2021-03-12 16:22 > *收件人：* zhenpengzheng(a)net-swift.com <mailto:zhenpengzheng@net-swift.com>; Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > *抄送：* liuyuan36 <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com>; kernel(a)openeuler.org <mailto:kernel@openeuler.org> > *主题：* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > For this series, > Acked-by: Xie XiuQi <xiexiuqi(a)huawei.com> > > @Leizhen, > > Please help to apply this two patches to kernel-4.19 & openEuler-1.0-LTS branches. > Thanks. > > On 2021/3/9 19:13, zhenpengzheng(a)net-swift.com wrote: > > to谢工， > > 已清理所有提交文件中“huawei” “intel” “HiNIC”等字样与本次提交无关的注释。 > > > > toLei工， > > 已删除所有提交文件末尾空行。 > > > > 谢谢大家的意见，附件为改动后最新的patch。 > > > > 振鹏 > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > **************************************************************** > > > > 郑振鹏(zheng zhenpeng) > > > > 北京网迅科技有限公司杭州分公司软件工程师 > > > > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > > > > Beijing WangXun Technology Co., Ltd. Software Engineer. > > > > Room A507, HuaXing Times Square, No.478 West Wensan Road. > > > > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > > > > > > > > Office: +86(0571)89807901-8014 > > > > Mobile: +86-13656681762 > > > > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > > > > **************************************************************** > > > > > > *发件人：* Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > > *发送时间：* 2021-03-09 17:59 > > *收件人：* zhenpengzheng(a)net-swift.com <mailto:zhenpengzheng@net-swift.com>; Xie XiuQi <mailto:xiexiuqi@huawei.com> > > *抄送：* liuyuan36 <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com> > > *主题：* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > > > > > > On 2021/3/9 16:38, zhenpengzheng(a)net-swift.com wrote: > > > 谢工，lei工 > > > 您好，附件是我按照社区要求整改的patch，第一份较大的patch是不包含openeuler_config(x86)文件修改的驱动主代码，第二份patch仅含openeuler_config(x86)文件修改，arm的配置暂未修改，后续我尽快测完再发patch开启arm配置。 > > > > > > 针对社区反馈的问题1，我查过patch中确实存在一处告警所说明的违规（即指向patch90行那处），其余违规处对照后未发现异常，我检查过代码本身应无段尾出现空白的情况，不知道如何进一步确认patch是否合规，请在邮件中告知，谢谢。 > > drivers/net/ethernet/netswift/txgbe/txgbe_bp.h > > drivers/net/ethernet/netswift/txgbe/txgbe_ethtool.c > > drivers/net/ethernet/netswift/txgbe/txgbe_hw.c > > drivers/net/ethernet/netswift/txgbe/txgbe_lib.c > > drivers/net/ethernet/netswift/txgbe/txgbe_main.c > > drivers/net/ethernet/netswift/txgbe/txgbe_mtd.c > > drivers/net/ethernet/netswift/txgbe/txgbe_mtd.h > > > > 这个告警是文件末尾有空行。每个文件打开一下，shift+G到末尾check下就好了。 > > > > > > > > 振鹏 > > > > > > > > > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > > **************************************************************** > > > > > > 郑振鹏(zheng zhenpeng) > > > > > > 北京网迅科技有限公司杭州分公司软件工程师 > > > > > > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > > > > > > Beijing WangXun Technology Co., Ltd. Software Engineer. > > > > > > Room A507, HuaXing Times Square, No.478 West Wensan Road. > > > > > > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > > > > > > > > > > > > Office: +86(0571)89807901-8014 > > > > > > Mobile: +86-13656681762 > > > > > > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > > > > > > **************************************************************** > > > > > > > > > *发件人：* Xie XiuQi <mailto:xiexiuqi@huawei.com> > > > *发送时间：* 2021-03-08 16:29 > > > *收件人：* zhenpengzheng(a)net-swift.com <mailto:zhenpengzheng@net-swift.com>; Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > > > *抄送：* liuyuan36 <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com> > > > *主题：* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > > > Hi， > > > > > > On 2021/3/8 11:12, zhenpengzheng(a)net-swift.com wrote: > > > > 适用arm64，但这份驱动我只在x86指令集的机器上测试过，我先改好，稍后安排ARM的适配测试。 > > > > > > 好的，在 x86 上测试过，就先在 x86 上 enable 吧。 > > > ARM64 的测试过之后，可以再 enable。 > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > > > > **************************************************************** > > > > > > > > 郑振鹏(zheng zhenpeng) > > > > > > > > 北京网迅科技有限公司杭州分公司软件工程师 > > > > > > > > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > > > > > > > > Beijing WangXun Technology Co., Ltd. Software Engineer. > > > > > > > > Room A507, HuaXing Times Square, No.478 West Wensan Road. > > > > > > > > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > > > > > > > > > > > > > > > > Office: +86(0571)89807901-8014 > > > > > > > > Mobile: +86-13656681762 > > > > > > > > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > > > > > > > > **************************************************************** > > > > > > > > > > > > *发件人：* Xie XiuQi <mailto:xiexiuqi@huawei.com> > > > > *发送时间：* 2021-03-08 10:30 > > > > *收件人：* zhenpengzheng(a)net-swift.com <mailto:zhenpengzheng@net-swift.com>; Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > > > > *抄送：* liuyuan36 <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com> > > > > *主题：* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > > > > Hi, > > > > > > > > 网讯网卡驱动在 arm64 上也是适用的吧？ > > > > 是的话，arm64 的config，也打开吧。 > > > > > > > > arch/arm64/configs/openeuler_defconfig > > > > > > > > > > > > > > > > On 2021/3/8 9:42, zhenpengzheng(a)net-swift.com wrote: > > > > > 好的，对于问题2，我分割成两个patch再发一次，谢谢。 > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > > > > > > **************************************************************** > > > > > > > > > > 郑振鹏(zheng zhenpeng) > > > > > > > > > > 北京网迅科技有限公司杭州分公司软件工程师 > > > > > > > > > > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > > > > > > > > > > Beijing WangXun Technology Co., Ltd. Software Engineer. > > > > > > > > > > Room A507, HuaXing Times Square, No.478 West Wensan Road. > > > > > > > > > > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > > > > > > > > > > > > > > > > > > > > Office: +86(0571)89807901-8014 > > > > > > > > > > Mobile: +86-13656681762 > > > > > > > > > > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > > > > > > > > > > **************************************************************** > > > > > > > > > > > > > > > *发件人：* Leizhen (ThunderTown) <mailto:thunder.leizhen@huawei.com> > > > > > *发送时间：* 2021-03-06 15:05 > > > > > *收件人：* Xie XiuQi <mailto:xiexiuqi@huawei.com>; 郑振鹏 <mailto:zhenpengzheng@net-swift.com> > > > > > *抄送：* Liuyuan (Compatibility, Cloud Infrastructure Service Product Dept.) <mailto:liuyuan36@huawei.com>; Cheng Jian <mailto:cj.chengjian@huawei.com>; Libin (Huawei) <mailto:huawei.libin@huawei.com>; Yang Yingliang <mailto:yangyingliang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <mailto:dukaitian@huawei.com>; neil.yao(a)huawei.com <mailto:neil.yao@huawei.com> > > > > > *主题：* Re: Fwd: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > > > > > Hi 振鹏， > > > > > 我review了一下补丁，有几个地方需要改进下： > > > > > > > > > > 1. git am补丁的时候会报几个warning，需要消除一下； > > > > > git am 0001-add-WangXun-XGIG-NIC-driver-for-EulerOS.patch > > > > > Applying: add WangXun XGIG NIC driver for EulerOS > > > > > .git/rebase-apply/patch:90: new blank line at EOF. > > > > > + > > > > > .git/rebase-apply/patch:2331: new blank line at EOF. > > > > > + > > > > > .git/rebase-apply/patch:5755: new blank line at EOF. > > > > > + > > > > > .git/rebase-apply/patch:12891: new blank line at EOF. > > > > > + > > > > > .git/rebase-apply/patch:14134: new blank line at EOF. > > > > > + > > > > > warning: squelched 3 whitespace errors > > > > > warning: 8 lines add whitespace errors. > > > > > 2. 对arch/x86/configs/openeuler_defconfig文件的修改，最好能拆分到一个独立的补丁中去。 > > > > > 3. txgbe_bp.c没有添加版权声明。 > > > > > 4. 其它#if 0、//注释掉的代码，最好能清掉。 > > > > > > > > > > > > > > > > > > > > On 2021/3/1 16:32, Xie XiuQi wrote: > > > > > > Hi 振鹏， > > > > > > > > > > > > Thanks for your patch, we'll review this patch, and give a feedback soon. > > > > > > > > > > > > --- > > > > > > Thanks, > > > > > > Xie XiuQi > > > > > > > > > > > > > > > > > > -------- Forwarded Message -------- > > > > > > Subject: 网迅万兆网卡驱动合入openeuler-4.19内核申请 > > > > > > Date: Mon, 1 Mar 2021 15:41:09 +0800 > > > > > > From: zhenpengzheng(a)net-swift.com <zhenpengzheng(a)net-swift.com> > > > > > > To: xiexiuqi <xiexiuqi(a)huawei.com>, liuyuan36 <liuyuan36(a)huawei.com> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 谢工，刘工： > > > > > > > > > > > > 您好，我已准备好patch，见附件，patch已按照社区要求做checkpatch，报告的错误已消除，commit信息已更新。 > > > > > > > > > > > > 振鹏 > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > > > > > > > > **************************************************************** > > > > > > > > > > > > 郑振鹏(zheng zhenpeng) > > > > > > > > > > > > 北京网迅科技有限公司杭州分公司软件工程师 > > > > > > > > > > > > 浙江省杭州市西湖区文三路478号华星时代广场A座507室 310013 > > > > > > > > > > > > Beijing WangXun Technology Co., Ltd. Software Engineer. > > > > > > > > > > > > Room A507, HuaXing Times Square, No.478 West Wensan Road. > > > > > > > > > > > > West Lake District, Hangzhou City, 310013 ZHEJIANG, P.R.CHINA. > > > > > > > > > > > > > > > > > > > > > > > > Office: +86(0571)89807901-8014 > > > > > > > > > > > > Mobile: +86-13656681762 > > > > > > > > > > > > E-Mail: z <mailto:jianwang@trustnetic.com>henpengzheng(a)net-swift.com > > > > > > > > > > > > **************************************************************** > > > > > > > > > > > > > > > > > > > > >

1 1

[PATCH kernel-4.19 0/6] Perf: backport JVMTI plugin from mainline 5.7
by Zhichang Yuan 18 May '21

18 May '21

This series is a set of backports to enhance the JVMTI plugin support in Linux perf tool. It allows one to use perf to profile Java applications and attain clearer symbols output. Nick Gasson (6): perf jvmti: Fix jitdump for methods without debug info perf jvmti: Do not report error when missing debug information perf tests: Add test for the java demangler perf jvmti: Fix demangling Java symbols perf jvmti: Remove redundant jitdump line table entries perf jit: Fix inaccurate DWARF line table tools/perf/jvmti/libjvmti.c | 92 ++++++++++++--------------- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++ tools/perf/tests/demangle-java-test.c | 42 ++++++++++++ tools/perf/tests/tests.h | 1 + tools/perf/util/demangle-java.c | 13 ++-- tools/perf/util/genelf_debug.c | 4 +- 7 files changed, 96 insertions(+), 61 deletions(-) create mode 100644 tools/perf/tests/demangle-java-test.c -- 2.23.0

1 6

[PATCH openEuler-1.0-LTS 1/2] bpf: Fix masking negation logic upon negative dst register
by Yang Yingliang 18 May '21

18 May '21

From: Daniel Borkmann <daniel(a)iogearbox.net> stable inclusion from linux-4.19.190 commit 0e2dfdc74a7f4036127356d42ea59388f153f42c -------------------------------- commit b9b34ddbe2076ade359cd5ce7537d5ed019e9807 upstream. The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it's not an immediate based operation. Fixes: 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Tested-by: Piotr Krysiuk <piotras(a)gmail.com> Reviewed-by: Piotr Krysiuk <piotras(a)gmail.com> Reviewed-by: John Fastabend <john.fastabend(a)gmail.com> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/bpf/verifier.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index c1df2803033d3..79b50911008a0 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -6373,14 +6373,10 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) *patch++ = BPF_ALU64_REG(BPF_OR, BPF_REG_AX, off_reg); *patch++ = BPF_ALU64_IMM(BPF_NEG, BPF_REG_AX, 0); *patch++ = BPF_ALU64_IMM(BPF_ARSH, BPF_REG_AX, 63); - if (issrc) { - *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, - off_reg); - insn->src_reg = BPF_REG_AX; - } else { - *patch++ = BPF_ALU64_REG(BPF_AND, off_reg, - BPF_REG_AX); - } + *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, off_reg); + if (!issrc) + *patch++ = BPF_MOV64_REG(insn->dst_reg, insn->src_reg); + insn->src_reg = BPF_REG_AX; if (isneg) insn->code = insn->code == code_add ? code_sub : code_add; -- 2.25.1

1 1

[PATCH kernel-4.19] bpf: Fix leakage of uninitialized bpf stack under speculation
by Yang Yingliang 18 May '21

18 May '21

From: Daniel Borkmann <daniel(a)iogearbox.net> mainline inclusion from mainline-v5.13-rc1 commit 801c6058d14a82179a7ee17a4b532cac6fad067f category: bugfix bugzilla: NA CVE: CVE-2021-31829 -------------------------------- The current implemented mechanisms to mitigate data disclosure under speculation mainly address stack and map value oob access from the speculative domain. However, Piotr discovered that uninitialized BPF stack is not protected yet, and thus old data from the kernel stack, potentially including addresses of kernel structures, could still be extracted from that 512 bytes large window. The BPF stack is special compared to map values since it's not zero initialized for every program invocation, whereas map values /are/ zero initialized upon their initial allocation and thus cannot leak any prior data in either domain. In the non-speculative domain, the verifier ensures that every stack slot read must have a prior stack slot write by the BPF program to avoid such data leaking issue. However, this is not enough: for example, when the pointer arithmetic operation moves the stack pointer from the last valid stack offset to the first valid offset, the sanitation logic allows for any intermediate offsets during speculative execution, which could then be used to extract any restricted stack content via side-channel. Given for unprivileged stack pointer arithmetic the use of unknown but bounded scalars is generally forbidden, we can simply turn the register-based arithmetic operation into an immediate-based arithmetic operation without the need for masking. This also gives the benefit of reducing the needed instructions for the operation. Given after the work in 7fedb63a8307 ("bpf: Tighten speculative pointer arithmetic mask"), the aux->alu_limit already holds the final immediate value for the offset register with the known scalar. Thus, a simple mov of the immediate to AX register with using AX as the source for the original instruction is sufficient and possible now in this case. Reported-by: Piotr Krysiuk <piotras(a)gmail.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Tested-by: Piotr Krysiuk <piotras(a)gmail.com> Reviewed-by: Piotr Krysiuk <piotras(a)gmail.com> Reviewed-by: John Fastabend <john.fastabend(a)gmail.com> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Conflicts: kernel/bpf/verifier.c Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Reviewed-by: Kuohai Xu <xukuohai(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- include/linux/bpf_verifier.h | 5 +++-- kernel/bpf/verifier.c | 27 +++++++++++++++++---------- 2 files changed, 20 insertions(+), 12 deletions(-) diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h index 42dc8c2146f4d..daab0960c0544 100644 --- a/include/linux/bpf_verifier.h +++ b/include/linux/bpf_verifier.h @@ -142,10 +142,11 @@ struct bpf_verifier_state_list { }; /* Possible states for alu_state member. */ -#define BPF_ALU_SANITIZE_SRC 1U -#define BPF_ALU_SANITIZE_DST 2U +#define BPF_ALU_SANITIZE_SRC (1U << 0) +#define BPF_ALU_SANITIZE_DST (1U << 1) #define BPF_ALU_NEG_VALUE (1U << 2) #define BPF_ALU_NON_POINTER (1U << 3) +#define BPF_ALU_IMMEDIATE (1U << 4) #define BPF_ALU_SANITIZE (BPF_ALU_SANITIZE_SRC | \ BPF_ALU_SANITIZE_DST) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 46e21bdb79c4c..c49aa17839875 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2745,6 +2745,7 @@ static int sanitize_ptr_alu(struct bpf_verifier_env *env, { struct bpf_insn_aux_data *aux = commit_window ? cur_aux(env) : tmp_aux; struct bpf_verifier_state *vstate = env->cur_state; + bool off_is_imm = tnum_is_const(off_reg->var_off); bool off_is_neg = off_reg->smin_value < 0; bool ptr_is_dst_reg = ptr_reg == dst_reg; u8 opcode = BPF_OP(insn->code); @@ -2775,6 +2776,7 @@ static int sanitize_ptr_alu(struct bpf_verifier_env *env, alu_limit = abs(tmp_aux->alu_limit - alu_limit); } else { alu_state = off_is_neg ? BPF_ALU_NEG_VALUE : 0; + alu_state |= off_is_imm ? BPF_ALU_IMMEDIATE : 0; alu_state |= ptr_is_dst_reg ? BPF_ALU_SANITIZE_SRC : BPF_ALU_SANITIZE_DST; } @@ -6301,7 +6303,7 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) const u8 code_sub = BPF_ALU64 | BPF_SUB | BPF_X; struct bpf_insn insn_buf[16]; struct bpf_insn *patch = &insn_buf[0]; - bool issrc, isneg; + bool issrc, isneg, isimm; u32 off_reg; aux = &env->insn_aux_data[i + delta]; @@ -6312,16 +6314,21 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) isneg = aux->alu_state & BPF_ALU_NEG_VALUE; issrc = (aux->alu_state & BPF_ALU_SANITIZE) == BPF_ALU_SANITIZE_SRC; + isimm = aux->alu_state & BPF_ALU_IMMEDIATE; off_reg = issrc ? insn->src_reg : insn->dst_reg; - if (isneg) - *patch++ = BPF_ALU64_IMM(BPF_MUL, off_reg, -1); - *patch++ = BPF_MOV32_IMM(BPF_REG_AX, aux->alu_limit); - *patch++ = BPF_ALU64_REG(BPF_SUB, BPF_REG_AX, off_reg); - *patch++ = BPF_ALU64_REG(BPF_OR, BPF_REG_AX, off_reg); - *patch++ = BPF_ALU64_IMM(BPF_NEG, BPF_REG_AX, 0); - *patch++ = BPF_ALU64_IMM(BPF_ARSH, BPF_REG_AX, 63); - *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, off_reg); + if (isimm) { + *patch++ = BPF_MOV32_IMM(BPF_REG_AX, aux->alu_limit); + } else { + if (isneg) + *patch++ = BPF_ALU64_IMM(BPF_MUL, off_reg, -1); + *patch++ = BPF_MOV32_IMM(BPF_REG_AX, aux->alu_limit); + *patch++ = BPF_ALU64_REG(BPF_SUB, BPF_REG_AX, off_reg); + *patch++ = BPF_ALU64_REG(BPF_OR, BPF_REG_AX, off_reg); + *patch++ = BPF_ALU64_IMM(BPF_NEG, BPF_REG_AX, 0); + *patch++ = BPF_ALU64_IMM(BPF_ARSH, BPF_REG_AX, 63); + *patch++ = BPF_ALU64_REG(BPF_AND, BPF_REG_AX, off_reg); + } if (!issrc) *patch++ = BPF_MOV64_REG(insn->dst_reg, insn->src_reg); insn->src_reg = BPF_REG_AX; @@ -6329,7 +6336,7 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) insn->code = insn->code == code_add ? code_sub : code_add; *patch++ = *insn; - if (issrc && isneg) + if (issrc && isneg && !isimm) *patch++ = BPF_ALU64_IMM(BPF_MUL, off_reg, -1); cnt = patch - insn_buf; -- 2.25.1

1 0

2024

2023

2022

2021

2020

2019

Kernel May 2021