--- /dev/null
+From e12e28009e584c8f8363439f6a928ec86278a106 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Wed, 20 Mar 2024 08:55:52 +0100
+Subject: arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as broken
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+commit e12e28009e584c8f8363439f6a928ec86278a106 upstream.
+
+Several Qualcomm Bluetooth controllers lack persistent storage for the
+device address and instead one can be provided by the boot firmware
+using the 'local-bd-address' devicetree property.
+
+The Bluetooth bindings clearly states that the address should be
+specified in little-endian order, but due to a long-standing bug in the
+Qualcomm driver which reversed the address some boot firmware has been
+providing the address in big-endian order instead.
+
+The boot firmware in SC7180 Trogdor Chromebooks is known to be affected
+so mark the 'local-bd-address' property as broken to maintain backwards
+compatibility with older firmware when fixing the underlying driver bug.
+
+Note that ChromeOS always updates the kernel and devicetree in lockstep
+so that there is no need to handle backwards compatibility with older
+devicetrees.
+
+Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt")
+Cc: stable@vger.kernel.org # 5.10
+Cc: Rob Clark <robdclark@chromium.org>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Acked-by: Bjorn Andersson <andersson@kernel.org>
+Reviewed-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
++++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+@@ -923,6 +923,8 @@ ap_spi_fp: &spi10 {
+ vddrf-supply = <&pp1300_l2c>;
+ vddch0-supply = <&pp3300_l10c>;
+ max-speed = <3200000>;
++
++ qcom,local-bd-address-broken;
+ };
+ };
+
--- /dev/null
+From 39646f29b100566451d37abc4cc8cdd583756dfe Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Wed, 20 Mar 2024 08:55:53 +0100
+Subject: Bluetooth: add quirk for broken address properties
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+commit 39646f29b100566451d37abc4cc8cdd583756dfe upstream.
+
+Some Bluetooth controllers lack persistent storage for the device
+address and instead one can be provided by the boot firmware using the
+'local-bd-address' devicetree property.
+
+The Bluetooth devicetree bindings clearly states that the address should
+be specified in little-endian order, but due to a long-standing bug in
+the Qualcomm driver which reversed the address some boot firmware has
+been providing the address in big-endian order instead.
+
+Add a new quirk that can be set on platforms with broken firmware and
+use it to reverse the address when parsing the property so that the
+underlying driver bug can be fixed.
+
+Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address")
+Cc: stable@vger.kernel.org # 5.1
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/bluetooth/hci.h | 9 +++++++++
+ net/bluetooth/hci_sync.c | 5 ++++-
+ 2 files changed, 13 insertions(+), 1 deletion(-)
+
+--- a/include/net/bluetooth/hci.h
++++ b/include/net/bluetooth/hci.h
+@@ -175,6 +175,15 @@ enum {
+ */
+ HCI_QUIRK_USE_BDADDR_PROPERTY,
+
++ /* When this quirk is set, the Bluetooth Device Address provided by
++ * the 'local-bd-address' fwnode property is incorrectly specified in
++ * big-endian order.
++ *
++ * This quirk can be set before hci_register_dev is called or
++ * during the hdev->setup vendor callback.
++ */
++ HCI_QUIRK_BDADDR_PROPERTY_BROKEN,
++
+ /* When this quirk is set, the duplicate filtering during
+ * scanning is based on Bluetooth devices addresses. To allow
+ * RSSI based updates, restart scanning if needed.
+--- a/net/bluetooth/hci_sync.c
++++ b/net/bluetooth/hci_sync.c
+@@ -3293,7 +3293,10 @@ static void hci_dev_get_bd_addr_from_pro
+ if (ret < 0 || !bacmp(&ba, BDADDR_ANY))
+ return;
+
+- bacpy(&hdev->public_addr, &ba);
++ if (test_bit(HCI_QUIRK_BDADDR_PROPERTY_BROKEN, &hdev->quirks))
++ baswap(&hdev->public_addr, &ba);
++ else
++ bacpy(&hdev->public_addr, &ba);
+ }
+
+ struct hci_init_stage {
--- /dev/null
+From 7835fcfd132eb88b87e8eb901f88436f63ab60f7 Mon Sep 17 00:00:00 2001
+From: Bastien Nocera <hadess@hadess.net>
+Date: Wed, 27 Mar 2024 15:24:56 +0100
+Subject: Bluetooth: Fix TOCTOU in HCI debugfs implementation
+
+From: Bastien Nocera <hadess@hadess.net>
+
+commit 7835fcfd132eb88b87e8eb901f88436f63ab60f7 upstream.
+
+struct hci_dev members conn_info_max_age, conn_info_min_age,
+le_conn_max_interval, le_conn_min_interval, le_adv_max_interval,
+and le_adv_min_interval can be modified from the HCI core code, as well
+through debugfs.
+
+The debugfs implementation, that's only available to privileged users,
+will check for boundaries, making sure that the minimum value being set
+is strictly above the maximum value that already exists, and vice-versa.
+
+However, as both minimum and maximum values can be changed concurrently
+to us modifying them, we need to make sure that the value we check is
+the value we end up using.
+
+For example, with ->conn_info_max_age set to 10, conn_info_min_age_set()
+gets called from vfs handlers to set conn_info_min_age to 8.
+
+In conn_info_min_age_set(), this goes through:
+ if (val == 0 || val > hdev->conn_info_max_age)
+ return -EINVAL;
+
+Concurrently, conn_info_max_age_set() gets called to set to set the
+conn_info_max_age to 7:
+ if (val == 0 || val > hdev->conn_info_max_age)
+ return -EINVAL;
+That check will also pass because we used the old value (10) for
+conn_info_max_age.
+
+After those checks that both passed, the struct hci_dev access
+is mutex-locked, disabling concurrent access, but that does not matter
+because the invalid value checks both passed, and we'll end up with
+conn_info_min_age = 8 and conn_info_max_age = 7
+
+To fix this problem, we need to lock the structure access before so the
+check and assignment are not interrupted.
+
+This fix was originally devised by the BassCheck[1] team, and
+considered the problem to be an atomicity one. This isn't the case as
+there aren't any concerns about the variable changing while we check it,
+but rather after we check it parallel to another change.
+
+This patch fixes CVE-2024-24858 and CVE-2024-24857.
+
+[1] https://sites.google.com/view/basscheck/
+
+Co-developed-by: Gui-Dong Han <2045gemini@gmail.com>
+Signed-off-by: Gui-Dong Han <2045gemini@gmail.com>
+Link: https://lore.kernel.org/linux-bluetooth/20231222161317.6255-1-2045gemini@gmail.com/
+Link: https://nvd.nist.gov/vuln/detail/CVE-2024-24858
+Link: https://lore.kernel.org/linux-bluetooth/20231222162931.6553-1-2045gemini@gmail.com/
+Link: https://lore.kernel.org/linux-bluetooth/20231222162310.6461-1-2045gemini@gmail.com/
+Link: https://nvd.nist.gov/vuln/detail/CVE-2024-24857
+Fixes: 31ad169148df ("Bluetooth: Add conn info lifetime parameters to debugfs")
+Fixes: 729a1051da6f ("Bluetooth: Expose default LE advertising interval via debugfs")
+Fixes: 71c3b60ec6d2 ("Bluetooth: Move BR/EDR debugfs file creation into hci_debugfs.c")
+Signed-off-by: Bastien Nocera <hadess@hadess.net>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_debugfs.c | 48 +++++++++++++++++++++++++++++---------------
+ 1 file changed, 32 insertions(+), 16 deletions(-)
+
+--- a/net/bluetooth/hci_debugfs.c
++++ b/net/bluetooth/hci_debugfs.c
+@@ -217,10 +217,12 @@ static int conn_info_min_age_set(void *d
+ {
+ struct hci_dev *hdev = data;
+
+- if (val == 0 || val > hdev->conn_info_max_age)
++ hci_dev_lock(hdev);
++ if (val == 0 || val > hdev->conn_info_max_age) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->conn_info_min_age = val;
+ hci_dev_unlock(hdev);
+
+@@ -245,10 +247,12 @@ static int conn_info_max_age_set(void *d
+ {
+ struct hci_dev *hdev = data;
+
+- if (val == 0 || val < hdev->conn_info_min_age)
++ hci_dev_lock(hdev);
++ if (val == 0 || val < hdev->conn_info_min_age) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->conn_info_max_age = val;
+ hci_dev_unlock(hdev);
+
+@@ -566,10 +570,12 @@ static int sniff_min_interval_set(void *
+ {
+ struct hci_dev *hdev = data;
+
+- if (val == 0 || val % 2 || val > hdev->sniff_max_interval)
++ hci_dev_lock(hdev);
++ if (val == 0 || val % 2 || val > hdev->sniff_max_interval) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->sniff_min_interval = val;
+ hci_dev_unlock(hdev);
+
+@@ -594,10 +600,12 @@ static int sniff_max_interval_set(void *
+ {
+ struct hci_dev *hdev = data;
+
+- if (val == 0 || val % 2 || val < hdev->sniff_min_interval)
++ hci_dev_lock(hdev);
++ if (val == 0 || val % 2 || val < hdev->sniff_min_interval) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->sniff_max_interval = val;
+ hci_dev_unlock(hdev);
+
+@@ -849,10 +857,12 @@ static int conn_min_interval_set(void *d
+ {
+ struct hci_dev *hdev = data;
+
+- if (val < 0x0006 || val > 0x0c80 || val > hdev->le_conn_max_interval)
++ hci_dev_lock(hdev);
++ if (val < 0x0006 || val > 0x0c80 || val > hdev->le_conn_max_interval) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->le_conn_min_interval = val;
+ hci_dev_unlock(hdev);
+
+@@ -877,10 +887,12 @@ static int conn_max_interval_set(void *d
+ {
+ struct hci_dev *hdev = data;
+
+- if (val < 0x0006 || val > 0x0c80 || val < hdev->le_conn_min_interval)
++ hci_dev_lock(hdev);
++ if (val < 0x0006 || val > 0x0c80 || val < hdev->le_conn_min_interval) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->le_conn_max_interval = val;
+ hci_dev_unlock(hdev);
+
+@@ -989,10 +1001,12 @@ static int adv_min_interval_set(void *da
+ {
+ struct hci_dev *hdev = data;
+
+- if (val < 0x0020 || val > 0x4000 || val > hdev->le_adv_max_interval)
++ hci_dev_lock(hdev);
++ if (val < 0x0020 || val > 0x4000 || val > hdev->le_adv_max_interval) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->le_adv_min_interval = val;
+ hci_dev_unlock(hdev);
+
+@@ -1017,10 +1031,12 @@ static int adv_max_interval_set(void *da
+ {
+ struct hci_dev *hdev = data;
+
+- if (val < 0x0020 || val > 0x4000 || val < hdev->le_adv_min_interval)
++ hci_dev_lock(hdev);
++ if (val < 0x0020 || val > 0x4000 || val < hdev->le_adv_min_interval) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->le_adv_max_interval = val;
+ hci_dev_unlock(hdev);
+
--- /dev/null
+From c569242cd49287d53b73a94233db40097d838535 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Wed, 27 Mar 2024 12:30:30 +0800
+Subject: Bluetooth: hci_event: set the conn encrypted before conn establishes
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit c569242cd49287d53b73a94233db40097d838535 upstream.
+
+We have a BT headset (Lenovo Thinkplus XT99), the pairing and
+connecting has no problem, once this headset is paired, bluez will
+remember this device and will auto re-connect it whenever the device
+is powered on. The auto re-connecting works well with Windows and
+Android, but with Linux, it always fails. Through debugging, we found
+at the rfcomm connection stage, the bluetooth stack reports
+"Connection refused - security block (0x0003)".
+
+For this device, the re-connecting negotiation process is different
+from other BT headsets, it sends the Link_KEY_REQUEST command before
+the CONNECT_REQUEST completes, and it doesn't send ENCRYPT_CHANGE
+command during the negotiation. When the device sends the "connect
+complete" to hci, the ev->encr_mode is 1.
+
+So here in the conn_complete_evt(), if ev->encr_mode is 1, link type
+is ACL and HCI_CONN_ENCRYPT is not set, we set HCI_CONN_ENCRYPT to
+this conn, and update conn->enc_key_size accordingly.
+
+After this change, this BT headset could re-connect with Linux
+successfully. This is the btmon log after applying the patch, after
+receiving the "Connect Complete" with "Encryption: Enabled", will send
+the command to read encryption key size:
+> HCI Event: Connect Request (0x04) plen 10
+ Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
+ Class: 0x240404
+ Major class: Audio/Video (headset, speaker, stereo, video, vcr)
+ Minor class: Wearable Headset Device
+ Rendering (Printing, Speaker)
+ Audio (Speaker, Microphone, Headset)
+ Link type: ACL (0x01)
+...
+> HCI Event: Link Key Request (0x17) plen 6
+ Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
+< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
+ Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
+ Link key: ${32-hex-digits-key}
+...
+> HCI Event: Connect Complete (0x03) plen 11
+ Status: Success (0x00)
+ Handle: 256
+ Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
+ Link type: ACL (0x01)
+ Encryption: Enabled (0x01)
+< HCI Command: Read Encryption Key... (0x05|0x0008) plen 2
+ Handle: 256
+< ACL Data TX: Handle 256 flags 0x00 dlen 10
+ L2CAP: Information Request (0x0a) ident 1 len 2
+ Type: Extended features supported (0x0002)
+> HCI Event: Command Complete (0x0e) plen 7
+ Read Encryption Key Size (0x05|0x0008) ncmd 1
+ Status: Success (0x00)
+ Handle: 256
+ Key size: 16
+
+Cc: stable@vger.kernel.org
+Link: https://github.com/bluez/bluez/issues/704
+Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Reviewed-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_event.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -3234,6 +3234,31 @@ static void hci_conn_complete_evt(struct
+ if (test_bit(HCI_ENCRYPT, &hdev->flags))
+ set_bit(HCI_CONN_ENCRYPT, &conn->flags);
+
++ /* "Link key request" completed ahead of "connect request" completes */
++ if (ev->encr_mode == 1 && !test_bit(HCI_CONN_ENCRYPT, &conn->flags) &&
++ ev->link_type == ACL_LINK) {
++ struct link_key *key;
++ struct hci_cp_read_enc_key_size cp;
++
++ key = hci_find_link_key(hdev, &ev->bdaddr);
++ if (key) {
++ set_bit(HCI_CONN_ENCRYPT, &conn->flags);
++
++ if (!(hdev->commands[20] & 0x10)) {
++ conn->enc_key_size = HCI_LINK_KEY_SIZE;
++ } else {
++ cp.handle = cpu_to_le16(conn->handle);
++ if (hci_send_cmd(hdev, HCI_OP_READ_ENC_KEY_SIZE,
++ sizeof(cp), &cp)) {
++ bt_dev_err(hdev, "sending read key size failed");
++ conn->enc_key_size = HCI_LINK_KEY_SIZE;
++ }
++ }
++
++ hci_encrypt_cfm(conn, ev->status);
++ }
++ }
++
+ /* Get remote features */
+ if (conn->type == ACL_LINK) {
+ struct hci_cp_read_remote_features cp;
--- /dev/null
+From 77f45cca8bc55d00520a192f5a7715133591c83e Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Wed, 20 Mar 2024 08:55:54 +0100
+Subject: Bluetooth: qca: fix device-address endianness
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+commit 77f45cca8bc55d00520a192f5a7715133591c83e upstream.
+
+The WCN6855 firmware on the Lenovo ThinkPad X13s expects the Bluetooth
+device address in big-endian order when setting it using the
+EDL_WRITE_BD_ADDR_OPCODE command.
+
+Presumably, this is the case for all non-ROME devices which all use the
+EDL_WRITE_BD_ADDR_OPCODE command for this (unlike the ROME devices which
+use a different command and expect the address in little-endian order).
+
+Reverse the little-endian address before setting it to make sure that
+the address can be configured using tools like btmgmt or using the
+'local-bd-address' devicetree property.
+
+Note that this can potentially break systems with boot firmware which
+has started relying on the broken behaviour and is incorrectly passing
+the address via devicetree in big-endian order.
+
+The only device affected by this should be the WCN3991 used in some
+Chromebooks. As ChromeOS updates the kernel and devicetree in lockstep,
+the new 'qcom,local-bd-address-broken' property can be used to determine
+if the firmware is buggy so that the underlying driver bug can be fixed
+without breaking backwards compatibility.
+
+Set the HCI_QUIRK_BDADDR_PROPERTY_BROKEN quirk for such platforms so
+that the address is reversed when parsing the address property.
+
+Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address")
+Cc: stable@vger.kernel.org # 5.1
+Cc: Balakrishna Godavarthi <quic_bgodavar@quicinc.com>
+Cc: Matthias Kaehlcke <mka@chromium.org>
+Tested-by: Nikita Travkin <nikita@trvn.ru> # sc7180
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/btqca.c | 8 ++++++--
+ drivers/bluetooth/hci_qca.c | 10 ++++++++++
+ 2 files changed, 16 insertions(+), 2 deletions(-)
+
+--- a/drivers/bluetooth/btqca.c
++++ b/drivers/bluetooth/btqca.c
+@@ -758,11 +758,15 @@ EXPORT_SYMBOL_GPL(qca_uart_setup);
+
+ int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr)
+ {
++ bdaddr_t bdaddr_swapped;
+ struct sk_buff *skb;
+ int err;
+
+- skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, bdaddr,
+- HCI_EV_VENDOR, HCI_INIT_TIMEOUT);
++ baswap(&bdaddr_swapped, bdaddr);
++
++ skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6,
++ &bdaddr_swapped, HCI_EV_VENDOR,
++ HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ err = PTR_ERR(skb);
+ bt_dev_err(hdev, "QCA Change address cmd failed (%d)", err);
+--- a/drivers/bluetooth/hci_qca.c
++++ b/drivers/bluetooth/hci_qca.c
+@@ -225,6 +225,7 @@ struct qca_serdev {
+ struct qca_power *bt_power;
+ u32 init_speed;
+ u32 oper_speed;
++ bool bdaddr_property_broken;
+ const char *firmware_name;
+ };
+
+@@ -1787,6 +1788,7 @@ static int qca_setup(struct hci_uart *hu
+ const char *firmware_name = qca_get_firmware_name(hu);
+ int ret;
+ struct qca_btsoc_version ver;
++ struct qca_serdev *qcadev;
+ const char *soc_name;
+
+ ret = qca_check_speeds(hu);
+@@ -1845,6 +1847,11 @@ retry:
+ case QCA_WCN6855:
+ case QCA_WCN7850:
+ set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
++
++ qcadev = serdev_device_get_drvdata(hu->serdev);
++ if (qcadev->bdaddr_property_broken)
++ set_bit(HCI_QUIRK_BDADDR_PROPERTY_BROKEN, &hdev->quirks);
++
+ hci_set_aosp_capable(hdev);
+
+ ret = qca_read_soc_version(hdev, &ver, soc_type);
+@@ -2212,6 +2219,9 @@ static int qca_serdev_probe(struct serde
+ if (!qcadev->oper_speed)
+ BT_DBG("UART will pick default operating speed");
+
++ qcadev->bdaddr_property_broken = device_property_read_bool(&serdev->dev,
++ "qcom,local-bd-address-broken");
++
+ if (data)
+ qcadev->btsoc_type = data->soc_type;
+ else
--- /dev/null
+From e89c928bedd77d181edc2df01cb6672184775140 Mon Sep 17 00:00:00 2001
+From: Oliver Upton <oliver.upton@linux.dev>
+Date: Tue, 5 Mar 2024 18:48:39 +0000
+Subject: KVM: arm64: Fix host-programmed guest events in nVHE
+
+From: Oliver Upton <oliver.upton@linux.dev>
+
+commit e89c928bedd77d181edc2df01cb6672184775140 upstream.
+
+Programming PMU events in the host that count during guest execution is
+a feature supported by perf, e.g.
+
+ perf stat -e cpu_cycles:G ./lkvm run
+
+While this works for VHE, the guest/host event bitmaps are not carried
+through to the hypervisor in the nVHE configuration. Make
+kvm_pmu_update_vcpu_events() conditional on whether or not _hardware_
+supports PMUv3 rather than if the vCPU as vPMU enabled.
+
+Cc: stable@vger.kernel.org
+Fixes: 84d751a019a9 ("KVM: arm64: Pass pmu events to hyp via vcpu")
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20240305184840.636212-3-oliver.upton@linux.dev
+Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/kvm/arm_pmu.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/kvm/arm_pmu.h
++++ b/include/kvm/arm_pmu.h
+@@ -85,7 +85,7 @@ void kvm_vcpu_pmu_restore_host(struct kv
+ */
+ #define kvm_pmu_update_vcpu_events(vcpu) \
+ do { \
+- if (!has_vhe() && kvm_vcpu_has_pmu(vcpu)) \
++ if (!has_vhe() && kvm_arm_support_pmu_v3()) \
+ vcpu->arch.pmu.events = *kvm_get_pmu_events(); \
+ } while (0)
+
--- /dev/null
+From 62fc3357e079a07a22465b9b6ef71bb6ea75ee4b Mon Sep 17 00:00:00 2001
+From: Mahmoud Adam <mngyadam@amazon.com>
+Date: Tue, 26 Mar 2024 16:31:33 +0100
+Subject: net/rds: fix possible cp null dereference
+
+From: Mahmoud Adam <mngyadam@amazon.com>
+
+commit 62fc3357e079a07a22465b9b6ef71bb6ea75ee4b upstream.
+
+cp might be null, calling cp->cp_conn would produce null dereference
+
+[Simon Horman adds:]
+
+Analysis:
+
+* cp is a parameter of __rds_rdma_map and is not reassigned.
+
+* The following call-sites pass a NULL cp argument to __rds_rdma_map()
+
+ - rds_get_mr()
+ - rds_get_mr_for_dest
+
+* Prior to the code above, the following assumes that cp may be NULL
+ (which is indicative, but could itself be unnecessary)
+
+ trans_private = rs->rs_transport->get_mr(
+ sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL,
+ args->vec.addr, args->vec.bytes,
+ need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);
+
+* The code modified by this patch is guarded by IS_ERR(trans_private),
+ where trans_private is assigned as per the previous point in this analysis.
+
+ The only implementation of get_mr that I could locate is rds_ib_get_mr()
+ which can return an ERR_PTR if the conn (4th) argument is NULL.
+
+* ret is set to PTR_ERR(trans_private).
+ rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.
+ Thus ret may be -ENODEV in which case the code in question will execute.
+
+Conclusion:
+* cp may be NULL at the point where this patch adds a check;
+ this patch does seem to address a possible bug
+
+Fixes: c055fc00c07b ("net/rds: fix WARNING in rds_conn_connect_if_down")
+Cc: stable@vger.kernel.org # v4.19+
+Signed-off-by: Mahmoud Adam <mngyadam@amazon.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://lore.kernel.org/r/20240326153132.55580-1-mngyadam@amazon.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rds/rdma.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/rds/rdma.c
++++ b/net/rds/rdma.c
+@@ -302,7 +302,7 @@ static int __rds_rdma_map(struct rds_soc
+ }
+ ret = PTR_ERR(trans_private);
+ /* Trigger connection so that its ready for the next retry */
+- if (ret == -ENODEV)
++ if (ret == -ENODEV && cp)
+ rds_conn_connect_if_down(cp->cp_conn);
+ goto out;
+ }
--- /dev/null
+From 2e91bb99b9d4f756e92e83c4453f894dda220f09 Mon Sep 17 00:00:00 2001
+From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+Date: Wed, 3 Apr 2024 15:21:58 +0200
+Subject: net: usb: ax88179_178a: avoid the interface always configured as random address
+
+From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+
+commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream.
+
+After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
+consecutive device resets"), reset is not executed from bind operation and
+mac address is not read from the device registers or the devicetree at that
+moment. Since the check to configure if the assigned mac address is random
+or not for the interface, happens after the bind operation from
+usbnet_probe, the interface keeps configured as random address, although the
+address is correctly read and set during open operation (the only reset
+now).
+
+In order to keep only one reset for the device and to avoid the interface
+always configured as random address, after reset, configure correctly the
+suitable field from the driver, if the mac address is read successfully from
+the device registers or the devicetree. Take into account if a locally
+administered address (random) was previously stored.
+
+cc: stable@vger.kernel.org # 6.6+
+Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets")
+Reported-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
+Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://lore.kernel.org/r/20240403132158.344838-1-jtornosm@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/ax88179_178a.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/net/usb/ax88179_178a.c
++++ b/drivers/net/usb/ax88179_178a.c
+@@ -1273,6 +1273,8 @@ static void ax88179_get_mac_addr(struct
+
+ if (is_valid_ether_addr(mac)) {
+ eth_hw_addr_set(dev->net, mac);
++ if (!is_local_ether_addr(mac))
++ dev->net->addr_assign_type = NET_ADDR_PERM;
+ } else {
+ netdev_info(dev->net, "invalid MAC address, using random\n");
+ eth_hw_addr_random(dev->net);
--- /dev/null
+From 5d872c9f46bd2ea3524af3c2420a364a13667135 Mon Sep 17 00:00:00 2001
+From: Heiner Kallweit <hkallweit1@gmail.com>
+Date: Sat, 30 Mar 2024 12:49:02 +0100
+Subject: r8169: fix issue caused by buggy BIOS on certain boards with RTL8168d
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+commit 5d872c9f46bd2ea3524af3c2420a364a13667135 upstream.
+
+On some boards with this chip version the BIOS is buggy and misses
+to reset the PHY page selector. This results in the PHY ID read
+accessing registers on a different page, returning a more or
+less random value. Fix this by resetting the page selector first.
+
+Fixes: f1e911d5d0df ("r8169: add basic phylib support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://lore.kernel.org/r/64f2055e-98b8-45ec-8568-665e3d54d4e6@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/realtek/r8169_main.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/net/ethernet/realtek/r8169_main.c
++++ b/drivers/net/ethernet/realtek/r8169_main.c
+@@ -5032,6 +5032,15 @@ static int r8169_mdio_register(struct rt
+ struct mii_bus *new_bus;
+ int ret;
+
++ /* On some boards with this chip version the BIOS is buggy and misses
++ * to reset the PHY page selector. This results in the PHY ID read
++ * accessing registers on a different page, returning a more or
++ * less random value. Fix this by resetting the page selector first.
++ */
++ if (tp->mac_version == RTL_GIGA_MAC_VER_25 ||
++ tp->mac_version == RTL_GIGA_MAC_VER_26)
++ r8169_mdio_write(tp, 0x1f, 0);
++
+ new_bus = devm_mdiobus_alloc(&pdev->dev);
+ if (!new_bus)
+ return -ENOMEM;
--- /dev/null
+From 4790a73ace86f3d165bbedba898e0758e6e1b82d Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Thu, 14 Mar 2024 09:44:12 +0100
+Subject: Revert "Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT"
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+commit 4790a73ace86f3d165bbedba898e0758e6e1b82d upstream.
+
+This reverts commit 7dcd3e014aa7faeeaf4047190b22d8a19a0db696.
+
+Qualcomm Bluetooth controllers like WCN6855 do not have persistent
+storage for the Bluetooth address and must therefore start as
+unconfigured to allow the user to set a valid address unless one has
+been provided by the boot firmware in the devicetree.
+
+A recent change snuck into v6.8-rc7 and incorrectly started marking the
+default (non-unique) address as valid. This specifically also breaks the
+Bluetooth setup for some user of the Lenovo ThinkPad X13s.
+
+Note that this is the second time Qualcomm breaks the driver this way
+and that this was fixed last year by commit 6945795bc81a ("Bluetooth:
+fix use-bdaddr-property quirk"), which also has some further details.
+
+Fixes: 7dcd3e014aa7 ("Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT")
+Cc: stable@vger.kernel.org # 6.8
+Cc: Janaki Ramaiah Thota <quic_janathot@quicinc.com>
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Reported-by: Clayton Craft <clayton@craftyguy.net>
+Tested-by: Clayton Craft <clayton@craftyguy.net>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/hci_qca.c | 13 +------------
+ 1 file changed, 1 insertion(+), 12 deletions(-)
+
+--- a/drivers/bluetooth/hci_qca.c
++++ b/drivers/bluetooth/hci_qca.c
+@@ -7,7 +7,6 @@
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Copyright (c) 2010, 2012, 2018 The Linux Foundation. All rights reserved.
+- * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ *
+ * Acknowledgements:
+ * This file is based on hci_ll.c, which was...
+@@ -1845,17 +1844,7 @@ retry:
+ case QCA_WCN6750:
+ case QCA_WCN6855:
+ case QCA_WCN7850:
+-
+- /* Set BDA quirk bit for reading BDA value from fwnode property
+- * only if that property exist in DT.
+- */
+- if (fwnode_property_present(dev_fwnode(hdev->dev.parent), "local-bd-address")) {
+- set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
+- bt_dev_info(hdev, "setting quirk bit to read BDA from fwnode later");
+- } else {
+- bt_dev_dbg(hdev, "local-bd-address` is not present in the devicetree so not setting quirk bit for BDA");
+- }
+-
++ set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
+ hci_set_aosp_capable(hdev);
+
+ ret = qca_read_soc_version(hdev, &ver, soc_type);
dm-integrity-fix-out-of-range-warning.patch
x86-cpufeatures-add-new-word-for-scattered-features.patch
perf-x86-amd-lbr-use-freeze-based-on-availability.patch
+kvm-arm64-fix-host-programmed-guest-events-in-nvhe.patch
+r8169-fix-issue-caused-by-buggy-bios-on-certain-boards-with-rtl8168d.patch
+x86-cpufeatures-add-cpuid_lnx_5-to-track-recently-added-linux-defined-word.patch
+revert-bluetooth-hci_qca-set-bda-quirk-bit-if-fwnode-exists-in-dt.patch
+arm64-dts-qcom-sc7180-trogdor-mark-bluetooth-address-as-broken.patch
+bluetooth-qca-fix-device-address-endianness.patch
+bluetooth-add-quirk-for-broken-address-properties.patch
+bluetooth-hci_event-set-the-conn-encrypted-before-conn-establishes.patch
+bluetooth-fix-toctou-in-hci-debugfs-implementation.patch
+xen-netfront-add-missing-skb_mark_for_recycle.patch
+net-rds-fix-possible-cp-null-dereference.patch
+net-usb-ax88179_178a-avoid-the-interface-always-configured-as-random-address.patch
+vsock-virtio-fix-packet-delivery-to-tap-device.patch
--- /dev/null
+From b32a09ea7c38849ff925489a6bf5bd8914bc45df Mon Sep 17 00:00:00 2001
+From: Marco Pinna <marco.pinn95@gmail.com>
+Date: Fri, 29 Mar 2024 17:12:59 +0100
+Subject: vsock/virtio: fix packet delivery to tap device
+
+From: Marco Pinna <marco.pinn95@gmail.com>
+
+commit b32a09ea7c38849ff925489a6bf5bd8914bc45df upstream.
+
+Commit 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks") added
+virtio_transport_deliver_tap_pkt() for handing packets to the
+vsockmon device. However, in virtio_transport_send_pkt_work(),
+the function is called before actually sending the packet (i.e.
+before placing it in the virtqueue with virtqueue_add_sgs() and checking
+whether it returned successfully).
+Queuing the packet in the virtqueue can fail even multiple times.
+However, in virtio_transport_deliver_tap_pkt() we deliver the packet
+to the monitoring tap interface only the first time we call it.
+This certainly avoids seeing the same packet replicated multiple times
+in the monitoring interface, but it can show the packet sent with the
+wrong timestamp or even before we succeed to queue it in the virtqueue.
+
+Move virtio_transport_deliver_tap_pkt() after calling virtqueue_add_sgs()
+and making sure it returned successfully.
+
+Fixes: 82dfb540aeb2 ("VSOCK: Add virtio vsock vsockmon hooks")
+Cc: stable@vge.kernel.org
+Signed-off-by: Marco Pinna <marco.pinn95@gmail.com>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Link: https://lore.kernel.org/r/20240329161259.411751-1-marco.pinn95@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/vmw_vsock/virtio_transport.c
++++ b/net/vmw_vsock/virtio_transport.c
+@@ -109,7 +109,6 @@ virtio_transport_send_pkt_work(struct wo
+ if (!skb)
+ break;
+
+- virtio_transport_deliver_tap_pkt(skb);
+ reply = virtio_vsock_skb_reply(skb);
+
+ sg_init_one(&hdr, virtio_vsock_hdr(skb), sizeof(*virtio_vsock_hdr(skb)));
+@@ -128,6 +127,8 @@ virtio_transport_send_pkt_work(struct wo
+ break;
+ }
+
++ virtio_transport_deliver_tap_pkt(skb);
++
+ if (reply) {
+ struct virtqueue *rx_vq = vsock->vqs[VSOCK_VQ_RX];
+ int val;
--- /dev/null
+From 8cb4a9a82b21623dbb4b3051dd30d98356cf95bc Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 4 Apr 2024 17:16:14 -0700
+Subject: x86/cpufeatures: Add CPUID_LNX_5 to track recently added Linux-defined word
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 8cb4a9a82b21623dbb4b3051dd30d98356cf95bc upstream.
+
+Add CPUID_LNX_5 to track cpufeatures' word 21, and add the appropriate
+compile-time assert in KVM to prevent direct lookups on the features in
+CPUID_LNX_5. KVM uses X86_FEATURE_* flags to manage guest CPUID, and so
+must translate features that are scattered by Linux from the Linux-defined
+bit to the hardware-defined bit, i.e. should never try to directly access
+scattered features in guest CPUID.
+
+Opportunistically add NR_CPUID_WORDS to enum cpuid_leafs, along with a
+compile-time assert in KVM's CPUID infrastructure to ensure that future
+additions update cpuid_leafs along with NCAPINTS.
+
+No functional change intended.
+
+Fixes: 7f274e609f3d ("x86/cpufeatures: Add new word for scattered features")
+Cc: Sandipan Das <sandipan.das@amd.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/cpufeature.h | 2 ++
+ arch/x86/kvm/reverse_cpuid.h | 2 ++
+ 2 files changed, 4 insertions(+)
+
+--- a/arch/x86/include/asm/cpufeature.h
++++ b/arch/x86/include/asm/cpufeature.h
+@@ -33,6 +33,8 @@ enum cpuid_leafs
+ CPUID_7_EDX,
+ CPUID_8000_001F_EAX,
+ CPUID_8000_0021_EAX,
++ CPUID_LNX_5,
++ NR_CPUID_WORDS,
+ };
+
+ #define X86_CAP_FMT_NUM "%d:%d"
+--- a/arch/x86/kvm/reverse_cpuid.h
++++ b/arch/x86/kvm/reverse_cpuid.h
+@@ -83,10 +83,12 @@ static const struct cpuid_reg reverse_cp
+ */
+ static __always_inline void reverse_cpuid_check(unsigned int x86_leaf)
+ {
++ BUILD_BUG_ON(NR_CPUID_WORDS != NCAPINTS);
+ BUILD_BUG_ON(x86_leaf == CPUID_LNX_1);
+ BUILD_BUG_ON(x86_leaf == CPUID_LNX_2);
+ BUILD_BUG_ON(x86_leaf == CPUID_LNX_3);
+ BUILD_BUG_ON(x86_leaf == CPUID_LNX_4);
++ BUILD_BUG_ON(x86_leaf == CPUID_LNX_5);
+ BUILD_BUG_ON(x86_leaf >= ARRAY_SIZE(reverse_cpuid));
+ BUILD_BUG_ON(reverse_cpuid[x86_leaf].function == 0);
+ }
--- /dev/null
+From 037965402a010898d34f4e35327d22c0a95cd51f Mon Sep 17 00:00:00 2001
+From: Jesper Dangaard Brouer <hawk@kernel.org>
+Date: Wed, 27 Mar 2024 13:14:56 +0100
+Subject: xen-netfront: Add missing skb_mark_for_recycle
+
+From: Jesper Dangaard Brouer <hawk@kernel.org>
+
+commit 037965402a010898d34f4e35327d22c0a95cd51f upstream.
+
+Notice that skb_mark_for_recycle() is introduced later than fixes tag in
+commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
+
+It is believed that fixes tag were missing a call to page_pool_release_page()
+between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().
+Since v6.6 the call page_pool_release_page() were removed (in
+commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")
+and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch
+'net-page_pool-remove-page_pool_release_page'")).
+
+This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch
+page_pool memory leaks").
+
+Cc: stable@vger.kernel.org
+Fixes: 6c5aa6fc4def ("xen networking: add basic XDP support for xen-netfront")
+Reported-by: Leonidas Spyropoulos <artafinde@archlinux.com>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=218654
+Reported-by: Arthur Borsboom <arthurborsboom@gmail.com>
+Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org>
+Link: https://lore.kernel.org/r/171154167446.2671062.9127105384591237363.stgit@firesoul
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/xen-netfront.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/xen-netfront.c
++++ b/drivers/net/xen-netfront.c
+@@ -285,6 +285,7 @@ static struct sk_buff *xennet_alloc_one_
+ return NULL;
+ }
+ skb_add_rx_frag(skb, 0, page, 0, 0, PAGE_SIZE);
++ skb_mark_for_recycle(skb);
+
+ /* Align ip header to a 16 bytes boundary */
+ skb_reserve(skb, NET_IP_ALIGN);
projects / thirdparty / kernel / stable-queue.git / commitdiff
