- 27 3月, 2022 1 次提交
-
-
由 Yun Xu 提交于
Ramaxel inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4ZR0O CVE: NA ------------------------------------ There are some issues of the driver that cannot be fixed now. The driver is not good enough for the LTS quality requirements of openEuler,so remove it. Signed-off-by: NYun Xu <xuyun@ramaxel.com> Signed-off-by: NYanling Song <songyl@ramaxel.com> Reviewed-by: NYun Xu <xuyun@ramaxel.com> Acked-by: NXie Xiuqi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 23 3月, 2022 2 次提交
-
-
由 Haimin Zhang 提交于
mainline inclusion from mainline-v5.17-rc5 commit cc8f7fe1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4Z2IA CVE: CVE-2022-0494 -------------------------------- Add __GFP_ZERO flag for alloc_page in function bio_copy_kern to initialize the buffer of a bio. Signed-off-by: NHaimin Zhang <tcs.kernel@gmail.com> Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220216084038.15635-1-tcs.kernel@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk> Conflict: commit ce288e05 ("block: remove BLK_BOUNCE_ISA support") is not backported. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Eric Dumazet 提交于
mainline inclusion from mainline-v5.16-rc1 commit 59f09ae8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4Z2Z9 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=59f09ae8fac4a990070fc6bdc889d0e0118664ea ------------------------------- This trivial function is called ~90,000 times on 256 cpus hosts, when reading /proc/net/netstat. And this number keeps inflating. Inlining it saves many cycles. Signed-off-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NCao Wangbao <caowangbao@huawei.com> Reviewed-by: NWu Changye <wuchangye@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 22 3月, 2022 4 次提交
-
-
由 Steffen Klassert 提交于
mainline inclusion from mainline commit ebe48d36 category: bugfix bugzilla: 186409, https://gitee.com/openeuler/kernel/issues/I4YXSX CVE: CVE-2022-0886 -------------------------------- The maximum message size that can be send is bigger than the maximum site that skb_page_frag_refill can allocate. So it is possible to write beyond the allocated buffer. Fix this by doing a fallback to COW in that case. v2: Avoid get get_order() costs as suggested by Linus Torvalds. Fixes: cac2661c ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f ("esp6: Avoid skb_cow_data whenever possible") Reported-by: Nvalis <sec@valis.email> Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NXu Jia <xujia39@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yunsheng Lin 提交于
mainline inclusion from mainline-v5.15-rc1 commit 723783d0 category: bugfix bugzilla: 186409, https://gitee.com/openeuler/kernel/issues/I4YXSX CVE: CVE-2022-0886 -------------------------------- Both SKB_FRAG_PAGE_ORDER are defined to the same value in net/core/sock.c and drivers/vhost/net.c. Move the SKB_FRAG_PAGE_ORDER definition to net/core/sock.h, as both net/core/sock.c and drivers/vhost/net.c include it, and it seems a reasonable file to put the macro. Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com> Acked-by: NJason Wang <jasowang@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NXu Jia <xujia39@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 eillon 提交于
euleros inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4YW86 -------------------------------- When building with defconfig on arm32, we got a compile error: ./include/linux/page-flags-layout.h:95:2: error: #error "Not enough bits in page flags" 95 | #error "Not enough bits in page flags" | ^~~~~ Limit PG_reserve_pgflag_0 and PG_reserve_pgflag_1 to compile only on X86_64 and ARM64 to resolve this issue. Fixes: afdf2a6c ("kabi: Add reserved page and gfp flags for future extension") Signed-off-by: Neillon <yezhenyu2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904, https://gitee.com/openeuler/kernel/issues/I4YXOA -------------------------------- When building with defconfig on arm32, we got a compile error: ./include/linux/page-flags-layout.h:95:2: error: #error "Not enough bits in page flags" 95 | #error "Not enough bits in page flags" | ^~~~~ Limit PG_pool to compile only on X86_64 and ARM64 to resolve this issue. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 21 3月, 2022 6 次提交
-
-
由 Zhang Wensheng 提交于
mainline inclusion from mainline-v5.17-rc8 commit 0c4bcfde category: bugfix bugzilla: 186448, https://gitee.com/openeuler/kernel/issues/I4YS7O CVE: CVE-2022-1011 -------------------------------- Because create a new user_pages in fuse_args, to fix kabi change. Signed-off-by: Zhang Wensheng zhangwensheng5@huawei.com Reviewed-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Miklos Szeredi 提交于
mainline inclusion from mainline-v5.17-rc8 commit 0c4bcfde category: bugfix bugzilla: 186448, https://gitee.com/openeuler/kernel/issues/I4YS7O CVE: CVE-2022-1011 -------------------------------- In FOPEN_DIRECT_IO mode, fuse_file_write_iter() calls fuse_direct_write_iter(), which normally calls fuse_direct_io(), which then imports the write buffer with fuse_get_user_pages(), which uses iov_iter_get_pages() to grab references to userspace pages instead of actually copying memory. On the filesystem device side, these pages can then either be read to userspace (via fuse_dev_read()), or splice()d over into a pipe using fuse_dev_splice_read() as pipe buffers with &nosteal_pipe_buf_ops. This is wrong because after fuse_dev_do_read() unlocks the FUSE request, the userspace filesystem can mark the request as completed, causing write() to return. At that point, the userspace filesystem should no longer have access to the pipe buffer. Fix by copying pages coming from the user address space to new pipe buffers. Reported-by: NJann Horn <jannh@google.com> Fixes: c3021629 ("fuse: support splice() reading from fuse device") Cc: <stable@vger.kernel.org> Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com> Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jamie Hill-Daniel 提交于
mainline inclusion from mainline-v5.17-rc1 commit 722d9484 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4YD3S CVE: CVE-2022-0185 -------------------------------- The "PAGE_SIZE - 2 - size" calculation in legacy_parse_param() is an unsigned type so a large value of "size" results in a high positive value instead of a negative value as expected. Fix this by getting rid of the subtraction. Signed-off-by: NJamie Hill-Daniel <jamie@hill-daniel.co.uk> Signed-off-by: NWilliam Liu <willsroot@protonmail.com> Tested-by: NSalvatore Bonaccorso <carnil@debian.org> Tested-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Trond Myklebust 提交于
mainline inclusion from mainline-v5.17-rc5 commit e0caaf75 category: bugfix bugzilla: 186205 https://gitee.com/openeuler/kernel/issues/I4YQRW CVE: CVE-2022-24448 -------------------------------- Commit ac795161 (NFSv4: Handle case where the lookup of a directory fails) [1], part of Linux since 5.17-rc2, introduced a regression, where a symbolic link on an NFS mount to a directory on another NFS does not resolve(?) the first time it is accessed: Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de> Fixes: ac795161 ("NFSv4: Handle case where the lookup of a directory fails") Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Tested-by: NDonald Buczek <buczek@molgen.mpg.de> Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: NChenXiaoSong <chenxiaosong2@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: 186389, https://gitee.com/openeuler/kernel/issues/I4Y43S CVE: NA -------------------------------- blk_mq_realloc_hw_ctxs() will free the 'queue_hw_ctx'(e.g. undate submit_queues through configfs for null_blk), while it might still be used from other context(e.g. switch elevator to none): t1 t2 elevator_switch blk_mq_unquiesce_queue blk_mq_run_hw_queues queue_for_each_hw_ctx // assembly code for hctx = (q)->queue_hw_ctx[i] mov 0x48(%rbp),%rdx -> read old queue_hw_ctx __blk_mq_update_nr_hw_queues blk_mq_realloc_hw_ctxs hctxs = q->queue_hw_ctx q->queue_hw_ctx = new_hctxs kfree(hctxs) movslq %ebx,%rax mov (%rdx,%rax,8),%rdi ->uaf Sicne the queue is freezed in __blk_mq_update_nr_hw_queues(), fix the problem by protecting 'queue_hw_ctx' through rcu where it can be accessed without grabbing 'q_usage_counter'. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NMing Lei <ming.lei@redhat.com> Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Laibin Qiu 提交于
hulk inclusion category: bugfix bugzilla: 186352, https://gitee.com/openeuler/kernel/issues/I4YADX CVE: NA -------------------------------- In case of BLK_MQ_F_BLOCKING, per-hctx srcu is used to protect dispatch critical area. But the current process is not aware when memory of srcu allocation failed in blk_mq_alloc_hctx, which will leads to illegal address BUG. Add return value validation to avoid this problem. Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 20 3月, 2022 9 次提交
-
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- Patch ("hugetlb: address ref count racing in prep_compound_gigantic_page") add a check of ref count in prep_compound_gigantic_page. We will call this function in dynamic hugetlb feature too, so we should initialize subpages before calling prep_compound_gigantic_page to satisfy the change. Further, the input of prep_compound_gigantic_page should be a group of pages rather than compound page, so clear the properties related to compound page. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- Patch ("mm: hugetlb: fix a race between freeing and dissolving the page") add PageHugeFreed to check whether a page is freed in hugetlb. Patch ("hugetlb: convert PageHugeFreed to HPageFreed flag") convert it to HPageFreed. We need to clear it when alloc hugepage from hugetlb to and set it when free hugepage back to hugetlb. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- We do not support dynamic combination of 1G hugepages dynamicly as this can result in a significant performance loss. We suggest to configure the number of hugepages immediately after creating a dynamic hugetlb pool rather than modify them dynamicly while some processes are runing. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- Do not release the lock after merging all pages, otherwise some other process may allocate the pages, and then some pages can't be put back to hugetlb. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- When all processes in the memory cgroup are finished, some memory may still be occupied such as file cache. Use mem_cgroup_force_empty to reclaim these pages that charged in the memory cgroup before merging all pages. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- Use check_new_page to check the page to be allocated. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- For 1G huge pages, the struct page of each subpages may be discontinuous, but pfn must be continuous, so it's better to traverse subpages using pfn rathan than struct page. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- Referring to alloc_buddy_huge_page function, replace prep_compound_page with prep_new_page which is more appropriate because it's the opposite of free_pages_prepare. And initialize page->mapping for huge pages as they are initialized in free_huge_page too. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: 46904 https://gitee.com/openeuler/kernel/issues/I4Y0XO -------------------------------- The hugepages may still remain PG_uptodate flags when freed. When splitting hugepage to pages, the flag is not clear. This causes the page to be allocated with PG_uptodate flags and user may read incorrect datas. In order to solve this problem and similar problems, add free_pages_prepares() to clear page when splitting pages to small pool. Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 17 3月, 2022 4 次提交
-
-
由 Mao HongBo 提交于
Phytium inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I41AUQ CVE: NA ------------------------------------------------- Fix the issue that interrupts are concentrated in one cpu for Phytium S2500 server. Signed-off-by: NMao HongBo <maohongbo@phytium.com.cn> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ding Hui 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I3BNT6 CVE: NA ----------------------------------------------- We can get a crash when disconnecting the iSCSI session, the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98 In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, but not saved in edev->component[i].scratch In this situation, edev->component[0].scratch is an invalid pointer, when kfree it in ses_intf_remove_enclosure, a crash like above would happen The call trace also could be other random cases when kfree cannot catch the invalid pointer We should not use edev->component[] array when the components count is 0 We also need check index when use edev->component[] array in ses_enclosure_data_process Another fix option is report error and do not attach in ses_intf_add if we meet a zero component enclosure Tested-by: NZeng Zhicong <timmyzeng@163.com> Signed-off-by: NDing Hui <dinghui@sangfor.com.cn> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chengguang Xu 提交于
mainline inclusion from mainline-v5.11-rc1 commit c11faf32 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4Y3CE?from=project-issue CVE: NA -------------------------------- In metacopy case, we should use ovl_inode_realdata() instead of ovl_inode_real() to get real inode which has data, so that we can get correct information of extentes in ->fiemap operation. Signed-off-by: NChengguang Xu <cgxu519@mykernel.net> Reviewed-by: NAmir Goldstein <amir73il@gmail.com> Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com> Signed-off-by: NZheng Liang <zhengliang6@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Arnaldo Carvalho de Melo 提交于
mainline inclusion from mainline-v5.14-rc2 commit d08c84e0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4Y3D0 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d08c84e01afa7a7eee6badab25d5420fa847f783 ---------------------------- In fedora rawhide the PTHREAD_STACK_MIN define may end up expanded to a sysconf() call, and that will return 'long int', breaking the build: 45 fedora:rawhide : FAIL gcc version 11.1.1 20210623 (Red Hat 11.1.1-6) (GCC) builtin-sched.c: In function 'create_tasks': /git/perf-5.14.0-rc1/tools/include/linux/kernel.h:43:24: error: comparison of distinct pointer types lacks a cast [-Werror] 43 | (void) (&_max1 == &_max2); \ | ^~ builtin-sched.c:673:34: note: in expansion of macro 'max' 673 | (size_t) max(16 * 1024, PTHREAD_STACK_MIN)); | ^~~ cc1: all warnings being treated as errors $ grep __sysconf /usr/include/*/*.h /usr/include/bits/pthread_stack_min-dynamic.h:extern long int __sysconf (int __name) __THROW; /usr/include/bits/pthread_stack_min-dynamic.h:# define PTHREAD_STACK_MIN __sysconf (__SC_THREAD_STACK_MIN_VALUE) /usr/include/bits/time.h:extern long int __sysconf (int); /usr/include/bits/time.h:# define CLK_TCK ((__clock_t) __sysconf (2)) /* 2 is _SC_CLK_TCK */ $ So cast it to int to cope with that. Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: NZou Wei <zou_wei@huawei.com> Reviewed-by: NYang Jihong <yangjihong1@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 15 3月, 2022 1 次提交
-
-
由 Zengruan Ye 提交于
virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4VZPC CVE: NA -------------------------------- Commit 63042c58 ("KVM: arm64: Add interface to support vCPU preempted check") introduced paravirt spinlock operations, as pv_lock_ops was exported via EXPORT_SYMBOL(), while the pv_ops structure containing the pv lock operations is exported via EXPORT_SYMBOL_GPL(). Change that by using EXPORT_SYMBOL(pv_ops) for arm/arm64, as with the x86 architecture changes, the following: https://lore.kernel.org/all/20181029150116.25372-1-jgross@suse.com/T/#u Fixes: 63042c58 ("KVM: arm64: Add interface to support vCPU preempted check") Signed-off-by: Nyezengruan <yezengruan@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Acked-by: NXie Xiuqi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 11 3月, 2022 3 次提交
-
-
由 shenxiangwei 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4XHBM CVE: NA ------------- The check for control character shouldn't be added when import a binary digest list. Signed-off-by: Nshenxiangwei <shenxiangwei1@huawei.com> Reviewed-by: NLu Huaxin <luhuaxin1@huawei.com> Reviewed-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chiqijun 提交于
driver inclusion category: bugfix bugzilla: 4472 https://gitee.com/openeuler/kernel/issues/I4O2ZZ ----------------------------------------------------------------------- When rx_buff is greater than 2, the driver will alloc for more than 1 page of memory for network rx, but the __GFP_COMP gfp flag is not set, resulting in the following call trace: CPU: 3 PID: 494041 Comm: ping Kdump: loaded Tainted: G W OE 4.19.90-2106.3.0.0095.oe1.x86_64 #1 Hardware name: Huawei Technologies Co., Ltd. RH2288H V3/BC11HGSA0, BIOS 5.15 05/21/2019 RIP: 0010:copy_page_to_iter+0x154/0x310 Code: 31 b8 00 10 00 00 f7 c6 00 80 00 00 74 07 0f b6 49 51 48 d3 e0 48 39 c2 0f 86 ed fe ff ff 48 c7 c7 30 RSP: 0018:ffffbd6907d03bd8 EFLAGS: 00010286 RAX: 0000000000000024 RBX: ffffe0ffee5b3000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9edbbfcd6858 RDI: ffff9edbbfcd6858 RBP: 0000000000000001 R08: 000000000001574a R09: 0000000000000004 R10: 000000000000004e R11: 0000000000000001 R12: ffffbd6907d03ed0 R13: 0000000000002100 R14: 0000000000000030 R15: 0000000000000000 FS: 00007f9d37244dc0(0000) GS:ffff9edbbfcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe0e715f80 CR3: 000000203c018005 CR4: 00000000001606e0 Call Trace: skb_copy_datagram_iter+0x16c/0x2a0 raw_recvmsg+0xd0/0x1f0 inet_recvmsg+0x5b/0xd0 ____sys_recvmsg+0x95/0x160 ? import_iovec+0x37/0xd0 ? copy_msghdr_from_user+0x5c/0x90 ___sys_recvmsg+0x8c/0xd0 ? __audit_syscall_exit+0x228/0x290 ? kretprobe_trampoline+0x25/0x50 ? __sys_recvmsg+0x5b/0xa0 __sys_recvmsg+0x5b/0xa0 do_syscall_64+0x5f/0x240 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Use 'dev_alloc_pages' instead of calling ’alloc_pages_node‘ directly. Signed-off-by: NChiqijun <chiqijun@huawei.com> Reviewed-by: NWangxiaoyun <cloud.wangxiaoyun@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chiqijun 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I4XF98 CVE: NA ----------------------------------------------------------------------- The hinic driver currently generates a NULL pointer dereference when performing the hinicadm tool command during device probe. This is because the hinicadm process accesses the NULL hwif pointer in the hwdev which have not been allocated in probe. Fix this by checking the initialization state of device before accessing it. Signed-off-by: NChiqijun <chiqijun@huawei.com> Reviewed-by: NWangxiaoyun <cloud.wangxiaoyun@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 10 3月, 2022 1 次提交
-
-
由 Chiqijun 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I4WWH4 CVE: NA ----------------------------------------------------------------------- When hinic_remove is executed concurrently, chip_node is double freed. Signed-off-by: NChiqijun <chiqijun@huawei.com> Reviewed-by: NWangxiaoyun <cloud.wangxiaoyun@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 09 3月, 2022 9 次提交
-
-
由 Yanling Song 提交于
Ramaxel inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4UA67 CVE: NA ---------------------------------------------- Fix: 1.Remove UNF_ORIGIN_HOTTAG_MASK and UNF_HOTTAG_FLAG 2.Update some output string 3.Remove spinlock protect in free_parent_sq() because there is spinlock protect in caller function free_parent_queue_info() Signed-off-by: NYanling Song <songyl@ramaxel.com> Reviewed-by: NYun Xu <xuyun@ramaxel.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dave Chinner 提交于
mainline-inclusion from mainline-v5.14-rc4 commit 68a74dca category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4V7IK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68a74dcae6737c27b524b680e070fe41f0cad43a ------------------------------------------------- Because log recovery depends on strictly ordered start records as well as strictly ordered commit records. This is a zero day bug in the way XFS writes pipelined transactions to the journal which is exposed by fixing the zero day bug that prevents the CIL from pipelining checkpoints. This re-introduces explicit concurrent commits back into the on-disk journal and hence out of order start records. The XFS journal commit code has never ordered start records and we have relied on strict commit record ordering for correct recovery ordering of concurrently written transactions. Unfortunately, root cause analysis uncovered the fact that log recovery uses the LSN of the start record for transaction commit processing. Hence, whilst the commits are processed in strict order by recovery, the LSNs associated with the commits can be out of order and so recovery may stamp incorrect LSNs into objects and/or misorder intents in the AIL for later processing. This can result in log recovery failures and/or on disk corruption, sometimes silent. Because this is a long standing log recovery issue, we can't just fix log recovery and call it good. This still leaves older kernels susceptible to recovery failures and corruption when replaying a log from a kernel that pipelines checkpoints. There is also the issue that in-memory ordering for AIL pushing and data integrity operations are based on checkpoint start LSNs, and if the start LSN is incorrect in the journal, it is also incorrect in memory. Hence there's really only one choice for fixing this zero-day bug: we need to strictly order checkpoint start records in ascending sequence order in the log, the same way we already strictly order commit records. Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NLihong Kou <koulihong@huawei.com> Reviewed-by: Nguoxuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dave Chinner 提交于
mainline-inclusion from mainline-v5.14-rc4 commit caa80090 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4V7IK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caa80090d17c89d0caca1dcb4c8a9cdef5335e71 ------------------------------------------------- Now that we have a mechanism to guarantee that the callbacks attached to an iclog are owned by the context that attaches them until they drop their reference to the iclog via xlog_state_release_iclog(), we can attach callbacks to the iclog at any time we have an active reference to the iclog. xlog_state_get_iclog_space() always guarantees that the commit record will fit in the iclog it returns, so we can move this IO callback setting to xlog_cil_set_ctx_write_state(), record the commit iclog in the context and remove the need for the commit iclog to be returned by xlog_write() altogether. This, in turn, allows us to move the wakeup for ordered commit record writes up into xlog_cil_set_ctx_write_state(), too, because we have been guaranteed that this commit record will be physically located in the iclog before any waiting commit record at a higher sequence number will be granted iclog space. This further cleans up the post commit record write processing in the CIL push code, especially as xlog_state_release_iclog() will now clean up the context when shutdown errors occur. Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NLihong Kou <koulihong@huawei.com> Reviewed-by: Nguoxuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dave Chinner 提交于
mainline-inclusion from mainline-v5.14-rc4 commit bf034bc8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4V7IK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bf034bc827807ac15affa051e6a94b03f93b1a03 ------------------------------------------------- So we can use it for start record ordering as well as commit record ordering in future. Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NLihong Kou <koulihong@huawei.com> Reviewed-by: Nguoxuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dave Chinner 提交于
mainline-inclusion from mainline-v5.14-rc4 commit c45aba40 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4V7IK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c45aba40cf5b2988c0bebee8c9b846c88aa651eb ------------------------------------------------- Pass the CIL context to xlog_write() rather than a pointer to a LSN variable. Only the CIL checkpoint calls to xlog_write() need to know about the start LSN of the writes, so rework xlog_write to directly write the LSNs into the CIL context structure. This removes the commit_lsn variable from xlog_cil_push_work(), so now we only have to issue the commit record ordering wakeup from there. Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NLihong Kou <koulihong@huawei.com> Reviewed-by: Nguoxuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Darrick J. Wong 提交于
mainline-inclusion from mainline-v5.10-rc5 commit a5336d6b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4V7IK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5336d6bb2d02d0e9d4d3c8be04b80b8b68d56c8 ------------------------------------------------- In commit 27c14b5d we started tracking the last inode seen during an inode walk to avoid infinite loops if a corrupt inobt record happens to have a lower ir_startino than the record preceeding it. Unfortunately, the assertion trips over the case where there are completely empty inobt records (which can happen quite easily on 64k page filesystems) because we advance the tracking cursor without actually putting the empty record into the processing buffer. Fix the assert to allow for this case. Reported-by: zlang@redhat.com Fixes: 27c14b5d ("xfs: ensure inobt record walks always make forward progress") Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com> Reviewed-by: NZorro Lang <zlang@redhat.com> Reviewed-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: Nguoxuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dave Chinner 提交于
mainline-inclusion from mainline-v5.14-rc4 commit 2ce82b72 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4V7IK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ce82b722de980deef809438603b7e95156d3818 ------------------------------------------------- It is only used by the CIL checkpoints, and is the counterpart to start record formatting and writing that is already local to xfs_log_cil.c. Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NLihong Kou <koulihong@huawei.com> Reviewed-by: Nguoxuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dave Chinner 提交于
mainline-inclusion from mainline-v5.14-rc4 commit 2562c322 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4V7IK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2562c322404d81ee5fa82f3cf601a2e27393ab57 ------------------------------------------------- I'm seeing assert failures from xlog_space_left() after a shutdown has begun that look like: XFS (dm-0): log I/O error -5 XFS (dm-0): xfs_do_force_shutdown(0x2) called from line 1338 of file fs/xfs/xfs_log.c. Return address = xlog_ioend_work+0x64/0xc0 XFS (dm-0): Log I/O Error Detected. XFS (dm-0): Shutting down filesystem. Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xlog_space_left: head behind tail XFS (dm-0): tail_cycle = 6, tail_bytes = 2706944 XFS (dm-0): GH cycle = 6, GH bytes = 1633867 XFS: Assertion failed: 0, file: fs/xfs/xfs_log.c, line: 1310 ------------[ cut here ]------------ Call Trace: xlog_space_left+0xc3/0x110 xlog_grant_push_threshold+0x3f/0xf0 xlog_grant_push_ail+0x12/0x40 xfs_log_reserve+0xd2/0x270 ? __might_sleep+0x4b/0x80 xfs_trans_reserve+0x18b/0x260 ..... There are two things here. Firstly, after a shutdown, the log head and tail can be out of whack as things abort and release (or don't release) resources, so checking them for sanity doesn't make much sense. Secondly, xfs_log_reserve() can race with shutdown and so it can still fail like this even though it has already checked for a log shutdown before calling xlog_grant_push_ail(). So, before ASSERT failing in xlog_space_left(), make sure we haven't already shut down.... Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NLihong Kou <koulihong@huawei.com> Reviewed-by: Nguoxuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dave Chinner 提交于
mainline-inclusion from mainline-v5.14-rc4 commit 502a01fa category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4V7IK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=502a01fac0983406e7c312764d7a03e06b3d0748 ------------------------------------------------- When the log is shutdown, it currently walks all the iclogs and runs callbacks that are attached to the iclogs, regardless of whether the iclog is queued for IO completion or not. This creates a problem for contexts attaching callbacks to iclogs in that a racing shutdown can run the callbacks even before the attaching context has finished processing the iclog and releasing it for IO submission. If the callback processing of the iclog frees the structure that is attached to the iclog, then this leads to an UAF scenario that can only be protected against by holding the icloglock from the point callbacks are attached through to the release of the iclog. While we currently do this, it is not practical or sustainable. Hence we need to make shutdown processing the responsibility of the context that holds active references to the iclog. We know that the contexts attaching callbacks to the iclog must have active references to the iclog, and that means they must be in either ACTIVE or WANT_SYNC states. xlog_state_do_callback() will skip over iclogs in these states -except- when the log is shut down. xlog_state_do_callback() checks the state of the iclogs while holding the icloglock, therefore the reference count/state change that occurs in xlog_state_release_iclog() after the callbacks are atomic w.r.t. shutdown processing. We can't push the responsibility of callback cleanup onto the CIL context because we can have ACTIVE iclogs that have callbacks attached that have already been released. Hence we really need to internalise the cleanup of callbacks into xlog_state_release_iclog() processing. Indeed, we already have that internalisation via: xlog_state_release_iclog drop last reference ->SYNCING xlog_sync xlog_write_iclog if (log_is_shutdown) xlog_state_done_syncing() xlog_state_do_callback() <process shutdown on iclog that is now in SYNCING state> The problem is that xlog_state_release_iclog() aborts before doing anything if the log is already shut down. It assumes that the callbacks have already been cleaned up, and it doesn't need to do any cleanup. Hence the fix is to remove the xlog_is_shutdown() check from xlog_state_release_iclog() so that reference counts are correctly released from the iclogs, and when the reference count is zero we always transition to SYNCING if the log is shut down. Hence we'll always enter the xlog_sync() path in a shutdown and eventually end up erroring out the iclog IO and running xlog_state_do_callback() to process the callbacks attached to the iclog. This allows us to stop processing referenced ACTIVE/WANT_SYNC iclogs directly in the shutdown code, and in doing so gets rid of the UAF vector that currently exists. This then decouples the adding of callbacks to the iclogs from xlog_state_release_iclog() as we guarantee that xlog_state_release_iclog() will process the callbacks if the log has been shut down before xlog_state_release_iclog() has been called. Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NLihong Kou <koulihong@huawei.com> Reviewed-by: Nguoxuenan <guoxuenan@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-