- 22 8月, 2023 4 次提交
-
-
由 Cristian Ciocaltea 提交于
stable inclusion from stable-v5.10.191 commit eda9f8ffca46570acda76ad1da8cb8b8f5ccc5a3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLYY CVE: CVE-2023-20593 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eda9f8ffca46570acda76ad1da8cb8b8f5ccc5a3 -------------------------------- commit 6dbef74aeb090d6bee7d64ef3fa82ae6fa53f271 upstream. Commit 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") provided a fix for the Zen2 VZEROUPPER data corruption bug affecting a range of CPU models, but the AMD Custom APU 0405 found on SteamDeck was not listed, although it is clearly affected by the vulnerability. Add this CPU variant to the Zenbleed erratum list, in order to unconditionally enable the fallback fix until a proper microcode update is available. Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") Signed-off-by: NCristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230811203705.1699914-1-cristian.ciocaltea@collabora.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com>
-
由 Borislav Petkov (AMD) 提交于
stable inclusion from stable-v5.10.187 commit 93df00f9d48d48466ddbe01a06eaaf3311ecfb53 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLYY CVE: CVE-2023-20593 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=93df00f9d48d48466ddbe01a06eaaf3311ecfb53 -------------------------------- Upstream commit: 522b1d69219d8f083173819fde04f994aa051a98 Add a fix for the Zen2 VZEROUPPER data corruption bug where under certain circumstances executing VZEROUPPER can cause register corruption or leak data. The optimal fix is through microcode but in the case the proper microcode revision has not been applied, enable a fallback fix using a chicken bit. Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: arch/x86/include/asm/microcode_amd.h arch/x86/kernel/cpu/common.c Signed-off-by: NYu Liao <liaoyu15@huawei.com>
-
由 Borislav Petkov (AMD) 提交于
stable inclusion from stable-v5.10.187 commit 191b8f9b0e3708e8325d8d28e1005a1fbe5e3991 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLYY CVE: CVE-2023-20593 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=191b8f9b0e3708e8325d8d28e1005a1fbe5e3991 -------------------------------- Upstream commit: 8b6f687743dacce83dbb0c7cfacf88bab00f808a Avoid new and remove old forward declarations. No functional changes. Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com>
-
由 Borislav Petkov 提交于
stable inclusion from stable-v5.10.155 commit 154d744fbefcd13648ff036db2d185319afa74dc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7M5F4 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=154d744fbefcd13648ff036db2d185319afa74dc -------------------------------- commit 2632daeb upstream. DE_CFG contains the LFENCE serializing bit, restore it on resume too. This is relevant to older families due to the way how they do S3. Unify and correct naming while at it. Fixes: e4d0e84e ("x86/cpu/AMD: Make LFENCE a serializing instruction") Reported-by: NAndrew Cooper <Andrew.Cooper3@citrix.com> Reported-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Cc: <stable@kernel.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> Signed-off-by: NYu Liao <liaoyu15@huawei.com>
-
- 08 6月, 2023 2 次提交
-
-
由 Stefan Metzmacher 提交于
stable inclusion from stable-v5.10.162 commit f0a5f0dc0131c6483908601f6e4907befb609c97 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f0a5f0dc0131c6483908601f6e4907befb609c97 -------------------------------- [ Upstream commit 50b7b6f2 ] As io_threads are fully set up USER threads it's clearer to separate the code path from the KTHREAD logic. The only remaining difference to user space threads is that io_threads never return to user space again. Instead they loop within the given worker function. The fact that they never return to user space means they don't have an user space thread stack. In order to indicate that to tools like gdb we reset the stack and instruction pointers to 0. This allows gdb attach to user space processes using io-uring, which like means that they have io_threads, without printing worrying message like this: warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386 warning: Architecture rejected target-supplied description The output will be something like this: (gdb) info threads Id Target Id Frame * 1 LWP 4863 "io_uring-cp-for" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 2 LWP 4864 "iou-mgr-4863" 0x0000000000000000 in ?? () 3 LWP 4865 "iou-wrk-4863" 0x0000000000000000 in ?? () (gdb) thread 3 [Switching to thread 3 (LWP 4865)] #0 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x0 Fixes: 4727dc20 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD") Link: https://lore.kernel.org/io-uring/044d0bad-6888-a211-e1d3-159a4aeed52d@polymtl.ca/T/#m1bbf5727e3d4e839603f6ec7ed79c7eebfba6267Signed-off-by: NStefan Metzmacher <metze@samba.org> cc: Linus Torvalds <torvalds@linux-foundation.org> cc: Jens Axboe <axboe@kernel.dk> cc: Andy Lutomirski <luto@kernel.org> cc: linux-kernel@vger.kernel.org cc: io-uring@vger.kernel.org cc: x86@kernel.org Link: https://lore.kernel.org/r/20210505110310.237537-1-metze@samba.orgReviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
-
由 Jens Axboe 提交于
stable inclusion from stable-v5.10.162 commit 320c8057eceb18c5d836fcbe0ffb0035fcfe28ff category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=320c8057eceb18c5d836fcbe0ffb0035fcfe28ff -------------------------------- PF_IO_WORKER are kernel threads too, but they aren't PF_KTHREAD in the sense that we don't assign ->set_child_tid with our own structure. Just ensure that every arch sets up the PF_IO_WORKER threads like kthreads in the arch implementation of copy_thread(). Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflict: arch/s390/kernel/process.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
-
- 07 6月, 2023 3 次提交
-
-
由 Chen Zhongjin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6DK3O CVE: NA -------------------------------- check_paravirt() calls orc_find() before its implementation code. If CONFIG_DYNAMIC_FTRACE is enabled, orc_find() will be declared earlier and compiling will not fail. Otherwise it will fail for "implicit declaration of function 'orc_find'". Move declaration of orc_find() out of CONFIG_DYNAMIC_FTRACE macro to fix this. Fixes: cbb12ea4718a ("[Huawei] x86/unwind: Fix orc entry for paravirt {save,restore}_fl") Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> (cherry picked from commit 78380898)
-
由 Chen Zhongjin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6DK3O CVE: NA -------------------------------- When CONFIG_PARAVIRT_XXL is enabled, the code of {save,restore}_fl is defined as: ff 14 25 00 00 00 00 callq *0x0 which will be patched to call the xen paravirt function, or native implementation, in 'paravirt_patch_64.c': pushfq; popq %rax // for native_save_fl pushq %rdi; popfq // for native_restore_fl The orc metadata is generated with insn 'callq', so it can become inconsistent with the real insn 'push;pop'. This makes stacktrace on the 'pop' insn fail and incorrect stacktrace result can be returned. To prevent reliable stacktrace broken, check the insns when unwind pt_regs stack frame: When there are 'push;pop' combination and both insns don't change orc entry, it means the stack state is inconsistent with orc on pop. Add one slot to sp_offset for on original orc entry to get the correct orc entry. Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> (cherry picked from commit cd5fe777)
-
由 Wei Li 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7BAJ0 -------------------------------- EulerFS was introduced as a technical preview feature in the 21.09 innovation version. Considering the current discontinuation of Intel Optane hardware and immature ecosystem, it has been decided to turn it off in the 22.03 LTS version. It will continue to evolve as an innovative feature in future innovation versions. Signed-off-by: NWei Li <liwei391@huawei.com> (cherry picked from commit 42e496a1)
-
- 19 4月, 2023 1 次提交
-
-
由 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> Signed-off-by: NLin Yujun <linyujun809@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
- 18 4月, 2023 1 次提交
-
-
由 KP Singh 提交于
stable inclusion from stable-v5.10.173 commit abfed855f05863d292de2d0ebab4656791bab9c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6V7TU CVE: CVE-2023-1998 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=abfed855f05863d292de2d0ebab4656791bab9c8 -------------------------------- 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> (cherry picked from commit 811a507c)
-
- 04 4月, 2023 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
stable inclusion from stable-v5.10.169 commit 6416c2108ba54d569e4c98d3b62ac78cb12e7107 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6OOP3 CVE: CVE-2023-1513 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6416c2108ba54d569e4c98d3b62ac78cb12e7107 -------------------------------- commit 2c10b614 upstream. When calling the KVM_GET_DEBUGREGS ioctl, on some configurations, there might be some unitialized portions of the kvm_debugregs structure that could be copied to userspace. Prevent this as is done in the other kvm ioctls, by setting the whole structure to 0 before copying anything into it. Bonus is that this reduces the lines of code as the explicit flag setting and reserved space zeroing out can be removed. Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: <x86@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: stable <stable@kernel.org> Reported-by: NXingyuan Mo <hdthky0@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Message-Id: <20230214103304.3689213-1-gregkh@linuxfoundation.org> Tested-by: NXingyuan Mo <hdthky0@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.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: NJialin Zhang <zhangjialin11@huawei.com>
-
- 22 3月, 2023 1 次提交
-
-
由 Li Huafei 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6NVPT -------------------------------- Currently, arch_klp_code_modify_{prepare, post_process} is implemented only in the x86 architecture. It is used to hold the 'text_mutex' lock before entering the stop_machine and modifying the code, and to release the lock after exiting the stop_machine. klp_mem_prepare() needs to hold the 'text_mutex' lock only when saving old instruction code on x86 to ensure that it holds valid instructions. Place klp_mem_prepare() before arch_klp_code_modify_prepare() and lock the save instruction action separately to narrow the 'text_mutex' lock. Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
- 08 3月, 2023 2 次提交
-
-
由 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: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@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: Guo Mengqi <guomengqi3@huawei.com Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
- 28 2月, 2023 3 次提交
-
-
由 Rodrigo Branco 提交于
stable inclusion from stable-v5.10.163 commit 67e39c4f4cb318cfbbf8982ab016c649ed97edaf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6CU98 CVE: CVE-2023-0045 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=67e39c4f4cb318cfbbf8982ab016c649ed97edaf -------------------------------- commit a664ec91 upstream. We missed the window between the TIF flag update and the next reschedule. Signed-off-by: NRodrigo Branco <bsdaemon@google.com> Reviewed-by: NBorislav Petkov (AMD) <bp@alien8.de> Signed-off-by: NIngo Molnar <mingo@kernel.org> Cc: <stable@vger.kernel.org> Signed-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: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Jens Axboe 提交于
stable inclusion from stable-v5.10.162 commit 3c295bd2ddaecf3509458c86bf7ba610042f3609 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6BTWC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.168&id=3c295bd2ddaecf3509458c86bf7ba610042f3609 -------------------------------- [ Upstream commit 12db8b69 ] Add TIF_NOTIFY_SIGNAL handling in the generic entry code, which if set, will return true if signal_pending() is used in a wait loop. That causes an exit of the loop so that notify_signal tracehooks can be run. If the wait loop is currently inside a system call, the system call is restarted once task_work has been processed. In preparation for only having arch_do_signal() handle syscall restarts if _TIF_SIGPENDING isn't set, rename it to arch_do_signal_or_restart(). Pass in a boolean that tells the architecture specific signal handler if it should attempt to get a signal, or just process a potential syscall restart. For !CONFIG_GENERIC_ENTRY archs, add the TIF_NOTIFY_SIGNAL handling to get_signal(). This is done to minimize the needed architecture changes to support this feature. Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NOleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20201026203230.386348-3-axboe@kernel.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Conflict: include/linux/tracehook.h Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> Acked-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Jens Axboe 提交于
stable inclusion from stable-v5.10.162 commit 4b1dcf8ec9b2f11b57f1ff5dcaa1f8575c7dacb5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6BTWC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.168&id=4b1dcf8ec9b2f11b57f1ff5dcaa1f8575c7dacb5 -------------------------------- [ Upstream commit c8d5ed67 ] The generic entry code has support for TIF_NOTIFY_SIGNAL already. Just provide the TIF bit. [ tglx: Adopted to other TIF changes in x86 ] Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201026203230.386348-4-axboe@kernel.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
- 22 2月, 2023 7 次提交
-
-
由 Sean Christopherson 提交于
mainline inclusion from mainline-v6.2-rc1 commit 1cfaac24 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC CVE: CVE-2023-0597 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1cfaac2400c73378e78182a706be0f3ac8b93cd7 -------------------------------- Popuplate the shadow for the shared portion of the CPU entry area, i.e. the read-only IDT mapping, during KASAN initialization. A recent change modified KASAN to map the per-CPU areas on-demand, but forgot to keep a shadow for the common area that is shared amongst all CPUs. Map the common area in KASAN init instead of letting idt_map_in_cea() do the dirty work so that it Just Works in the unlikely event more shared data is shoved into the CPU entry area. The bug manifests as a not-present #PF when software attempts to lookup an IDT entry, e.g. when KVM is handling IRQs on Intel CPUs (KVM performs direct CALL to the IRQ handler to avoid the overhead of INTn): BUG: unable to handle page fault for address: fffffbc0000001d8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 16c03a067 P4D 16c03a067 PUD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 5 PID: 901 Comm: repro Tainted: G W 6.1.0-rc3+ #410 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kasan_check_range+0xdf/0x190 vmx_handle_exit_irqoff+0x152/0x290 [kvm_intel] vcpu_run+0x1d89/0x2bd0 [kvm] kvm_arch_vcpu_ioctl_run+0x3ce/0xa70 [kvm] kvm_vcpu_ioctl+0x349/0x900 [kvm] __x64_sys_ioctl+0xb8/0xf0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fixes: 9fd429c28073 ("x86/kasan: Map shadow for percpu pages on demand") Reported-by: syzbot+8cdd16fd5a6c0565e227@syzkaller.appspotmail.com Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20221110203504.1985010-6-seanjc@google.comSigned-off-by: NTong Tiangen <tongtiangen@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Sean Christopherson 提交于
mainline inclusion from mainline-v6.2-rc1 commit bde258d9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC CVE: CVE-2023-0597 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bde258d97409f2a45243cb393a55ea9ecfc7aba5 -------------------------------- Add helpers to dedup code for aligning shadow address up/down to page boundaries when translating an address to its shadow. No functional change intended. Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com> Link: https://lkml.kernel.org/r/20221110203504.1985010-5-seanjc@google.comSigned-off-by: NTong Tiangen <tongtiangen@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Sean Christopherson 提交于
mainline inclusion from mainline-v6.2-rc1 commit 7077d2cc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC CVE: CVE-2023-0597 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7077d2ccb94dafd00b29cc2d601c9f6891648f5b -------------------------------- Rename the CPU entry area variables in kasan_init() to shorten their names, a future fix will reference the beginning of the per-CPU portion of the CPU entry area, and shadow_cpu_entry_per_cpu_begin is a bit much. No functional change intended. Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com> Link: https://lkml.kernel.org/r/20221110203504.1985010-4-seanjc@google.comSigned-off-by: NTong Tiangen <tongtiangen@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Sean Christopherson 提交于
mainline inclusion from mainline-v6.2-rc1 commit 97650148 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC CVE: CVE-2023-0597 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97650148a15e0b30099d6175ffe278b9f55ec66a -------------------------------- Populate a KASAN shadow for the entire possible per-CPU range of the CPU entry area instead of requiring that each individual chunk map a shadow. Mapping shadows individually is error prone, e.g. the per-CPU GDT mapping was left behind, which can lead to not-present page faults during KASAN validation if the kernel performs a software lookup into the GDT. The DS buffer is also likely affected. The motivation for mapping the per-CPU areas on-demand was to avoid mapping the entire 512GiB range that's reserved for the CPU entry area, shaving a few bytes by not creating shadows for potentially unused memory was not a goal. The bug is most easily reproduced by doing a sigreturn with a garbage CS in the sigcontext, e.g. int main(void) { struct sigcontext regs; syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul); syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); memset(®s, 0, sizeof(regs)); regs.cs = 0x1d0; syscall(__NR_rt_sigreturn); return 0; } to coerce the kernel into doing a GDT lookup to compute CS.base when reading the instruction bytes on the subsequent #GP to determine whether or not the #GP is something the kernel should handle, e.g. to fixup UMIP violations or to emulate CLI/STI for IOPL=3 applications. BUG: unable to handle page fault for address: fffffbc8379ace00 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 16c03a067 P4D 16c03a067 PUD 15b990067 PMD 15b98f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 3 PID: 851 Comm: r2 Not tainted 6.1.0-rc3-next-20221103+ #432 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kasan_check_range+0xdf/0x190 Call Trace: <TASK> get_desc+0xb0/0x1d0 insn_get_seg_base+0x104/0x270 insn_fetch_from_user+0x66/0x80 fixup_umip_exception+0xb1/0x530 exc_general_protection+0x181/0x210 asm_exc_general_protection+0x22/0x30 RIP: 0003:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0003:0000000000000000 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000001d0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Fixes: 9fd429c28073 ("x86/kasan: Map shadow for percpu pages on demand") Reported-by: syzbot+ffb4f000dc2872c93f62@syzkaller.appspotmail.com Suggested-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com> Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com> Link: https://lkml.kernel.org/r/20221110203504.1985010-3-seanjc@google.comSigned-off-by: NTong Tiangen <tongtiangen@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Sean Christopherson 提交于
mainline inclusion from mainline-v6.2-rc1 commit 80d72a8f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC CVE: CVE-2023-0597 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80d72a8f76e8f3f0b5a70b8c7022578e17bde8e7 -------------------------------- Recompute the physical address for each per-CPU page in the CPU entry area, a recent commit inadvertantly modified cea_map_percpu_pages() such that every PTE is mapped to the physical address of the first page. Fixes: 9fd429c28073 ("x86/kasan: Map shadow for percpu pages on demand") Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com> Link: https://lkml.kernel.org/r/20221110203504.1985010-2-seanjc@google.comSigned-off-by: NTong Tiangen <tongtiangen@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Andrey Ryabinin 提交于
mainline inclusion from mainline-v6.2-rc1 commit 3f148f33 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC CVE: CVE-2023-0597 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f148f3318140035e87decc1214795ff0755757b -------------------------------- KASAN maps shadow for the entire CPU-entry-area: [CPU_ENTRY_AREA_BASE, CPU_ENTRY_AREA_BASE + CPU_ENTRY_AREA_MAP_SIZE] This will explode once the per-cpu entry areas are randomized since it will increase CPU_ENTRY_AREA_MAP_SIZE to 512 GB and KASAN fails to allocate shadow for such big area. Fix this by allocating KASAN shadow only for really used cpu entry area addresses mapped by cea_map_percpu_pages() Thanks to the 0day folks for finding and reporting this to be an issue. [ dhansen: tweak changelog since this will get committed before peterz's actual cpu-entry-area randomization ] Signed-off-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Tested-by: NYujie Liu <yujie.liu@intel.com> Cc: kernel test robot <yujie.liu@intel.com> Link: https://lore.kernel.org/r/202210241508.2e203c3d-yujie.liu@intel.comSigned-off-by: NTong Tiangen <tongtiangen@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Peter Zijlstra 提交于
mainline inclusion from mainline-v6.2-rc1 commit 97e3d26b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC CVE: CVE-2023-0597 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e3d26b5e5f371b3ee223d94dd123e6c442ba80 -------------------------------- Seth found that the CPU-entry-area; the piece of per-cpu data that is mapped into the userspace page-tables for kPTI is not subject to any randomization -- irrespective of kASLR settings. On x86_64 a whole P4D (512 GB) of virtual address space is reserved for this structure, which is plenty large enough to randomize things a little. As such, use a straight forward randomization scheme that avoids duplicates to spread the existing CPUs over the available space. [ bp: Fix le build. ] Reported-by: NSeth Jenkins <sethjenkins@google.com> Reviewed-by: NKees Cook <keescook@chromium.org> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Confilict: arch/x86/mm/cpu_entry_area.c Use get_random_u32() instead of prandom_u32_max() in init_cea_offsets(). With CONFIG_RANDOMIZE_BASE=y, KASLR use prandom_seed_state() init prandom seed before init_cea_offsets(). But when CONFIG_RANDOMIZE_BASE=n, prandom seed init after init_cea_offsets() cause cea is always 0. The patch d4150779("random32: use real rng for non-deterministic randomness") use get_random_u32() instead of prandom_u32() in prandom_u32_max() that make prandom_u32_max() don't need to wait prandom seed init(). But the patch has many pre-patches that have not been merged, So,we adopt the current solution as a workaround. directly use get_random_u32() in init_cea_offsets() to simplify code. Signed-off-by: NKe Liu <liuke94@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
- 06 1月, 2023 1 次提交
-
-
由 Jim Mattson 提交于
mainline inclusion from mainline-v6.2-rc1 commit 2e7eab81 category: bugfix bugzilla: 188212 CVE: CVE-2022-2196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5 -------------------------------- According to Intel's document on Indirect Branch Restricted Speculation, "Enabling IBRS does not prevent software from controlling the predicted targets of indirect branches of unrelated software executed later at the same predictor mode (for example, between two different user applications, or two different virtual machines). Such isolation can be ensured through use of the Indirect Branch Predictor Barrier (IBPB) command." This applies to both basic and enhanced IBRS. Since L1 and L2 VMs share hardware predictor modes (guest-user and guest-kernel), hardware IBRS is not sufficient to virtualize IBRS. (The way that basic IBRS is implemented on pre-eIBRS parts, hardware IBRS is actually sufficient in practice, even though it isn't sufficient architecturally.) For virtual CPUs that support IBRS, add an indirect branch prediction barrier on emulated VM-exit, to ensure that the predicted targets of indirect branches executed in L1 cannot be controlled by software that was executed in L2. Since we typically don't intercept guest writes to IA32_SPEC_CTRL, perform the IBPB at emulated VM-exit regardless of the current IA32_SPEC_CTRL.IBRS value, even though the IBPB could technically be deferred until L1 sets IA32_SPEC_CTRL.IBRS, if IA32_SPEC_CTRL.IBRS is clear at emulated VM-exit. This is CVE-2022-2196. Fixes: 5c911bef ("KVM: nVMX: Skip IBPB when switching between vmcs01 and vmcs02") Cc: Sean Christopherson <seanjc@google.com> Signed-off-by: NJim Mattson <jmattson@google.com> Reviewed-by: NSean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/r/20221019213620.1953281-3-jmattson@google.comSigned-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NChenXiaoSong <chenxiaosong2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 04 1月, 2023 1 次提交
-
-
由 Pu Wen 提交于
mainline inclusion from mainline-v5.13-rc1 commit 59eca2fa category: bugfix bugzilla: 188047, https://gitee.com/src-openeuler/kernel/issues/I64FW4 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=59eca2fa1934de42d8aa44d3bef655c92ea69703 -------------------------------- Set the maximum DIE per package variable on Hygon using the nodes_per_socket value in order to do per-DIE manipulations for drivers such as powercap. Signed-off-by: NPu Wen <puwen@hygon.cn> Signed-off-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NIngo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20210302020217.1827-1-puwen@hygon.cnSigned-off-by: NYuyao Lin <linyuyao1@huawei.com> Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 13 12月, 2022 3 次提交
-
-
由 Stephane Eranian 提交于
stable inclusion from stable-v5.10.140 commit c0ba9aa95bf79aa49f1097ff1bb5884c8e08023c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I63FTT Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c0ba9aa95bf79aa49f1097ff1bb5884c8e08023c -------------------------------- commit 11745ecf upstream. Existing code was generating bogus counts for the SNB IMC bandwidth counters: $ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/ 1.000327813 1,024.03 MiB uncore_imc/data_reads/ 1.000327813 20.73 MiB uncore_imc/data_writes/ 2.000580153 261,120.00 MiB uncore_imc/data_reads/ 2.000580153 23.28 MiB uncore_imc/data_writes/ The problem was introduced by commit: 07ce734d ("perf/x86/intel/uncore: Clean up client IMC") Where the read_counter callback was replace to point to the generic uncore_mmio_read_counter() function. The SNB IMC counters are freerunnig 32-bit counters laid out contiguously in MMIO. But uncore_mmio_read_counter() is using a readq() call to read from MMIO therefore reading 64-bit from MMIO. Although this is okay for the uncore_perf_event_update() function because it is shifting the value based on the actual counter width to compute a delta, it is not okay for the uncore_pmu_event_start() which is simply reading the counter and therefore priming the event->prev_count with a bogus value which is responsible for causing bogus deltas in the perf stat command above. The fix is to reintroduce the custom callback for read_counter for the SNB IMC PMU and use readl() instead of readq(). With the change the output of perf stat is back to normal: $ perf stat -a -I 1000 -e uncore_imc/data_reads/,uncore_imc/data_writes/ 1.000120987 296.94 MiB uncore_imc/data_reads/ 1.000120987 138.42 MiB uncore_imc/data_writes/ 2.000403144 175.91 MiB uncore_imc/data_reads/ 2.000403144 68.50 MiB uncore_imc/data_writes/ Fixes: 07ce734d ("perf/x86/intel/uncore: Clean up client IMC") Signed-off-by: NStephane Eranian <eranian@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NKan Liang <kan.liang@linux.intel.com> Link: https://lore.kernel.org/r/20220803160031.1379788-1-eranian@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Pawan Gupta 提交于
stable inclusion from stable-v5.10.140 commit 14cbbb9c9914663d0eeca6b59c1c9d4f5a547ee0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I63FTT Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=14cbbb9c9914663d0eeca6b59c1c9d4f5a547ee0 -------------------------------- commit 7df54884 upstream. Older Intel CPUs that are not in the affected processor list for MMIO Stale Data vulnerabilities currently report "Not affected" in sysfs, which may not be correct. Vulnerability status for these older CPUs is unknown. Add known-not-affected CPUs to the whitelist. Report "unknown" mitigation status for CPUs that are not in blacklist, whitelist and also don't enumerate MSR ARCH_CAPABILITIES bits that reflect hardware immunity to MMIO Stale Data vulnerabilities. Mitigation is not deployed when the status is unknown. [ bp: Massage, fixup. ] Fixes: 8d50cdf8 ("x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data") Suggested-by: NAndrew Cooper <andrew.cooper3@citrix.com> Suggested-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/a932c154772f2121794a5f2eded1a11013114711.1657846269.git.pawan.kumar.gupta@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Kan Liang 提交于
stable inclusion from stable-v5.10.140 commit 090f0ac167a04d5cbc22718655f0c733a3b99775 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I63FTT Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=090f0ac167a04d5cbc22718655f0c733a3b99775 -------------------------------- commit 32ba156d upstream. On the platform with Arch LBR, the HW raw branch type encoding may leak to the perf tool when the SAVE_TYPE option is not set. In the intel_pmu_store_lbr(), the HW raw branch type is stored in lbr_entries[].type. If the SAVE_TYPE option is set, the lbr_entries[].type will be converted into the generic PERF_BR_* type in the intel_pmu_lbr_filter() and exposed to the user tools. But if the SAVE_TYPE option is NOT set by the user, the current perf kernel doesn't clear the field. The HW raw branch type leaks. There are two solutions to fix the issue for the Arch LBR. One is to clear the field if the SAVE_TYPE option is NOT set. The other solution is to unconditionally convert the branch type and expose the generic type to the user tools. The latter is implemented here, because - The branch type is valuable information. I don't see a case where you would not benefit from the branch type. (Stephane Eranian) - Not having the branch type DOES NOT save any space in the branch record (Stephane Eranian) - The Arch LBR HW can retrieve the common branch types from the LBR_INFO. It doesn't require the high overhead SW disassemble. Fixes: 47125db2 ("perf/x86/intel/lbr: Support Architectural LBR") Reported-by: NStephane Eranian <eranian@google.com> Signed-off-by: NKan Liang <kan.liang@linux.intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20220816125612.2042397-1-kan.liang@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
- 07 12月, 2022 2 次提交
-
-
由 Yu Liao 提交于
hulk inclusion category: feature bugzilla: 186841, https://gitee.com/openeuler/kernel/issues/I61188 CVE: NA -------------------------------- Enable CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE by default. Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Kees Cook 提交于
mainline inclusion from mainline-v5.13-rc1 commit fe950f60 category: featrue bugzilla: https://gitee.com/openeuler/kernel/issues/I5YQ6Z CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe950f6020338c8ac668ef823bb692d36b7542a2 -------------------------------- Allow for a randomized stack offset on a per-syscall basis, with roughly 5-6 bits of entropy, depending on compiler and word size. Since the method of offsetting uses macros, this cannot live in the common entry code (the stack offset needs to be retained for the life of the syscall, which means it needs to happen at the actual entry point). Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210401232347.2791257-5-keescook@chromium.orgSigned-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 05 12月, 2022 1 次提交
-
-
由 Liu Chao 提交于
Some configs' values are incorrect, use update_oedefconfig fix it. Signed-off-by: NLiu Chao <liuchao173@huawei.com>
-
- 29 11月, 2022 1 次提交
-
-
由 Sudeep Holla 提交于
mainline inclusion from mainline-v6.0-rc1 commit 8add9a3a category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5OHOB CVE: NA -------------------------------- Currently, the arch_efi_call_virt() assumes all users of it will have defined a type 'efi_##f##_t' to make use of it. Simplify the arch_efi_call_virt() macro by eliminating the explicit need for efi_##f##_t type for every user of this macro. Signed-off-by: NSudeep Holla <sudeep.holla@arm.com> Acked-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk> [ardb: apply Sudeep's ARM fix to i686, Loongarch and RISC-V too] Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
-
- 26 11月, 2022 1 次提交
-
-
由 Aaron Lu 提交于
stable inclusion from stable-v5.10.138 commit 6876b4804b041856a8a390b949983ae00d1fd5b8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60QFD Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6876b4804b041856a8a390b949983ae00d1fd5b8 -------------------------------- commit 88e0a749 upstream. Commit c164fbb4("x86/mm: thread pgprot_t through init_memory_mapping()") mistakenly used __pgprot() which doesn't respect __default_kernel_pte_mask when setting PUD mapping. Fix it by only setting the one bit we actually need (PSE) and leaving the other bits (that have been properly masked) alone. Fixes: c164fbb4 ("x86/mm: thread pgprot_t through init_memory_mapping()") Signed-off-by: NAaron Lu <aaron.lu@intel.com> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
- 18 11月, 2022 5 次提交
-
-
由 Aaron Lewis 提交于
stable inclusion from stable-v5.10.137 commit 98b20e1612e69bf91185cf722a96293a136fe894 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=98b20e1612e69bf91185cf722a96293a136fe894 -------------------------------- commit 4ac19ead upstream. When returning from the compare function the u64 is truncated to an int. This results in a loss of the high nybble[1] in the event select and its sign if that nybble is in use. Switch from using a result that can end up being truncated to a result that can only be: 1, 0, -1. [1] bits 35:32 in the event select register and bits 11:8 in the event select. Fixes: 7ff775ac ("KVM: x86/pmu: Use binary search to check filtered events") Signed-off-by: NAaron Lewis <aaronlewis@google.com> Reviewed-by: NSean Christopherson <seanjc@google.com> Message-Id: <20220517051238.2566934-1-aaronlewis@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Vitaly Kuznetsov 提交于
stable inclusion from stable-v5.10.137 commit ac7de8c2ba1292856fdd4a4c0764669b9607cf0a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ac7de8c2ba1292856fdd4a4c0764669b9607cf0a -------------------------------- commit 00b5f371 upstream When kvm_irq_delivery_to_apic_fast() is called with APIC_DEST_SELF shorthand, 'src' must not be NULL. Crash the VM with KVM_BUG_ON() instead of crashing the host. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20220325132140.25650-3-vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NStefan Ghinea <stefan.ghinea@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Vitaly Kuznetsov 提交于
stable inclusion from stable-v5.10.137 commit 4c85e207c1b58249ea521670df577324ad69442c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4c85e207c1b58249ea521670df577324ad69442c -------------------------------- commit 7ec37d1c upstream When KVM_CAP_HYPERV_SYNIC{,2} is activated, KVM already checks for irqchip_in_kernel() so normally SynIC irqs should never be set. It is, however, possible for a misbehaving VMM to write to SYNIC/STIMER MSRs causing erroneous behavior. The immediate issue being fixed is that kvm_irq_delivery_to_apic() (kvm_irq_delivery_to_apic_fast()) crashes when called with 'irq.shorthand = APIC_DEST_SELF' and 'src == NULL'. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20220325132140.25650-2-vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NStefan Ghinea <stefan.ghinea@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Like Xu 提交于
stable inclusion from stable-v5.10.137 commit b788508a09901b1324ae3afe8aa0897e380422af category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b788508a09901b1324ae3afe8aa0897e380422af -------------------------------- [ Upstream commit 98defd2e ] MSR_CORE_PERF_GLOBAL_CTRL is introduced as part of Architecture PMU V2, as indicated by Intel SDM 19.2.2 and the intel_is_valid_msr() function. So in the absence of global_ctrl support, all PMCs are enabled as AMD does. Signed-off-by: NLike Xu <likexu@tencent.com> Message-Id: <20220509102204.62389-1-likexu@tencent.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.137 commit 6b4addec2f2d68ed774b4b7b6264419b15aee3b0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6b4addec2f2d68ed774b4b7b6264419b15aee3b0 -------------------------------- [ Upstream commit 93255bf9 ] Mark all MSR_CORE_PERF_GLOBAL_CTRL and MSR_CORE_PERF_GLOBAL_OVF_CTRL bits as reserved if there is no guest vPMU. The nVMX VM-Entry consistency checks do not check for a valid vPMU prior to consuming the masks via kvm_valid_perf_global_ctrl(), i.e. may incorrectly allow a non-zero mask to be loaded via VM-Enter or VM-Exit (well, attempted to be loaded, the actual MSR load will be rejected by intel_is_valid_msr()). Fixes: f5132b01 ("KVM: Expose a version 2 architectural PMU to a guests") Cc: stable@vger.kernel.org Signed-off-by: NSean Christopherson <seanjc@google.com> Message-Id: <20220722224409.1336532-3-seanjc@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-