From: Greg Kroah-Hartman Date: Fri, 3 Feb 2023 08:18:09 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v4.14.305~15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4b21da322134fb2a336c62a783eeb0cc9be98a94;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: acpi-processor-idle-practically-limit-dummy-wait-workaround-to-old-intel-systems.patch bluetooth-fix-null-ptr-deref-on-hci_sync_conn_complete_evt.patch --- diff --git a/queue-5.10/acpi-processor-idle-practically-limit-dummy-wait-workaround-to-old-intel-systems.patch b/queue-5.10/acpi-processor-idle-practically-limit-dummy-wait-workaround-to-old-intel-systems.patch new file mode 100644 index 00000000000..29a04022a42 --- /dev/null +++ b/queue-5.10/acpi-processor-idle-practically-limit-dummy-wait-workaround-to-old-intel-systems.patch @@ -0,0 +1,77 @@ +From e400ad8b7e6a1b9102123c6240289a811501f7d9 Mon Sep 17 00:00:00 2001 +From: Dave Hansen +Date: Thu, 22 Sep 2022 11:47:45 -0700 +Subject: ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems + +From: Dave Hansen + +commit e400ad8b7e6a1b9102123c6240289a811501f7d9 upstream. + +Old, circa 2002 chipsets have a bug: they don't go idle when they are +supposed to. So, a workaround was added to slow the CPU down and +ensure that the CPU waits a bit for the chipset to actually go idle. +This workaround is ancient and has been in place in some form since +the original kernel ACPI implementation. + +But, this workaround is very painful on modern systems. The "inl()" +can take thousands of cycles (see Link: for some more detailed +numbers and some fun kernel archaeology). + +First and foremost, modern systems should not be using this code. +Typical Intel systems have not used it in over a decade because it is +horribly inferior to MWAIT-based idle. + +Despite this, people do seem to be tripping over this workaround on +AMD system today. + +Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD +systems from tripping over the workaround. Remotely modern Intel +systems use intel_idle instead of this code and will, in practice, +remain unaffected by the dummy wait. + +Reported-by: K Prateek Nayak +Suggested-by: Rafael J. Wysocki +Signed-off-by: Dave Hansen +Reviewed-by: Mario Limonciello +Tested-by: K Prateek Nayak +Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/ +Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com +Signed-off-by: Guilherme G. Piccoli +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/processor_idle.c | 23 ++++++++++++++++++++--- + 1 file changed, 20 insertions(+), 3 deletions(-) + +--- a/drivers/acpi/processor_idle.c ++++ b/drivers/acpi/processor_idle.c +@@ -536,10 +536,27 @@ static void wait_for_freeze(void) + /* No delay is needed if we are in guest */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + return; ++ /* ++ * Modern (>=Nehalem) Intel systems use ACPI via intel_idle, ++ * not this code. Assume that any Intel systems using this ++ * are ancient and may need the dummy wait. This also assumes ++ * that the motivating chipset issue was Intel-only. ++ */ ++ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) ++ return; + #endif +- /* Dummy wait op - must do something useless after P_LVL2 read +- because chipsets cannot guarantee that STPCLK# signal +- gets asserted in time to freeze execution properly. */ ++ /* ++ * Dummy wait op - must do something useless after P_LVL2 read ++ * because chipsets cannot guarantee that STPCLK# signal gets ++ * asserted in time to freeze execution properly ++ * ++ * This workaround has been in place since the original ACPI ++ * implementation was merged, circa 2002. ++ * ++ * If a profile is pointing to this instruction, please first ++ * consider moving your system to a more modern idle ++ * mechanism. ++ */ + inl(acpi_gbl_FADT.xpm_timer_block.address); + } + diff --git a/queue-5.10/bluetooth-fix-null-ptr-deref-on-hci_sync_conn_complete_evt.patch b/queue-5.10/bluetooth-fix-null-ptr-deref-on-hci_sync_conn_complete_evt.patch new file mode 100644 index 00000000000..fbf6659bdb6 --- /dev/null +++ b/queue-5.10/bluetooth-fix-null-ptr-deref-on-hci_sync_conn_complete_evt.patch @@ -0,0 +1,45 @@ +From 3afee2118132e93e5f6fa636dfde86201a860ab3 Mon Sep 17 00:00:00 2001 +From: Soenke Huster +Date: Fri, 14 Jan 2022 17:44:02 +0100 +Subject: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt + +From: Soenke Huster + +commit 3afee2118132e93e5f6fa636dfde86201a860ab3 upstream. + +This event is just specified for SCO and eSCO link types. +On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR +of an existing LE connection, LE link type and a status that triggers the +second case of the packet processing a NULL pointer dereference happens, +as conn->link is NULL. + +Signed-off-by: Soenke Huster +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Ovidiu Panait +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_event.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -4307,6 +4307,19 @@ static void hci_sync_conn_complete_evt(s + struct hci_ev_sync_conn_complete *ev = (void *) skb->data; + struct hci_conn *conn; + ++ switch (ev->link_type) { ++ case SCO_LINK: ++ case ESCO_LINK: ++ break; ++ default: ++ /* As per Core 5.3 Vol 4 Part E 7.7.35 (p.2219), Link_Type ++ * for HCI_Synchronous_Connection_Complete is limited to ++ * either SCO or eSCO ++ */ ++ bt_dev_err(hdev, "Ignoring connect complete event for invalid link type"); ++ return; ++ } ++ + BT_DBG("%s status 0x%2.2x", hdev->name, ev->status); + + hci_dev_lock(hdev); diff --git a/queue-5.10/series b/queue-5.10/series index ad4a02326a2..4156e9aec35 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -4,3 +4,5 @@ arm64-dts-imx8mq-thor96-fix-no-mmc-property-for-sdhc.patch bpf-skip-task-with-pid-1-in-send_signal_common.patch blk-cgroup-fix-missing-pd_online_fn-while-activating.patch dmaengine-imx-sdma-fix-a-possible-memory-leak-in-sdm.patch +acpi-processor-idle-practically-limit-dummy-wait-workaround-to-old-intel-systems.patch +bluetooth-fix-null-ptr-deref-on-hci_sync_conn_complete_evt.patch