Tags: openunix/linux
Tags
Tag end of Tag end of resf_kernel-4.18.0-553.50.1.el8_10 - Original N… …ame: kernel-4.18.0-553.50.1.el8_10
[CIQ] v6.12.24 - rebased configs CONFIG_IRQ_BYPASS_MANAGER now follows KVM CONFIG_HAVE_KVM_IRQ_BYPASS now follows KVM KVM: Allow building irqbypass.ko as as module when kvm.ko is a module Upstream: fae0a87 CONFIG_HID_UNIVERSAL_PIDFF is new HID: Add hid-universal-pidff driver and supported device ids Upstream: f45f26a
Tag end of Tag end of resf_kernel-5.14.0-503.38.1.el9_5 - Original Na… …me: kernel-5.14.0-503.38.1.el9_5
x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT jira LE-2729 build-fix Fix build when XEN_PV is not set commit-author Kirill A. Shutemov <[email protected]> commit 22cc5ca upstream-diff Had to fix a couple of trivial merge conflicts because this kernel hasn't removed paravirt_disable_iospace and pv_native_wbindvd yet CONFIG_PARAVIRT_XXL is mainly defined/used by XEN PV guests. For other VM guest types, features supported under CONFIG_PARAVIRT are self sufficient. CONFIG_PARAVIRT mainly provides support for TLB flush operations and time related operations. For TDX guest as well, paravirt calls under CONFIG_PARVIRT meets most of its requirement except the need of HLT and SAFE_HLT paravirt calls, which is currently defined under CONFIG_PARAVIRT_XXL. Since enabling CONFIG_PARAVIRT_XXL is too bloated for TDX guest like platforms, move HLT and SAFE_HLT paravirt calls under CONFIG_PARAVIRT. Moving HLT and SAFE_HLT paravirt calls are not fatal and should not break any functionality for current users of CONFIG_PARAVIRT. Fixes: bfe6ed0 ("x86/tdx: Add HLT support for TDX guests") Co-developed-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Vishal Annapurve <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Tested-by: Ryan Afranji <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Brian Gerst <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 22cc5ca) Signed-off-by: Brett Mastbergen <[email protected]>
net/sched: cls_u32: No longer copy tcf_result on update to avoid use-… …after-free jira VULN-34673 jira VULN-8840 cve CVE-2023-4208 cve CVE-2023-4218 commit-author valis <[email protected]> commit 3044b16 When u32_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. Fix this by no longer copying the tcf_result struct from the old filter. Fixes: de5df63 ("net: sched: cls_u32 changes to knode must appear atomic to readers") Reported-by: valis <[email protected]> Reported-by: M A Ramdhan <[email protected]> Signed-off-by: valis <[email protected]> Signed-off-by: Jamal Hadi Salim <[email protected]> Reviewed-by: Victor Nogueira <[email protected]> Reviewed-by: Pedro Tammela <[email protected]> Reviewed-by: M A Ramdhan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 3044b16) Signed-off-by: Brett Mastbergen <[email protected]>
PreviousNext