- 26 4月, 2023 1 次提交
-
-
由 zhaoweibo 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I51UWX CVE: NA ------------------------------------------------------------- When the user-configured max_inline_data value exceeds the hardware specification, an err needs to be returned. Fixes: 87d3b87b ("RDMA/hns: Optimize qp param setup flow") Signed-off-by: Nzhaoweibo <zhaoweibo3@huawei.com> Reviewed-by: NChunzhi Hu <huchunzhi@huawei.com> Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>
-
- 25 4月, 2023 1 次提交
-
-
由 Zheng Wang 提交于
stable inclusion from stable-v4.19.280 commit 533d915899b4a5a7b5b5a99eec24b2920ccd1f11 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6W80A CVE: CVE-2023-30772 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=533d915899b4a5a7b5b5a99eec24b2920ccd1f11 -------------------------------- [ Upstream commit 06615d11 ] In da9150_charger_probe, &charger->otg_work is bound with da9150_charger_otg_work. da9150_charger_otg_ncb may be called to start the work. If we remove the module which will call da9150_charger_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows: Fix it by canceling the work before cleanup in the da9150_charger_remove CPU0 CPUc1 |da9150_charger_otg_work da9150_charger_remove | power_supply_unregister | device_unregister | power_supply_dev_release| kfree(psy) | | | power_supply_changed(charger->usb); | //use Fixes: c1a281e3 ("power: Add support for DA9150 Charger") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 24 4月, 2023 1 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @leoliu-oc Change internal project name to external product name. ### Issue https://gitee.com/openeuler/kernel/issues/I6J0SW ### Test N/A ### Knowe Issue N/A ### Default config change N/A Link:https://gitee.com/openeuler/kernel/pulls/430 Reviewed-by: Wei Li <liwei391@huawei.com>
-
- 23 4月, 2023 3 次提交
-
-
由 Wei Chen 提交于
mainline inclusion from mainline-v6.3-rc4 commit 92fbb6d1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6XHPL CVE: CVE-2023-2194 -------------------------------- The data->block[0] variable comes from user and is a number between 0-255. Without proper check, the variable may be very large to cause an out-of-bounds when performing memcpy in slimpro_i2c_blkwr. Fix this bug by checking the value of writelen. Fixes: f6505fba ("i2c: add SLIMpro I2C device driver on APM X-Gene platform") Signed-off-by: NWei Chen <harperchen1110@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: NAndi Shyti <andi.shyti@kernel.org> Signed-off-by: NWolfram Sang <wsa@kernel.org> Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Li RongQing 提交于
mainline inclusion from mainline-v5.2-rc1 commit 95e0b46f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6X2LV CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95e0b46fcebd7dbf6850dee96046e4c4ddc7f69c -------------------------------- module.name will be allocated unconditionally when auditing load module, and audit_log_start() can fail with other reasons, or audit_log_exit maybe not called, caused module.name is not freed so free module.name in audit_free_context and __audit_syscall_exit unreferenced object 0xffff88af90837d20 (size 8): comm "modprobe", pid 1036, jiffies 4294704867 (age 3069.138s) hex dump (first 8 bytes): 69 78 67 62 65 00 ff ff ixgbe... backtrace: [<0000000008da28fe>] __audit_log_kern_module+0x33/0x80 [<00000000c1491e61>] load_module+0x64f/0x3850 [<000000007fc9ae3f>] __do_sys_init_module+0x218/0x250 [<0000000000d4a478>] do_syscall_64+0x117/0x400 [<000000004924ded8>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<000000007dc331dd>] 0xffffffffffffffff Fixes: ca86cad7 ("audit: log module name on init_module") Signed-off-by: NZhang Yu <zhangyu31@baidu.com> Signed-off-by: NLi RongQing <lirongqing@baidu.com> [PM: manual merge fixup in __audit_syscall_exit()] Signed-off-by: NPaul Moore <paul@paul-moore.com> conflict: kernel/auditsc.c Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: Ncuigaosheng <cuigaosheng1@huawei.com> Reviewed-by: Nguozihua <guozihua@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ch-cityhunter #### 设备remove流程和smmu中断处理线程是异步的，并发情况下有UAF问题 1. arm_smmu_remove_device流程先释放了dev->iommu_param 中断线程查找的红黑树还能找到对应master，会导致UAF 2. 中断线程通过红黑树获取master之后使用的过程没有保护 remove流程也可以在其查找成功之后释放dev->iommu_param openeuler在2019年最初上库第一版arm-smmu-v3是就有此问题 #### 修改方法 参考内核社区，arm-smmu-v3在2021年合入社区，此问题经过review后已修正，首次合入是没问题的 https://github.com/torvalds/linux/commit/395ad89d11fd93f79a6b942e91fc409807a63c4b 1. 调整移除master和释放内存的顺序，先移除master，避免被其他流程查找到 2. arm_smmu_find_master()外部加锁，保护中断线程获取master后整个使用阶段 ``` driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKM7 CVE: NA -------- A use-after-free issue like following: [ 2257.819189] arm-smmu-v3 arm-smmu-v3.4.auto: EVTQ overflow detected -- events lost [ 2257.819197] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received: [ 2257.819199] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000820000000010 [ 2257.819201] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000020000000000 [ 2257.819202] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7218 [ 2257.819206] iommu: Removing device 0000:82:00.0 from group 49 [ 2257.819207] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7000 [ 2257.819211] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received: [ 2257.819212] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000820000000010 [ 2257.819214] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000020000000000 [ 2257.819215] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea722c [ 2257.819216] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7000 [ 2257.819218] ================================================================== [ 2257.819228] BUG: KASAN: use-after-free in iommu_report_device_fault+0x520/0x5c0 [ 2257.819230] Read of size 8 at addr ffffa02c516c1320 by task irq/63-arm-smmu/483 [ 2257.819231] [ 2257.819235] CPU: 25 PID: 483 Comm: irq/63-arm-smmu Kdump: loaded Tainted: G OE 4.19.90-2205.3.0.0149.oe1.aarch64+debug #1 [ 2257.819236] Hardware name: Huawei S920S00/BC82AMDGK, BIOS 1.68 11/10/2020 [ 2257.819237] Call trace: [ 2257.819240] dump_backtrace+0x0/0x320 [ 2257.819242] show_stack+0x24/0x30 [ 2257.819246] dump_stack+0xdc/0x128 [ 2257.819251] print_address_description+0x68/0x278 [ 2257.819253] kasan_report+0x1e4/0x308 [ 2257.819254] __asan_report_load8_noabort+0x30/0x40 [ 2257.819257] iommu_report_device_fault+0x520/0x5c0 [ 2257.819260] arm_smmu_handle_evt+0x300/0x428 [ 2257.819261] arm_smmu_evtq_thread+0x27c/0x460 [ 2257.819264] irq_thread_fn+0x88/0x140 [ 2257.819266] irq_thread+0x190/0x318 [ 2257.819268] kthread+0x2a4/0x320 [ 2257.819270] ret_from_fork+0x10/0x18 [ 2257.819271] [ 2257.819273] Allocated by task 95166: [ 2257.819275] kasan_kmalloc+0xd0/0x178 [ 2257.819277] kmem_cache_alloc_trace+0x100/0x210 [ 2257.819279] iommu_group_add_device+0x254/0xe18 [ 2257.819280] iommu_group_get_for_dev+0x198/0x480 [ 2257.819282] arm_smmu_add_device+0x424/0x988 [ 2257.819284] iort_iommu_configure+0x33c/0x5b8 [ 2257.819287] acpi_dma_configure+0x9c/0xf8 [ 2257.819289] pci_dma_configure+0x124/0x158 [ 2257.819291] dma_configure+0x5c/0x80 [ 2257.819294] really_probe+0xcc/0x920 [ 2257.819296] driver_probe_device+0x224/0x308 [ 2257.819298] __device_attach_driver+0x154/0x260 [ 2257.819299] bus_for_each_drv+0xe4/0x178 [ 2257.819301] __device_attach+0x1bc/0x2a8 [ 2257.819302] device_attach+0x24/0x30 [ 2257.819304] pci_bus_add_device+0x7c/0xe8 [ 2257.819305] pci_bus_add_devices+0x70/0x168 [ 2257.819307] pci_bus_add_devices+0x114/0x168 [ 2257.819308] pci_rescan_bus+0x38/0x48 [ 2257.819310] bus_rescan_store+0xc4/0xe8 [ 2257.819312] bus_attr_store+0x70/0x98 [ 2257.819314] sysfs_kf_write+0x104/0x170 [ 2257.819316] kernfs_fop_write+0x23c/0x430 [ 2257.819319] __vfs_write+0x7c/0xe8 [ 2257.819320] vfs_write+0x12c/0x3d0 [ 2257.819321] ksys_write+0xd4/0x1d8 [ 2257.819322] __arm64_sys_write+0x70/0xa0 [ 2257.819325] el0_svc_common+0xfc/0x278 [ 2257.819327] el0_svc_handler+0x50/0xc0 [ 2257.819329] el0_svc+0x8/0x1b0 [ 2257.819329] [ 2257.819330] Freed by task 95166: [ 2257.819332] __kasan_slab_free+0x114/0x200 [ 2257.819334] kasan_slab_free+0x10/0x18 [ 2257.819335] kfree+0x80/0x1f0 [ 2257.819337] iommu_group_remove_device+0x27c/0x560 [ 2257.819338] arm_smmu_remove_device+0xe8/0x190 [ 2257.819339] iommu_bus_notifier+0x134/0x248 [ 2257.819342] notifier_call_chain+0xb0/0x140 [ 2257.819343] blocking_notifier_call_chain+0x6c/0xd8 [ 2257.819344] device_del+0x578/0x940 [ 2257.819346] pci_remove_bus_device+0x114/0x290 [ 2257.819347] pci_stop_and_remove_bus_device_locked+0x2c/0x40 [ 2257.819349] remove_store+0xdc/0xe8 [ 2257.819352] dev_attr_store+0x60/0x80 [ 2257.819353] sysfs_kf_write+0x104/0x170 [ 2257.819354] kernfs_fop_write+0x23c/0x430 [ 2257.819355] __vfs_write+0x7c/0xe8 [ 2257.819357] vfs_write+0x12c/0x3d0 [ 2257.819358] ksys_write+0xd4/0x1d8 [ 2257.819359] __arm64_sys_write+0x70/0xa0 [ 2257.819361] el0_svc_common+0xfc/0x278 [ 2257.819362] el0_svc_handler+0x50/0xc0 [ 2257.819364] el0_svc+0x8/0x1b0 [ 2257.819364] T0 T1 --------------------------------- --------------------------------- |- arm_smmu_evtq_thread |- arm_smmu_remove_device |- arm_smmu_handle_evt |- iommu_group_remove_device |- kfree(dev->iommu_param) |- arm_smmu_find_master |- iommu_report_device_fault |- arm_smmu_remove_master |- mutex_lock( \ &dev->iommu_param->lock) // UAF Reference upstream mainline commit 395ad89d, move arm_smmu_remove_master() before iommu_group_remove_device(), and hold mutex to protect finding master and subsequent handling. ``` Link:https://gitee.com/openeuler/kernel/pulls/595 Reviewed-by: Weilong Chen <chenweilong@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
- 19 4月, 2023 2 次提交
-
-
由 YueHaibing 提交于
mainline inclusion from mainline-v6.3-rc7 commit dc5110c2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6WB6P CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dc5110c2d959c1707e12df5f792f41d90614adaa ---------------------------------------- UBSAN: shift-out-of-bounds in net/ipv4/tcp_input.c:555:23 shift exponent 255 is too large for 32-bit type 'int' CPU: 1 PID: 7907 Comm: ssh Not tainted 6.3.0-rc4-00161-g62bad54b-dirty #206 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x136/0x150 __ubsan_handle_shift_out_of_bounds+0x21f/0x5a0 tcp_init_transfer.cold+0x3a/0xb9 tcp_finish_connect+0x1d0/0x620 tcp_rcv_state_process+0xd78/0x4d60 tcp_v4_do_rcv+0x33d/0x9d0 __release_sock+0x133/0x3b0 release_sock+0x58/0x1b0 'maxwin' is int, shifting int for 32 or more bits is undefined behaviour. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Reviewed-by: NEric Dumazet <edumazet@google.com> Reviewed-by: NKuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Reviewed-by: NLiu Jian <liujian56@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 KP Singh 提交于
stable inclusion from stable-v4.19.276 commit 10543fb3c9b019e45e2045f08f46fdf526add593 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6V7TU CVE: CVE-2023-1998 -------------------------------- commit 6921ed90 upstream. When plain IBRS is enabled (not enhanced IBRS), the logic in spectre_v2_user_select_mitigation() determines that STIBP is not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit is cleared on returning to userspace for performance reasons which leaves userspace threads vulnerable to cross-thread branch target injection against which STIBP protects. Exclude IBRS from the spectre_v2_in_ibrs_mode() check to allow for enabling STIBP (through seccomp/prctl() by default or always-on, if selected by spectre_v2_user kernel cmdline parameter). [ bp: Massage. ] Fixes: 7c693f54 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS") Reported-by: NJosé Oliveira <joseloliveira11@gmail.com> Reported-by: NRodrigo Branco <rodrigo@kernelhacking.com> Signed-off-by: NKP Singh <kpsingh@kernel.org> Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230220120127.1975241-1-kpsingh@kernel.org Link: https://lore.kernel.org/r/20230221184908.2349578-1-kpsingh@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NWei Li <liwei391@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 18 4月, 2023 9 次提交
-
-
由 Paolo Bonzini 提交于
stable inclusion from stable-v5.10.176 commit c54974ccaff73525462e278602dfe4069877cfaa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6U7AN CVE: CVE-2023-30456 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c54974ccaff73525462e278602dfe4069877cfaa -------------------------------- commit 112e6601 upstream. The effective values of the guest CR0 and CR4 registers may differ from those included in the VMCS12. In particular, disabling EPT forces CR4.PAE=1 and disabling unrestricted guest mode forces CR0.PG=CR0.PE=1. Therefore, checks on these bits cannot be delegated to the processor and must be performed by KVM. Reported-by: NReima ISHII <ishiir@g.ecc.u-tokyo.ac.jp> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> conflicts: arch/x86/kvm/vmx.c Signed-off-by: NLin Yujun <linyujun809@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zack Rusin 提交于
stable inclusion from stable-v4.19.270 commit 6b4e70a428b5a11f56db94047b68e144529fe512 category: bugfix bugzilla: 188685, https://gitee.com/src-openeuler/kernel/issues/I5QLC4 CVE：CVE-2022-36280 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6b4e70a428b5a11f56db94047b68e144529fe512 -------------------------------- commit 4cf949c7 upstream. Invalid userspace dma surface copies could potentially overflow the memcpy from the surface to the snooped image leading to crashes. To fix it the dimensions of the copybox have to be validated against the expected size of the snooped cursor. Signed-off-by: NZack Rusin <zackr@vmware.com> Fixes: 2ac86371 ("vmwgfx: Snoop DMA transfers with non-covering sizes") Cc: <stable@vger.kernel.org> # v3.2+ Reviewed-by: NMichael Banack <banackm@vmware.com> Reviewed-by: NMartin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-1-zack@kde.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYuyao Lin <linyuyao1@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Jamal Hadi Salim 提交于
stable inclusion from stable-v4.19.276 commit 01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6UYBU CVE: CVE-2023-1829 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b -------------------------------- commit 8c710f75 upstream. The tcindex classifier has served us well for about a quarter of a century but has not been getting much TLC due to lack of known users. Most recently it has become easy prey to syzkaller. For this reason, we are retiring it. Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com> Acked-by: NJiri Pirko <jiri@nvidia.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Paolo Bonzini 提交于
mainline inclusion from mainline-v6.2 commit 971cecb9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C CVE: CVE-2022-27672 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=971cecb9591a7b8ceae658252bf15240d7078a45 -------------------------------- The following warning: Documentation/admin-guide/hw-vuln/cross-thread-rsb.rst:92: ERROR: Unexpected indentation. was introduced by commit 493a2c2d. Fix it by placing everything in the same paragraph and also use a monospace font. Fixes: 493a2c2d ("Documentation/hw-vuln: Add documentation for Cross-Thread Return Predictions") Reported-by: Stephen Rothwell <sfr@canb@auug.org.au> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Tom Lendacky 提交于
stable inclusion from stable-v5.15.94 commit 17170acdc7c8b8585501bb443b4f196168ae9890 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C CVE: CVE-2022-27672 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=17170acdc7c8b8585501bb443b4f196168ae9890 -------------------------------- commit 493a2c2d upstream. Add the admin guide for the Cross-Thread Return Predictions vulnerability. Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Message-Id: <60f9c0b4396956ce70499ae180cb548720b25c7e.1675956146.git.thomas.lendacky@amd.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Tom Lendacky 提交于
stable inclusion from stable-v5.15.94 commit 5122e0e44363e3d837592b78bc04222b9d289868 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C CVE: CVE-2022-27672 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5122e0e44363e3d837592b78bc04222b9d289868 -------------------------------- commit 6f0f2d5e upstream. By default, KVM/SVM will intercept attempts by the guest to transition out of C0. However, the KVM_CAP_X86_DISABLE_EXITS capability can be used by a VMM to change this behavior. To mitigate the cross-thread return address predictions bug (X86_BUG_SMT_RSB), a VMM must not be allowed to override the default behavior to intercept C0 transitions. Use a module parameter to control the mitigation on processors that are vulnerable to X86_BUG_SMT_RSB. If the processor is vulnerable to the X86_BUG_SMT_RSB bug and the module parameter is set to mitigate the bug, KVM will not allow the disabling of the HLT, MWAIT and CSTATE exits. Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Message-Id: <4019348b5e07148eb4d593380a5f6713b93c9a16.1675956146.git.thomas.lendacky@amd.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Tom Lendacky 提交于
stable inclusion from stable-v5.15.94 commit 8f12dcab90e886d0169a9cd372a8bb35339cfc19 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C CVE: CVE-2022-27672 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8f12dcab90e886d0169a9cd372a8bb35339cfc19 -------------------------------- commit be8de49b upstream. Certain AMD processors are vulnerable to a cross-thread return address predictions bug. When running in SMT mode and one of the sibling threads transitions out of C0 state, the other sibling thread could use return target predictions from the sibling thread that transitioned out of C0. The Spectre v2 mitigations cover the Linux kernel, as it fills the RSB when context switching to the idle thread. However, KVM allows a VMM to prevent exiting guest mode when transitioning out of C0. A guest could act maliciously in this situation, so create a new x86 BUG that can be used to detect if the processor is vulnerable. Reviewed-by: NBorislav Petkov (AMD) <bp@alien8.de> Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Message-Id: <91cec885656ca1fcd4f0185ce403a53dd9edecb7.1675956146.git.thomas.lendacky@amd.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Vitaly Kuznetsov 提交于
mainline inclusion from mainline-v5.4 commit e1572f1d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C CVE: CVE-2022-27672 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.3-rc1&id=e1572f1d08be57a5412a464cff0712a23cd0b73e -------------------------------- KVM needs to know if SMT is theoretically possible, this means it is supported and not forcefully disabled ('nosmt=force'). Create and export cpu_smt_possible() answering this question. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Ding Hui 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKM7 CVE: NA -------- A use-after-free issue like following: [ 2257.819189] arm-smmu-v3 arm-smmu-v3.4.auto: EVTQ overflow detected -- events lost [ 2257.819197] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received: [ 2257.819199] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000820000000010 [ 2257.819201] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000020000000000 [ 2257.819202] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7218 [ 2257.819206] iommu: Removing device 0000:82:00.0 from group 49 [ 2257.819207] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7000 [ 2257.819211] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received: [ 2257.819212] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000820000000010 [ 2257.819214] arm-smmu-v3 arm-smmu-v3.4.auto: 0x0000020000000000 [ 2257.819215] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea722c [ 2257.819216] arm-smmu-v3 arm-smmu-v3.4.auto: 0x00000000dfea7000 [ 2257.819218] ================================================================== [ 2257.819228] BUG: KASAN: use-after-free in iommu_report_device_fault+0x520/0x5c0 [ 2257.819230] Read of size 8 at addr ffffa02c516c1320 by task irq/63-arm-smmu/483 [ 2257.819231] [ 2257.819235] CPU: 25 PID: 483 Comm: irq/63-arm-smmu Kdump: loaded Tainted: G OE 4.19.90-2205.3.0.0149.oe1.aarch64+debug #1 [ 2257.819236] Hardware name: Huawei S920S00/BC82AMDGK, BIOS 1.68 11/10/2020 [ 2257.819237] Call trace: [ 2257.819240] dump_backtrace+0x0/0x320 [ 2257.819242] show_stack+0x24/0x30 [ 2257.819246] dump_stack+0xdc/0x128 [ 2257.819251] print_address_description+0x68/0x278 [ 2257.819253] kasan_report+0x1e4/0x308 [ 2257.819254] __asan_report_load8_noabort+0x30/0x40 [ 2257.819257] iommu_report_device_fault+0x520/0x5c0 [ 2257.819260] arm_smmu_handle_evt+0x300/0x428 [ 2257.819261] arm_smmu_evtq_thread+0x27c/0x460 [ 2257.819264] irq_thread_fn+0x88/0x140 [ 2257.819266] irq_thread+0x190/0x318 [ 2257.819268] kthread+0x2a4/0x320 [ 2257.819270] ret_from_fork+0x10/0x18 [ 2257.819271] [ 2257.819273] Allocated by task 95166: [ 2257.819275] kasan_kmalloc+0xd0/0x178 [ 2257.819277] kmem_cache_alloc_trace+0x100/0x210 [ 2257.819279] iommu_group_add_device+0x254/0xe18 [ 2257.819280] iommu_group_get_for_dev+0x198/0x480 [ 2257.819282] arm_smmu_add_device+0x424/0x988 [ 2257.819284] iort_iommu_configure+0x33c/0x5b8 [ 2257.819287] acpi_dma_configure+0x9c/0xf8 [ 2257.819289] pci_dma_configure+0x124/0x158 [ 2257.819291] dma_configure+0x5c/0x80 [ 2257.819294] really_probe+0xcc/0x920 [ 2257.819296] driver_probe_device+0x224/0x308 [ 2257.819298] __device_attach_driver+0x154/0x260 [ 2257.819299] bus_for_each_drv+0xe4/0x178 [ 2257.819301] __device_attach+0x1bc/0x2a8 [ 2257.819302] device_attach+0x24/0x30 [ 2257.819304] pci_bus_add_device+0x7c/0xe8 [ 2257.819305] pci_bus_add_devices+0x70/0x168 [ 2257.819307] pci_bus_add_devices+0x114/0x168 [ 2257.819308] pci_rescan_bus+0x38/0x48 [ 2257.819310] bus_rescan_store+0xc4/0xe8 [ 2257.819312] bus_attr_store+0x70/0x98 [ 2257.819314] sysfs_kf_write+0x104/0x170 [ 2257.819316] kernfs_fop_write+0x23c/0x430 [ 2257.819319] __vfs_write+0x7c/0xe8 [ 2257.819320] vfs_write+0x12c/0x3d0 [ 2257.819321] ksys_write+0xd4/0x1d8 [ 2257.819322] __arm64_sys_write+0x70/0xa0 [ 2257.819325] el0_svc_common+0xfc/0x278 [ 2257.819327] el0_svc_handler+0x50/0xc0 [ 2257.819329] el0_svc+0x8/0x1b0 [ 2257.819329] [ 2257.819330] Freed by task 95166: [ 2257.819332] __kasan_slab_free+0x114/0x200 [ 2257.819334] kasan_slab_free+0x10/0x18 [ 2257.819335] kfree+0x80/0x1f0 [ 2257.819337] iommu_group_remove_device+0x27c/0x560 [ 2257.819338] arm_smmu_remove_device+0xe8/0x190 [ 2257.819339] iommu_bus_notifier+0x134/0x248 [ 2257.819342] notifier_call_chain+0xb0/0x140 [ 2257.819343] blocking_notifier_call_chain+0x6c/0xd8 [ 2257.819344] device_del+0x578/0x940 [ 2257.819346] pci_remove_bus_device+0x114/0x290 [ 2257.819347] pci_stop_and_remove_bus_device_locked+0x2c/0x40 [ 2257.819349] remove_store+0xdc/0xe8 [ 2257.819352] dev_attr_store+0x60/0x80 [ 2257.819353] sysfs_kf_write+0x104/0x170 [ 2257.819354] kernfs_fop_write+0x23c/0x430 [ 2257.819355] __vfs_write+0x7c/0xe8 [ 2257.819357] vfs_write+0x12c/0x3d0 [ 2257.819358] ksys_write+0xd4/0x1d8 [ 2257.819359] __arm64_sys_write+0x70/0xa0 [ 2257.819361] el0_svc_common+0xfc/0x278 [ 2257.819362] el0_svc_handler+0x50/0xc0 [ 2257.819364] el0_svc+0x8/0x1b0 [ 2257.819364] T0 T1 --------------------------------- --------------------------------- |- arm_smmu_evtq_thread |- arm_smmu_remove_device |- arm_smmu_handle_evt |- iommu_group_remove_device |- kfree(dev->iommu_param) |- arm_smmu_find_master |- iommu_report_device_fault |- arm_smmu_remove_master |- mutex_lock( \ &dev->iommu_param->lock) // UAF Reference upstream mainline commit 395ad89d, move arm_smmu_remove_master() before iommu_group_remove_device(), and hold mutex to protect finding master and subsequent handling. Fixes: b525f0a6 ("iommu/arm-smmu-v3: Add stall support for platform devices") Signed-off-by: NDing Hui <dinghui@sangfor.com.cn>
-
- 17 4月, 2023 2 次提交
-
-
由 Zheng Wang 提交于
mainline inclusion from mainline-v6.3-rc3 commit 5000fe6c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6UW64 CVE: CVE-2023-1990 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=5000fe6c2782 -------------------------------- This bug influences both st_nci_i2c_remove and st_nci_spi_remove. Take st_nci_i2c_remove as an example. In st_nci_i2c_probe, it called ndlc_probe and bound &ndlc->sm_work with llt_ndlc_sm_work. When it calls ndlc_recv or timeout handler, it will finally call schedule_work to start the work. When we call st_nci_i2c_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in ndlc_remove CPU0 CPU1 |llt_ndlc_sm_work st_nci_i2c_remove | ndlc_remove | st_nci_remove | nci_free_device| kfree(ndev) | //free ndlc->ndev | |llt_ndlc_rcv_queue |nci_recv_frame |//use ndlc->ndev Fixes: 35630df6 ("NFC: st21nfcb: Add driver for STMicroelectronics ST21NFCB NFC chip") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Reviewed-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230312160837.2040857-1-zyytlz.wz@163.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NWei Li <liwei391@huawei.com> Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zheng Wang 提交于
mainline inclusion from mainline-v6.3-rc7 commit 73f7b171 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6UW68 CVE: CVE-2023-1989 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73f7b171b7c09139eb3c6a5677c200dc1be5f318 --------------------------- In btsdio_probe, the data->work is bound with btsdio_work. It will be started in btsdio_send_frame. If the btsdio_remove runs with a unfinished work, there may be a race condition that hdev is freed but used in btsdio_work. Fix it by canceling the work before do cleanup in btsdio_remove. Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: NLiu Jian <liujian56@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 11 4月, 2023 1 次提交
-
-
由 Zheng Wang 提交于
mainline inclusion from mainline-v6.3-rc3 commit cb090e64 category: bugfix bugzilla: 188657, https://gitee.com/src-openeuler/kernel/issues/I6T36A CVE: CVE-2023-1855 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb090e64cf25602b9adaf32d5dfc9c8bec493cd1 -------------------------------- In xgene_hwmon_probe, &ctx->workq is bound with xgene_hwmon_evt_work. Then it will be started. If we remove the driver which will call xgene_hwmon_remove to clean up, there may be unfinished work. The possible sequence is as follows: Fix it by finishing the work before cleanup in xgene_hwmon_remove. CPU0 CPU1 |xgene_hwmon_evt_work xgene_hwmon_remove | kfifo_free(&ctx->async_msg_fifo);| | |kfifo_out_spinlocked |//use &ctx->async_msg_fifo Fixes: 2ca492e2 ("hwmon: (xgene) Fix crash when alarm occurs before driver probe") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Link: https://lore.kernel.org/r/20230310084007.1403388-1-zyytlz.wz@163.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com> Reviewed-by: Nsongping yu <yusongping@huawei.com> Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 10 4月, 2023 2 次提交
-
-
由 Zheng Wang 提交于
stable inclusion from stable-v4.19.279 commit 526660c25d3b93b1232a525b75469048388f0928 category: bugfix bugzilla: 188641, https://gitee.com/src-openeuler/kernel/issues/I6R4MM CVE: CVE-2023-1670 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=526660c25d3b93b1232a525b75469048388f0928 -------------------------------- [ Upstream commit e8d20c3d ] In xirc2ps_probe, the local->tx_timeout_task was bounded with xirc2ps_tx_timeout_task. When timeout occurs, it will call xirc_tx_timeout->schedule_work to start the work. When we call xirc2ps_detach to remove the driver, there may be a sequence as follows: Stop responding to timeout tasks and complete scheduled tasks before cleanup in xirc2ps_detach, which will fix the problem. CPU0 CPU1 |xirc2ps_tx_timeout_task xirc2ps_detach | free_netdev | kfree(dev); | | | do_reset | //use dev Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com> Reviewed-by: NLiu Jian <liujian56@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zheng Wang 提交于
maillist inclusion category: bugfix bugzilla: 188655, https://gitee.com/src-openeuler/kernel/issues/I6T36H CVE: CVE-2023-1859 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ea4f1009408efb4989a0f139b70fb338e7f687d0 ---------------------------------------- In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring to init priv->rings and bound &ring->work with p9_xen_response. When it calls xen_9pfs_front_event_handler to handle IRQ requests, it will finally call schedule_work to start the work. When we call xen_9pfs_front_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in xen_9pfs_front_free. Note that, this bug is found by static analysis, which might be false positive. CPU0 CPU1 |p9_xen_response xen_9pfs_front_remove| xen_9pfs_front_free| kfree(priv) | //free priv | |p9_tag_lookup |//use priv->client Fixes: 71ebd719 ("xen/9pfs: connect to the backend") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Reviewed-by: NMichal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by: NEric Van Hensbergen <ericvh@kernel.org> Signed-off-by: NLu Wei <luwei32@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 08 4月, 2023 18 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @LiuYongQiang0816 20 bugfixes from linux-4.19.y Link:https://gitee.com/openeuler/kernel/pulls/566 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Linus Torvalds 提交于
stable inclusion from stable-v4.19.274 commit c7603df97635954165fb599e64e197efc353979b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit f3dd0c53 upstream. Commit 74e19ef0 ("uaccess: Add speculation barrier to copy_from_user()") built fine on x86-64 and arm64, and that's the extent of my local build testing. It turns out those got the <linux/nospec.h> include incidentally through other header files (<linux/kvm_host.h> in particular), but that was not true of other architectures, resulting in build errors kernel/bpf/core.c: In function ‘___bpf_prog_run’: kernel/bpf/core.c:1913:3: error: implicit declaration of function ‘barrier_nospec’ so just make sure to explicitly include the proper <linux/nospec.h> header file to make everybody see it. Fixes: 74e19ef0 ("uaccess: Add speculation barrier to copy_from_user()") Reported-by: Nkernel test robot <lkp@intel.com> Reported-by: NViresh Kumar <viresh.kumar@linaro.org> Reported-by: NHuacai Chen <chenhuacai@loongson.cn> Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org> Tested-by: NDave Hansen <dave.hansen@linux.intel.com> Acked-by: NAlexei Starovoitov <alexei.starovoitov@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Dave Hansen 提交于
stable inclusion from stable-v4.19.274 commit f8e54da1c729cc23d9a7b7bd42379323e7fb7979 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit 74e19ef0 upstream. The results of "access_ok()" can be mis-speculated. The result is that you can end speculatively: if (access_ok(from, size)) // Right here even for bad from/size combinations. On first glance, it would be ideal to just add a speculation barrier to "access_ok()" so that its results can never be mis-speculated. But there are lots of system calls just doing access_ok() via "copy_to_user()" and friends (example: fstat() and friends). Those are generally not problematic because they do not _consume_ data from userspace other than the pointer. They are also very quick and common system calls that should not be needlessly slowed down. "copy_from_user()" on the other hand uses a user-controller pointer and is frequently followed up with code that might affect caches. Take something like this: if (!copy_from_user(&kernelvar, uptr, size)) do_something_with(kernelvar); If userspace passes in an evil 'uptr' that *actually* points to a kernel addresses, and then do_something_with() has cache (or other) side-effects, it could allow userspace to infer kernel data values. Add a barrier to the common copy_from_user() code to prevent mis-speculated values which happen after the copy. Also add a stub for architectures that do not define barrier_nospec(). This makes the macro usable in generic code. Since the barrier is now usable in generic code, the x86 #ifdef in the BPF code can also go away. Reported-by: NJordy Zomer <jordyzomer@google.com> Suggested-by: NLinus Torvalds <torvalds@linuxfoundation.org> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: Daniel Borkmann <daniel@iogearbox.net> # BPF bits Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: lib/usercopy.c Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com> Reviewed-by: NNanyong Sun <sunnanyong@huawei.com> Reviewed-by: Ntong tiangen <tongtiangen@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Jason A. Donenfeld 提交于
stable inclusion from stable-v4.19.274 commit e4935368448ce8097dada35163598e93567f1110 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e4935368448ce8097dada35163598e93567f1110 -------------------------------- [ Upstream commit d7bf7f3b ] add_latent_entropy() is called every time a process forks, in kernel_clone(). This in turn calls add_device_randomness() using the latent entropy global state. add_device_randomness() does two things: 2) Mixes into the input pool the latent entropy argument passed; and 1) Mixes in a cycle counter, a sort of measurement of when the event took place, the high precision bits of which are presumably difficult to predict. (2) is impossible without CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y. But (1) is always possible. However, currently CONFIG_GCC_PLUGIN_LATENT_ENTROPY=n disables both (1) and (2), instead of just (2). This commit causes the CONFIG_GCC_PLUGIN_LATENT_ENTROPY=n case to still do (1) by passing NULL (len 0) to add_device_randomness() when add_latent_ entropy() is called. Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: PaX Team <pageexec@freemail.hu> Cc: Emese Revfy <re.emese@gmail.com> Fixes: 38addce8 ("gcc-plugins: Add latent_entropy plugin") Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Conflicts: include/linux/random.h Signed-off-by: NCui GaoSheng <cuigaosheng1@huawei.com> Reviewed-by: Nyiyang <yiyang13@huawei.com> Reviewed-by: Nguozihua <guozihua@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Nikita Zhandarovich 提交于
stable inclusion from stable-v4.19.279 commit ffdf8d81c48822a329af9f31dc239090f4a60761 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit cbebd68f upstream. cmdline_find_option() may fail before doing any initialization of the buffer array. This may lead to unpredictable results when the same buffer is used later in calls to strncmp() function. Fix the issue by returning early if cmdline_find_option() returns an error. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: aca20d54 ("x86/mm: Add support to make use of Secure Memory Encryption") Signed-off-by: NNikita Zhandarovich <n.zhandarovich@fintech.ru> Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de> Acked-by: NTom Lendacky <thomas.lendacky@amd.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/20230306160656.14844-1-n.zhandarovich@fintech.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Baokun Li 提交于
stable inclusion from stable-v4.19.279 commit 3aea195acd977e82d970cbc7078f983880c7ee6a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- [ Upstream commit 5cd74028 ] In ext4_fill_super(), EXT4_ORPHAN_FS flag is cleared after ext4_orphan_cleanup() is executed. Therefore, when __ext4_iget() is called to get an inode whose i_nlink is 0 when the flag exists, no error is returned. If the inode is a special inode, a null pointer dereference may occur. If the value of i_nlink is 0 for any inodes (except boot loader inodes) got by using the EXT4_IGET_SPECIAL flag, the current file system is corrupted. Therefore, make the ext4_iget() function return an error if it gets such an abnormal special inode. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199179 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216541 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216539Reported-by: NLuís Henriques <lhenriques@suse.de> Suggested-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NBaokun Li <libaokun1@huawei.com> Reviewed-by: NJan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230107032126.4165860-2-libaokun1@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zhihao Cheng 提交于
stable inclusion from stable-v4.19.278 commit 59eee0cdf8c036f554add97a4da7c06d7a9ff34a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit f5361da1 upstream. If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024); Fix this by setting i_disksize as well as i_size to zero when initiaizing the boot loader inode. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159 Cc: stable@kernel.org Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-v4.19.276 commit 525eb5cb8edfb7014711c2c87827ed17af8872fb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit e3b7ab02 upstream. In case a newly allocated IRQ ever ends up not having any associated struct irq_data it would not even be possible to dispose the mapping. Replace the bogus disposal with a WARN_ON(). This will also be used to fix a shared-interrupt mapping race, hence the CC-stable tag. Fixes: 1e2a7d78 ("irqdomain: Don't set type when mapping an IRQ") Cc: stable@vger.kernel.org # 4.8 Tested-by: NHsin-Yi Wang <hsinyi@chromium.org> Tested-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com> Signed-off-by: NJohan Hovold <johan+linaro@kernel.org> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230213104302.17307-4-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-v4.19.276 commit 1b9fe6e4930155f1083a4dc32d3a47b1c4e8f55c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit 3f883c38 upstream. The global irq_domain_mutex is held when mapping interrupts from non-hierarchical domains but currently not when disposing them. This specifically means that updates of the domain mapcount is racy (currently only used for statistics in debugfs). Make sure to hold the global irq_domain_mutex also when disposing mappings from non-hierarchical domains. Fixes: 9dc6be3d ("genirq/irqdomain: Add map counter") Cc: stable@vger.kernel.org # 4.13 Tested-by: NHsin-Yi Wang <hsinyi@chromium.org> Tested-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com> Signed-off-by: NJohan Hovold <johan+linaro@kernel.org> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230213104302.17307-3-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Johan Hovold 提交于
stable inclusion from stable-v4.19.276 commit 2dcccf91bc4e9937dccf86c9b1f5026ffd72a80b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit b06730a5 upstream. The sanity check for an already mapped virq is done outside of the irq_domain_mutex-protected section which means that an (unlikely) racing association may not be detected. Fix this by factoring out the association implementation, which will also be used in a follow-on change to fix a shared-interrupt mapping race. Fixes: ddaf144c ("irqdomain: Refactor irq_domain_associate_many()") Cc: stable@vger.kernel.org # 3.11 Tested-by: NHsin-Yi Wang <hsinyi@chromium.org> Tested-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com> Signed-off-by: NJohan Hovold <johan+linaro@kernel.org> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230213104302.17307-2-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Yang Jihong 提交于
stable inclusion from stable-v4.19.276 commit add105f090a6ad3af1caaf1d81f896208cfc7afb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit f1c97a1b upstream. When arch_prepare_optimized_kprobe calculating jump destination address, it copies original instructions from jmp-optimized kprobe (see __recover_optprobed_insn), and calculated based on length of original instruction. arch_check_optimized_kprobe does not check KPROBE_FLAG_OPTIMATED when checking whether jmp-optimized kprobe exists. As a result, setup_detour_execution may jump to a range that has been overwritten by jump destination address, resulting in an inval opcode error. For example, assume that register two kprobes whose addresses are <func+9> and <func+11> in "func" function. The original code of "func" function is as follows: 0xffffffff816cb5e9 <+9>: push %r12 0xffffffff816cb5eb <+11>: xor %r12d,%r12d 0xffffffff816cb5ee <+14>: test %rdi,%rdi 0xffffffff816cb5f1 <+17>: setne %r12b 0xffffffff816cb5f5 <+21>: push %rbp 1.Register the kprobe for <func+11>, assume that is kp1, corresponding optimized_kprobe is op1. After the optimization, "func" code changes to: 0xffffffff816cc079 <+9>: push %r12 0xffffffff816cc07b <+11>: jmp 0xffffffffa0210000 0xffffffff816cc080 <+16>: incl 0xf(%rcx) 0xffffffff816cc083 <+19>: xchg %eax,%ebp 0xffffffff816cc084 <+20>: (bad) 0xffffffff816cc085 <+21>: push %rbp Now op1->flags == KPROBE_FLAG_OPTIMATED; 2. Register the kprobe for <func+9>, assume that is kp2, corresponding optimized_kprobe is op2. register_kprobe(kp2) register_aggr_kprobe alloc_aggr_kprobe __prepare_optimized_kprobe arch_prepare_optimized_kprobe __recover_optprobed_insn // copy original bytes from kp1->optinsn.copied_insn, // jump address = <func+14> 3. disable kp1: disable_kprobe(kp1) __disable_kprobe ... if (p == orig_p || aggr_kprobe_disabled(orig_p)) { ret = disarm_kprobe(orig_p, true) // add op1 in unoptimizing_list, not unoptimized orig_p->flags |= KPROBE_FLAG_DISABLED; // op1->flags == KPROBE_FLAG_OPTIMATED | KPROBE_FLAG_DISABLED ... 4. unregister kp2 __unregister_kprobe_top ... if (!kprobe_disabled(ap) && !kprobes_all_disarmed) { optimize_kprobe(op) ... if (arch_check_optimized_kprobe(op) < 0) // because op1 has KPROBE_FLAG_DISABLED, here not return return; p->kp.flags |= KPROBE_FLAG_OPTIMIZED; // now op2 has KPROBE_FLAG_OPTIMIZED } "func" code now is: 0xffffffff816cc079 <+9>: int3 0xffffffff816cc07a <+10>: push %rsp 0xffffffff816cc07b <+11>: jmp 0xffffffffa0210000 0xffffffff816cc080 <+16>: incl 0xf(%rcx) 0xffffffff816cc083 <+19>: xchg %eax,%ebp 0xffffffff816cc084 <+20>: (bad) 0xffffffff816cc085 <+21>: push %rbp 5. if call "func", int3 handler call setup_detour_execution: if (p->flags & KPROBE_FLAG_OPTIMIZED) { ... regs->ip = (unsigned long)op->optinsn.insn + TMPL_END_IDX; ... } The code for the destination address is 0xffffffffa021072c: push %r12 0xffffffffa021072e: xor %r12d,%r12d 0xffffffffa0210731: jmp 0xffffffff816cb5ee <func+14> However, <func+14> is not a valid start instruction address. As a result, an error occurs. Link: https://lore.kernel.org/all/20230216034247.32348-3-yangjihong1@huawei.com/ Fixes: f66c0447 ("kprobes: Set unoptimized flag after unoptimizing code") Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Cc: stable@vger.kernel.org Acked-by: NMasami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: NMasami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Yang Jihong 提交于
stable inclusion from stable-v4.19.276 commit 4334c26f53585a45455af324c08a4b0036bfaa8d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- commit 868a6fc0 upstream. Since the following commit: commit f66c0447 ("kprobes: Set unoptimized flag after unoptimizing code") modified the update timing of the KPROBE_FLAG_OPTIMIZED, a optimized_kprobe may be in the optimizing or unoptimizing state when op.kp->flags has KPROBE_FLAG_OPTIMIZED and op->list is not empty. The __recover_optprobed_insn check logic is incorrect, a kprobe in the unoptimizing state may be incorrectly determined as unoptimizing. As a result, incorrect instructions are copied. The optprobe_queued_unopt function needs to be exported for invoking in arch directory. Link: https://lore.kernel.org/all/20230216034247.32348-2-yangjihong1@huawei.com/ Fixes: f66c0447 ("kprobes: Set unoptimized flag after unoptimizing code") Cc: stable@vger.kernel.org Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Acked-by: NMasami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: NMasami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Breno Leitao 提交于
stable inclusion from stable-v4.19.276 commit ca582161f5900991e26240e17f30740a8f3b9f2b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- [ Upstream commit 0125acda ] Currently, x86_spec_ctrl_base is read at boot time and speculative bits are set if Kconfig items are enabled. For example, IBRS is enabled if CONFIG_CPU_IBRS_ENTRY is configured, etc. These MSR bits are not cleared if the mitigations are disabled. This is a problem when kexec-ing a kernel that has the mitigation disabled from a kernel that has the mitigation enabled. In this case, the MSR bits are not cleared during the new kernel boot. As a result, this might have some performance degradation that is hard to pinpoint. This problem does not happen if the machine is (hard) rebooted because the bit will be cleared by default. [ bp: Massage. ] Suggested-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: NBreno Leitao <leitao@debian.org> Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20221128153148.1129350-1-leitao@debian.orgSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Jann Horn 提交于
stable inclusion from stable-v4.19.276 commit 003e49fab13d0de9cda625489c402e5d18012a8b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- [ Upstream commit 9f76d591 ] The nanosleep syscalls use the restart_block mechanism, with a quirk: The `type` and `rmtp`/`compat_rmtp` fields are set up unconditionally on syscall entry, while the rest of the restart_block is only set up in the unlikely case that the syscall is actually interrupted by a signal (or pseudo-signal) that doesn't have a signal handler. If the restart_block was set up by a previous syscall (futex(..., FUTEX_WAIT, ...) or poll()) and hasn't been invalidated somehow since then, this will clobber some of the union fields used by futex_wait_restart() and do_restart_poll(). If userspace afterwards wrongly calls the restart_syscall syscall, futex_wait_restart()/do_restart_poll() will read struct fields that have been clobbered. This doesn't actually lead to anything particularly interesting because none of the union fields contain trusted kernel data, and futex(..., FUTEX_WAIT, ...) and poll() aren't syscalls where it makes much sense to apply seccomp filters to their arguments. So the current consequences are just of the "if userspace does bad stuff, it can damage itself, and that's not a problem" flavor. But still, it seems like a hazard for future developers, so invalidate the restart_block when partly setting it up in the nanosleep syscalls. Signed-off-by: NJann Horn <jannh@google.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230105134403.754986-1-jannh@google.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Herbert Xu 提交于
stable inclusion from stable-v4.19.276 commit a023f1a938ad43642ad68f68527001e5686f5e60 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- [ Upstream commit 564cabc0 ] Use the akcipher_request_complete helper instead of calling the completion function directly. In fact the previous code was buggy in that EINPROGRESS was never passed back to the original caller. Fixes: 3d5b1ecd ("crypto: rsa - RSA padding algorithm") Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Herbert Xu 提交于
stable inclusion from stable-v4.19.276 commit 1effbddaff60eeef8017c6dea1ee0ed970164d14 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- [ Upstream commit 32e62025 ] As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request. However, as the caller of seqiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free. Fixes: 0a270321 ("[CRYPTO] seqiv: Add Sequence Number IV Generator") Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Armin Wolf 提交于
stable inclusion from stable-v4.19.276 commit 6671af7f52c382963b482c6ae55f3e6ee582e0f6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- [ Upstream commit f2ac14b5 ] When encountering a string bigger than the destination buffer (32 bytes), the string is not properly NUL-terminated, causing buffer overreads later. This for example happens on the Inspiron 3505, where the battery model name is larger than 32 bytes, which leads to sysfs showing the model name together with the serial number string (which is NUL-terminated and thus prevents worse). Fix this by using strscpy() which ensures that the result is always NUL-terminated. Fixes: 106449e8 ("ACPI: Battery: Allow extract string from integer") Signed-off-by: NArmin Wolf <W_Armin@gmx.de> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Daniil Tatianin 提交于
stable inclusion from stable-v4.19.276 commit 331db828d34c37c466e4915fd50ea51415da143c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1 CVE: NA -------------------------------- [ Upstream commit ca843a4c ] Previously acpi_ns_simple_repair() would crash if expected_btypes contained any combination of ACPI_RTYPE_NONE with a different type, e.g | ACPI_RTYPE_INTEGER because of slightly incorrect logic in the !return_object branch, which wouldn't return AE_AML_NO_RETURN_VALUE for such cases. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Link: https://github.com/acpica/acpica/pull/811 Fixes: 61db45ca ("ACPICA: Restore code that repairs NULL package elements in return values.") Signed-off-by: NDaniil Tatianin <d-tatianin@yandex-team.ru> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-