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

Linux 6.15-rc3

This is the 6.12.24 stable release

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]>

Linux 6.15-rc2