- 13 5月, 2020 14 次提交
-
-
由 fengsheng 提交于
driver inclusion category: feature bugzilla: NA CVE: NA 1. add interface: sysctl_pmbus_write_common 2. add interface: sysctl_pmbus_read_common Signed-off-by: Nfengsheng <fengsheng5@huawei.com> Reviewed-by: Nwuyang <wuyang7@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Chiqijun 提交于
driver inclusion category: bugfix bugzilla: 4472 ----------------------------------------------------------------------- The current driver does not support ipip tunnel packet parsing. When the csum of the device is turned on, driver will get wrong inner headers, and causing device error. Signed-off-by: NChiqijun <chiqijun@huawei.com> Reviewed-by: NLuoshaokai <luoshaokai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Magnus Karlsson 提交于
mainline inclusion from mainline-v5.7-rc2 commit 99e3a236dd43d06c65af0a2ef9cb44306aef6e02 category: bugfix bugzilla: 13690 CVE: CVE-2020-12659 ------------------------------------------------- Add a check that the headroom cannot be larger than the available space in the chunk. In the current code, a malicious user can set the headroom to a value larger than the chunk size minus the fixed XDP headroom. That way packets with a length larger than the supported size in the umem could get accepted and result in an out-of-bounds write. Fixes: c0c77d8f ("xsk: add user memory registration support sockopt") Reported-by: NBui Quang Minh <minhquangbui99@gmail.com> Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=207225 Link: https://lore.kernel.org/bpf/1586849715-23490-1-git-send-email-magnus.karlsson@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org> Conflicts: net/xdp/xdp_umem.c [yyl: adjust context] Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NWenan Mao <maowenan@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Piotr Krysiuk 提交于
stable inclusion from linux-4.19.119 commit f511dc75d22e0c000fc70b54f670c2c17f5fba9a CVE: CVE-2020-12114 -------------------------------- A race condition between threads updating mountpoint reference counter affects longterm releases 4.4.220, 4.9.220, 4.14.177 and 4.19.118. The mountpoint reference counter corruption may occur when: * one thread increments m_count member of struct mountpoint [under namespace_sem, but not holding mount_lock] pivot_root() * another thread simultaneously decrements the same m_count [under mount_lock, but not holding namespace_sem] put_mountpoint() unhash_mnt() umount_mnt() mntput_no_expire() To fix this race condition, grab mount_lock before updating m_count in pivot_root(). Reference: CVE-2020-12114 Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: NPiotr Krysiuk <piotras@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: Nzhangyi (F) <yi.zhang@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Alan Stern 提交于
mainline inclusion from mainline-v5.7-rc3 commit 056ad39ee9253873522f6469c3364964a322912b category: bugfix bugzilla: 13690 CVE: CVE-2020-12464 ------------------------------------------------- FuzzUSB (a variant of syzkaller) found a free-while-still-in-use bug in the USB scatter-gather library: BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607 Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27 CPU: 1 PID: 27 Comm: kworker/u4:1 Not tainted 5.5.11 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: scsi_tmf_2 scmd_eh_abort_handler Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x153/0x1cb mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x152/0x1b0 mm/kasan/generic.c:192 __kasan_check_read+0x11/0x20 mm/kasan/common.c:95 atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607 usb_unlink_urb+0x72/0xb0 drivers/usb/core/urb.c:657 usb_sg_cancel+0x14e/0x290 drivers/usb/core/message.c:602 usb_stor_stop_transport+0x5e/0xa0 drivers/usb/storage/transport.c:937 This bug occurs when cancellation of the S-G transfer races with transfer completion. When that happens, usb_sg_cancel() may continue to access the transfer's URBs after usb_sg_wait() has freed them. The bug is caused by the fact that usb_sg_cancel() does not take any sort of reference to the transfer, and so there is nothing to prevent the URBs from being deallocated while the routine is trying to use them. The fix is to take such a reference by incrementing the transfer's io->count field while the cancellation is in progres and decrementing it afterward. The transfer's URBs are not deallocated until io->complete is triggered, which happens when io->count reaches zero. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: NKyungtae Kim <kt0755@gmail.com> CC: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2003281615140.14837-100000@netrider.rowland.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zhiqiang Liu 提交于
[ Upstream commit 2f95fa5c955d0a9987ffdc3a095e2f4e62c5f2a9 ] In bfq_idle_slice_timer func, bfqq = bfqd->in_service_queue is not in bfqd-lock critical section. The bfqq, which is not equal to NULL in bfq_idle_slice_timer, may be freed after passing to bfq_idle_slice_timer_body. So we will access the freed memory. In addition, considering the bfqq may be in race, we should firstly check whether bfqq is in service before doing something on it in bfq_idle_slice_timer_body func. If the bfqq in race is not in service, it means the bfqq has been expired through __bfq_bfqq_expire func, and wait_request flags has been cleared in __bfq_bfqd_reset_in_service func. So we do not need to re-clear the wait_request of bfqq which is not in service. KASAN log is given as follows: [13058.354613] ================================================================== [13058.354640] BUG: KASAN: use-after-free in bfq_idle_slice_timer+0xac/0x290 [13058.354644] Read of size 8 at addr ffffa02cf3e63f78 by task fork13/19767 [13058.354646] [13058.354655] CPU: 96 PID: 19767 Comm: fork13 [13058.354661] Call trace: [13058.354667] dump_backtrace+0x0/0x310 [13058.354672] show_stack+0x28/0x38 [13058.354681] dump_stack+0xd8/0x108 [13058.354687] print_address_description+0x68/0x2d0 [13058.354690] kasan_report+0x124/0x2e0 [13058.354697] __asan_load8+0x88/0xb0 [13058.354702] bfq_idle_slice_timer+0xac/0x290 [13058.354707] __hrtimer_run_queues+0x298/0x8b8 [13058.354710] hrtimer_interrupt+0x1b8/0x678 [13058.354716] arch_timer_handler_phys+0x4c/0x78 [13058.354722] handle_percpu_devid_irq+0xf0/0x558 [13058.354731] generic_handle_irq+0x50/0x70 [13058.354735] __handle_domain_irq+0x94/0x110 [13058.354739] gic_handle_irq+0x8c/0x1b0 [13058.354742] el1_irq+0xb8/0x140 [13058.354748] do_wp_page+0x260/0xe28 [13058.354752] __handle_mm_fault+0x8ec/0x9b0 [13058.354756] handle_mm_fault+0x280/0x460 [13058.354762] do_page_fault+0x3ec/0x890 [13058.354765] do_mem_abort+0xc0/0x1b0 [13058.354768] el0_da+0x24/0x28 [13058.354770] [13058.354773] Allocated by task 19731: [13058.354780] kasan_kmalloc+0xe0/0x190 [13058.354784] kasan_slab_alloc+0x14/0x20 [13058.354788] kmem_cache_alloc_node+0x130/0x440 [13058.354793] bfq_get_queue+0x138/0x858 [13058.354797] bfq_get_bfqq_handle_split+0xd4/0x328 [13058.354801] bfq_init_rq+0x1f4/0x1180 [13058.354806] bfq_insert_requests+0x264/0x1c98 [13058.354811] blk_mq_sched_insert_requests+0x1c4/0x488 [13058.354818] blk_mq_flush_plug_list+0x2d4/0x6e0 [13058.354826] blk_flush_plug_list+0x230/0x548 [13058.354830] blk_finish_plug+0x60/0x80 [13058.354838] read_pages+0xec/0x2c0 [13058.354842] __do_page_cache_readahead+0x374/0x438 [13058.354846] ondemand_readahead+0x24c/0x6b0 [13058.354851] page_cache_sync_readahead+0x17c/0x2f8 [13058.354858] generic_file_buffered_read+0x588/0xc58 [13058.354862] generic_file_read_iter+0x1b4/0x278 [13058.354965] ext4_file_read_iter+0xa8/0x1d8 [ext4] [13058.354972] __vfs_read+0x238/0x320 [13058.354976] vfs_read+0xbc/0x1c0 [13058.354980] ksys_read+0xdc/0x1b8 [13058.354984] __arm64_sys_read+0x50/0x60 [13058.354990] el0_svc_common+0xb4/0x1d8 [13058.354994] el0_svc_handler+0x50/0xa8 [13058.354998] el0_svc+0x8/0xc [13058.354999] [13058.355001] Freed by task 19731: [13058.355007] __kasan_slab_free+0x120/0x228 [13058.355010] kasan_slab_free+0x10/0x18 [13058.355014] kmem_cache_free+0x288/0x3f0 [13058.355018] bfq_put_queue+0x134/0x208 [13058.355022] bfq_exit_icq_bfqq+0x164/0x348 [13058.355026] bfq_exit_icq+0x28/0x40 [13058.355030] ioc_exit_icq+0xa0/0x150 [13058.355035] put_io_context_active+0x250/0x438 [13058.355038] exit_io_context+0xd0/0x138 [13058.355045] do_exit+0x734/0xc58 [13058.355050] do_group_exit+0x78/0x220 [13058.355054] __wake_up_parent+0x0/0x50 [13058.355058] el0_svc_common+0xb4/0x1d8 [13058.355062] el0_svc_handler+0x50/0xa8 [13058.355066] el0_svc+0x8/0xc [13058.355067] [13058.355071] The buggy address belongs to the object at ffffa02cf3e63e70#012 which belongs to the cache bfq_queue of size 464 [13058.355075] The buggy address is located 264 bytes inside of#012 464-byte region [ffffa02cf3e63e70, ffffa02cf3e64040) [13058.355077] The buggy address belongs to the page: [13058.355083] page:ffff7e80b3cf9800 count:1 mapcount:0 mapping:ffff802db5c90780 index:0xffffa02cf3e606f0 compound_mapcount: 0 [13058.366175] flags: 0x2ffffe0000008100(slab|head) [13058.370781] raw: 2ffffe0000008100 ffff7e80b53b1408 ffffa02d730c1c90 ffff802db5c90780 [13058.370787] raw: ffffa02cf3e606f0 0000000000370023 00000001ffffffff 0000000000000000 [13058.370789] page dumped because: kasan: bad access detected [13058.370791] [13058.370792] Memory state around the buggy address: [13058.370797] ffffa02cf3e63e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb [13058.370801] ffffa02cf3e63e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [13058.370805] >ffffa02cf3e63f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [13058.370808] ^ [13058.370811] ffffa02cf3e63f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [13058.370815] ffffa02cf3e64000: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [13058.370817] ================================================================== [13058.370820] Disabling lock debugging due to kernel taint Here, we directly pass the bfqd to bfq_idle_slice_timer_body func. -- V2->V3: rewrite the comment as suggested by Paolo Valente V1->V2: add one comment, and add Fixes and Reported-by tag. Fixes: aee69d78 ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler") Acked-by: NPaolo Valente <paolo.valente@linaro.org> Reported-by: NWang Wang <wangwang2@huawei.com> Signed-off-by: NZhiqiang Liu <liuzhiqiang26@huawei.com> Signed-off-by: NFeilong Lin <linfeilong@huawei.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Qing Xu 提交于
[ Upstream commit b70261a288ea4d2f4ac7cd04be08a9f0f2de4f4d ] mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy(). Signed-off-by: NQing Xu <m1s5p6688@gmail.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Qing Xu 提交于
[ Upstream commit 3a9b153c5591548612c3955c9600a98150c81875 ] mwifiex_ret_wmm_get_status() calls memcpy() without checking the destination size.Since the source is given from remote AP which contains illegal wmm elements , this may trigger a heap buffer overflow. Fix it by putting the length check before calling memcpy(). Signed-off-by: NQing Xu <m1s5p6688@gmail.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Dan Carpenter 提交于
commit 28d76df18f0ad5bcf5fa48510b225f0ed262a99b upstream. Tom Hatskevich reported that we look up "iocp" then, in the called functions we do a second copy_from_user() and look it up again. The problem that could cause is: drivers/message/fusion/mptctl.c 674 /* All of these commands require an interrupt or 675 * are unknown/illegal. 676 */ 677 if ((ret = mptctl_syscall_down(iocp, nonblock)) != 0) ^^^^ We take this lock. 678 return ret; 679 680 if (cmd == MPTFWDOWNLOAD) 681 ret = mptctl_fw_download(arg); ^^^ Then the user memory changes and we look up "iocp" again but a different one so now we are holding the incorrect lock and have a race condition. 682 else if (cmd == MPTCOMMAND) 683 ret = mptctl_mpt_command(arg); The security impact of this bug is not as bad as it could have been because these operations are all privileged and root already has enormous destructive power. But it's still worth fixing. This patch passes the "iocp" pointer to the functions to avoid the second lookup. That deletes 100 lines of code from the driver so it's a nice clean up as well. Link: https://lore.kernel.org/r/20200114123414.GA7957@kadamReported-by: NTom Hatskevich <tom2001tom.23@gmail.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Felix Fietkau 提交于
commit b102f0c522cf668c8382c56a4f771b37d011cda2 upstream. If the hardware receives an oversized packet with too many rx fragments, skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages. This becomes especially visible if it corrupts the freelist pointer of a slab page. Cc: stable@vger.kernel.org Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yufeng Mo 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------- The HNS RDMA driver will support VF device later, whose re-initialization should be done after PF's. This patch changes the order of hclge_reset_prepare_up() and hclge_notify_roce_client(), so that PF's roce client will be reinitialized before VF's Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Reviewed-by: NWeiwei Deng <dengweiwei@huawei.com> Reviewed-by: NPeng Li <lipeng321@huawei.com> Reviewed-by: NShengzui You <youshengzui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Shengzui You 提交于
driver inclusion category: other bugzilla: NA CVE: NA --------------------------------- This patch is used to modify the hns3 driver version to 1.9.37.9 Signed-off-by: NShengzui You <youshengzui@huawei.com> Reviewed-by: NWeiwei Deng <dengweiwei@huawei.com> Reviewed-by: NZhaohui Zhong <zhongzhaohui@huawei.com> Reviewed-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Ye Bin 提交于
hulk inclusion category: bugfix bugzilla: 34271 CVE: NA -------------------------------- This reverts commit fd72360bc94ad304136beb56e8ff2ec089113bb8. test setp: ... rmmod hisi_sas_v3_hw lsmod fdisk -l insomd hisi_sas_v3_hw.ko lsmod fdisk -l .... We get follow error when we test by above test steps. [ 3660.259153] [ffff00000116f000] pgd=00002027ffffe003, pud=00002027ffffd003, pmd=00002027cdf28003, pte=0000000000000000 [ 3660.269719] Internal error: Oops: 96000007 [#1] PREEMPT SMP [ 3660.275266] Modules linked in: hisi_sas_v3_hw(+) hisi_sas_main hns_roce_hw_v2(O) hns_roce(O) rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_ipoib ib_umad realtek hns3(O) hclge(O) hnae3(O) crc32_ce crct10dif_ce hisi_hpre hisi_zip hisi_qm uacce hisi_trng_v2 rng_core sfc lbc ip_tables x_tables libsas scsi_transport_sas [last unloaded: hisi_sas_main] [ 3660.308227] Process smartd (pid: 19570, stack limit = 0x000000001103634d) [ 3660.314985] CPU: 31 PID: 19570 Comm: smartd Kdump: loaded Tainted: G O 4.19.36-g32894fc #1 [ 3660.324504] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B220.02 03/27/2020 [ 3660.334110] pstate: 60400009 (nZCv daif +PAN -UAO) [ 3660.338882] pc : scsi_device_put+0x18/0x38 [ 3660.342961] lr : scsi_disk_put+0x3c/0x58 [ 3660.346865] sp : ffff0000158a3cb0 [ 3660.350164] x29: ffff0000158a3cb0 x28: ffff8027b8111000 [ 3660.355451] x27: 00000000080a005d x26: 0000000000000000 [ 3660.360738] x25: ffff8027c6310398 x24: ffff8027cd2ec410 [ 3660.366025] x23: ffff000009811000 x22: ffff80276d274750 [ 3660.371312] x21: ffff8027abdd5000 x20: ffff8027b8110800 [ 3660.376599] x19: ffff8027abdd5000 x18: 0000000000000000 [ 3660.381886] x17: 0000000000000000 x16: 0000000000000000 [ 3660.387172] x15: 0000000000000000 x14: 0000000000000000 [ 3660.392459] x13: ffff000009996cd0 x12: ffffffffffffffff [ 3660.397746] x11: ffff000009996cc8 x10: 0000000000000000 [ 3660.403033] x9 : 0000000000000000 x8 : 0000000040000000 [ 3660.408320] x7 : ffff0000098116c8 x6 : 0000000000000000 [ 3660.413607] x5 : ffff00000820ebbc x4 : ffff7e009eb8fb20 [ 3660.418894] x3 : 0000000080400009 x2 : ffff8027ae3ec600 [ 3660.424180] x1 : 71b6030ca20bb300 x0 : ffff00000116f000 [ 3660.429467] Call trace: [ 3660.431904] scsi_device_put+0x18/0x38 [ 3660.435636] scsi_disk_put+0x3c/0x58 [ 3660.439195] sd_release+0x50/0xc0 [ 3660.442496] __blkdev_put+0x20c/0x220 [ 3660.446141] blkdev_put+0x4c/0x110 [ 3660.449527] blkdev_close+0x1c/0x28 [ 3660.453000] __fput+0x88/0x1b8 [ 3660.456042] ____fput+0xc/0x18 [ 3660.459085] task_work_run+0x94/0xb0 [ 3660.462646] do_notify_resume+0x17c/0x180 [ 3660.466637] work_pending+0x8/0x10 [ 3660.470022] Code: f9000bf3 aa0003f3 f9400000 f9404c00 (f9400000) [ 3660.476089] ---[ end trace ca1d0144f9241f71 ]--- void scsi_device_put(struct scsi_device *sdev) { module_put(sdev->host->hostt->module); ---> error code put_device(&sdev->sdev_gendev); } When access "sdev->host->hostt" occurs exception, as "sdev->host->hostt" is point to the module address space which is already removed. module_delete first check module reference count, then call module exit function. So after pass module reference count check and before call module exit, we can call scsi_device_get function successfully. As "scsi: fix failing unload of a LLDD module" lead to call scsi_device_get success during remove module. We revert this patch, "scsi: fixup kernel warning during rmmod()" already fixed previous error. Signed-off-by: NYe Bin <yebin10@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Christian Borntraeger 提交于
mainline inclusion from mainline-v5.7-rc4 commit 316ec154810960052d4586b634156c54d0778f74 category: bugfix bugzilla: 13690 CVE: CVE-2020-11884 ------------------------------------------------- A page table upgrade in a kernel section that uses secondary address mode will mess up the kernel instructions as follows: Consider the following scenario: two threads are sharing memory. On CPU1 thread 1 does e.g. strnlen_user(). That gets to old_fs = enable_sacf_uaccess(); len = strnlen_user_srst(src, size); and " la %2,0(%1)\n" " la %3,0(%0,%1)\n" " slgr %0,%0\n" " sacf 256\n" "0: srst %3,%2\n" in strnlen_user_srst(). At that point we are in secondary space mode, control register 1 points to kernel page table and instruction fetching happens via c1, rather than usual c13. Interrupts are not disabled, for obvious reasons. On CPU2 thread 2 does MAP_FIXED mmap(), forcing the upgrade of page table from 3-level to e.g. 4-level one. We'd allocated new top-level table, set it up and now we hit this: notify = 1; spin_unlock_bh(&mm->page_table_lock); } if (notify) on_each_cpu(__crst_table_upgrade, mm, 0); OK, we need to actually change over to use of new page table and we need that to happen in all threads that are currently running. Which happens to include the thread 1. IPI is delivered and we have static void __crst_table_upgrade(void *arg) { struct mm_struct *mm = arg; if (current->active_mm == mm) set_user_asce(mm); __tlb_flush_local(); } run on CPU1. That does static inline void set_user_asce(struct mm_struct *mm) { S390_lowcore.user_asce = mm->context.asce; OK, user page table address updated... __ctl_load(S390_lowcore.user_asce, 1, 1); ... and control register 1 set to it. clear_cpu_flag(CIF_ASCE_PRIMARY); } IPI is run in home space mode, so it's fine - insns are fetched using c13, which always points to kernel page table. But as soon as we return from the interrupt, previous PSW is restored, putting CPU1 back into secondary space mode, at which point we no longer get the kernel instructions from the kernel mapping. The fix is to only fixup the control registers that are currently in use for user processes during the page table update. We must also disable interrupts in enable_sacf_uaccess to synchronize the cr and thread.mm_segment updates against the on_each-cpu. Fixes: 0aaba41b ("s390: remove all code using the access register mode") Cc: stable@vger.kernel.org # 4.15+ Reported-by: NAl Viro <viro@zeniv.linux.org.uk> Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com> References: CVE-2020-11884 Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 09 5月, 2020 2 次提交
-
-
由 Liu Yanshi 提交于
driver inclusion category: feature bugzilla: NA CVE: NA pcie_cae add interface to get the chipnums of the current system. Signed-off-by: NLiu Yanshi <liuyanshi@huawei.com> Reviewed-by: NZhu Xiongxiong <zhuxiongxiong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zhengyuan Liu 提交于
driver inclusion category: other bugzilla: NA CVE: NA ---------------------------------- The ccflags removed in this patch shouldn't be in open kernel tree. Especially for -fstack-protector-strong, there will be a compile error when CONFIG_STACKPROTECTOR_STRONG isn't enabled. Signed-off-by: NZhengyuan Liu <liuzhengyuan@tj.kylinos.cn> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 06 5月, 2020 4 次提交
-
-
由 Changbin Du 提交于
mainline inclusion from mainline-5.6 commit 0ada120c883d4f1f6aafd01cf0fbb10d8bbba015 category: bugfix bugzilla: 34555 CVE: NA ------------------------------------------------- libbfd has changed the bfd_section_* macros to inline functions bfd_section_<field> since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by: NChangbin Du <changbin.du@gmail.com> Acked-by: NJiri Olsa <jolsa@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com> Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 yu kuai 提交于
hulk inclusion category: bugfix bugzilla: 34280 CVE: NA --------------------------- blk_mq_tagset_busy_iter() is not safe that it could get stale request in tags->rqs[]. Use blk_mq_queue_tag_inflight_iter() here. Signed-off-by: Nyu kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 yu kuai 提交于
hulk inclusion category: bugfix bugzilla: 34280 CVE: NA --------------------------- blk_mq_tagset_busy_iter() is not safe that it could get stale request in tags->rqs[]. Use blk_mq_queue_tag_inflight_iter() here. Signed-off-by: Nyu kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 yu kuai 提交于
hulk inclusion category: bugfix bugzilla: 34280 CVE: NA --------------------------- tags->rqs[] will not been cleaned when free driver tag to avoid an extra store on a shared area in the per io path. But there is a window between get driver tag and write tags->rqs[], so we may see stale rq in tags->rqs[] which may have been freed, as the following case: blk_mq_get_request blk_mq_queue_tag_busy_iter -> blk_mq_get_tag -> bt_for_each -> bt_iter -> rq = tags->rqs[] -> rq->q -> blk_mq_rq_ctx_init -> data->hctx->tags->rqs[rq->tag] = rq; In additiion, tags->rqs[] only contains the requests that get driver tag. It is not accurate for io-scheduler case when account busy tags in part_in_flight. To fix both of them, the blk_mq_queue_tag_busy_iter is changed in this patch to use tags->static_rqs[] instead of tags->rqs[]. We have to identify whether there is a io scheduler attached to decide to use hctx->tags or hctx->sched_tags. And we will try to get a non-zero q_usage_counter before that, then could avoid race with update nr_hw_queues, switch io-scheduler and even queue cleanup. Add 'inflight' parameter to determine to iterate in-flight requests or just busy tags and add a new helper interface blk_mq_queue_tag_inflight_iter to iterate all of the in-flight tags and export this interface for drivers. Signed-off-by: Nyu kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 28 4月, 2020 20 次提交
-
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------- This patch is used to modify the hns3 driver version to 1.9.37.8 Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- Currently, proto_support indicates that what kind of flow type does this device support, with value of BIT(x). Due to 'x' may be extended to more than 32 even 64, it's not a good way to deal with it. So this patch eliminates proto_support. Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- For revision 0x20, rss_tuple_set field does not support in VF, so this patch fixes this case. Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- The 802.3 specification does not specify the behavior of auto-negotiation off with 1000M in phy. Therefore, some phy compatibility issues occur. This patch forbids the setting of this unreasonable mode by ethtool in driver. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- Currently, VF doesn't hold the mac address list which has been added or deleted, it just sends the mac address configure request to PF. It's better to handle it on the same way as PF does, which can be more clearly. Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- This patch modifies a magic number in hclge_dbg_dump_ncl_config, which can improve the readability of the code. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- Currently, when traversing the mac list, and allocating memory fail for mac node, it will stop traversing, and rollback the tmp_add_list and tmp_del_list. It's unnecessary, we can continue the configuration with the tmp_add_list and tmp_del_list, which may free some memory after delete node. Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- Currently, we change the device address directly in the path f hns3_set_mac_address(). There is a race with calling hclge_sync_vport_mac_table(), both them can add/delete mac address without vport->mac_list_lock protection. This patch fixes it by only updating mac list, then adding/deleting the mac address by hclge_sync_vport_mac_table(). Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- Function hns3_nic_net_xmit() and functioin hns3_nic_maybe_stop_tx() both get ring pointer from priv->ring[]. According to opinion of community to reduce this kind of operation, this patch adds parameter ring for function hns3_nic_maybe_stop_tx(). Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- Since kernel already has logs after kzalloc fails, it's unnecessary to print duplicate logs. So this patch deletes these logs. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- This patch fixes the following two points: 1. Net device can not change mtu with stream. So if 'net stop' failed, mtu setting should abort. this patch fixes this. 2. Fixes some coding style with the location of parameter. Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- This patch modifies one failed print message for using uniform format. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- Add some debug information for processing flow table if failed. Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- When restores rules failed in flow table list, PF driver should delete this rule in list and go on restore the rest rules. It means that it would never return other value except "0" in hclge_restore_fd_entries. So this patch modify the return type to "void". Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- When checks tuple in hclge_fd_check_ext_tuple(), two nested "if" is used as a logic judgment. It can be spliced as one,using "&&", which make code more readability. Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- An enum type parameter is passed to hclge_set_fd_key_config(), so "stage" should be declared as "enum". Parameter of "tuple_size" is from "key_length", which with type of "u8", so modify "tuple_size" to "u8" would be modre better This patch also cleanup some unnecessary blank lines, redundant parentheses. Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- This patch just modifies definition location of struct hclge_mac_ethertype_idx_rd_cmd to sync code with linux mainline. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- This patch modifies msi-x into misc for comment of macro HNAE3_MIN_VECTOR_NUM. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- This patch modifies macro HCLGE_MBX_MAX_RESP_DATA_SIZE into unsigned type and its print format from %d into %u. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 shenhao 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------------------- The macro HCLGEVF_MPF_ENBALE is never used, so this patch deletes it. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Nshenhao <shenhao21@huawei.com> Reviewed-by: NZhong Zhaohui <zhongzhaohui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-