--- /dev/null
+From 1e9683c9b6ca88cc9340cdca85edd6134c8cffe3 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Date: Tue, 27 Aug 2024 15:01:34 -0400
+Subject: Bluetooth: MGMT: Ignore keys being loaded with invalid type
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+commit 1e9683c9b6ca88cc9340cdca85edd6134c8cffe3 upstream.
+
+Due to 59b047bc98084f8af2c41483e4d68a5adf2fa7f7 there could be keys stored
+with the wrong address type so this attempt to detect it and ignore them
+instead of just failing to load all keys.
+
+Cc: stable@vger.kernel.org
+Link: https://github.com/bluez/bluez/issues/875
+Fixes: 59b047bc9808 ("Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE")
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/mgmt.c | 37 +++++++++++++++++++------------------
+ 1 file changed, 19 insertions(+), 18 deletions(-)
+
+--- a/net/bluetooth/mgmt.c
++++ b/net/bluetooth/mgmt.c
+@@ -2824,15 +2824,6 @@ static int load_link_keys(struct sock *s
+ bt_dev_dbg(hdev, "debug_keys %u key_count %u", cp->debug_keys,
+ key_count);
+
+- for (i = 0; i < key_count; i++) {
+- struct mgmt_link_key_info *key = &cp->keys[i];
+-
+- if (key->addr.type != BDADDR_BREDR || key->type > 0x08)
+- return mgmt_cmd_status(sk, hdev->id,
+- MGMT_OP_LOAD_LINK_KEYS,
+- MGMT_STATUS_INVALID_PARAMS);
+- }
+-
+ hci_dev_lock(hdev);
+
+ hci_link_keys_clear(hdev);
+@@ -2857,6 +2848,19 @@ static int load_link_keys(struct sock *s
+ continue;
+ }
+
++ if (key->addr.type != BDADDR_BREDR) {
++ bt_dev_warn(hdev,
++ "Invalid link address type %u for %pMR",
++ key->addr.type, &key->addr.bdaddr);
++ continue;
++ }
++
++ if (key->type > 0x08) {
++ bt_dev_warn(hdev, "Invalid link key type %u for %pMR",
++ key->type, &key->addr.bdaddr);
++ continue;
++ }
++
+ /* Always ignore debug keys and require a new pairing if
+ * the user wants to use them.
+ */
+@@ -7139,15 +7143,6 @@ static int load_long_term_keys(struct so
+
+ bt_dev_dbg(hdev, "key_count %u", key_count);
+
+- for (i = 0; i < key_count; i++) {
+- struct mgmt_ltk_info *key = &cp->keys[i];
+-
+- if (!ltk_is_valid(key))
+- return mgmt_cmd_status(sk, hdev->id,
+- MGMT_OP_LOAD_LONG_TERM_KEYS,
+- MGMT_STATUS_INVALID_PARAMS);
+- }
+-
+ hci_dev_lock(hdev);
+
+ hci_smp_ltks_clear(hdev);
+@@ -7163,6 +7158,12 @@ static int load_long_term_keys(struct so
+ &key->addr.bdaddr);
+ continue;
+ }
++
++ if (!ltk_is_valid(key)) {
++ bt_dev_warn(hdev, "Invalid LTK for %pMR",
++ &key->addr.bdaddr);
++ continue;
++ }
+
+ switch (key->type) {
+ case MGMT_LTK_UNAUTHENTICATED:
--- /dev/null
+From 3002240d16494d798add0575e8ba1f284258ab34 Mon Sep 17 00:00:00 2001
+From: yangyun <yangyun50@huawei.com>
+Date: Fri, 23 Aug 2024 16:51:46 +0800
+Subject: fuse: fix memory leak in fuse_create_open
+
+From: yangyun <yangyun50@huawei.com>
+
+commit 3002240d16494d798add0575e8ba1f284258ab34 upstream.
+
+The memory of struct fuse_file is allocated but not freed
+when get_create_ext return error.
+
+Fixes: 3e2b6fdbdc9a ("fuse: send security context of inode on file")
+Cc: stable@vger.kernel.org # v5.17
+Signed-off-by: yangyun <yangyun50@huawei.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/dir.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/fuse/dir.c
++++ b/fs/fuse/dir.c
+@@ -668,7 +668,7 @@ static int fuse_create_open(struct inode
+
+ err = get_create_ext(&args, dir, entry, mode);
+ if (err)
+- goto out_put_forget_req;
++ goto out_free_ff;
+
+ err = fuse_simple_request(fm, &args);
+ free_ext_value(&args);
--- /dev/null
+From f7790d67785302b3116bbbfda62a5a44524601a3 Mon Sep 17 00:00:00 2001
+From: Joanne Koong <joannelkoong@gmail.com>
+Date: Mon, 26 Aug 2024 14:19:04 -0700
+Subject: fuse: update stats for pages in dropped aux writeback list
+
+From: Joanne Koong <joannelkoong@gmail.com>
+
+commit f7790d67785302b3116bbbfda62a5a44524601a3 upstream.
+
+In the case where the aux writeback list is dropped (e.g. the pages
+have been truncated or the connection is broken), the stats for
+its pages and backing device info need to be updated as well.
+
+Fixes: e2653bd53a98 ("fuse: fix leaked aux requests")
+Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Cc: <stable@vger.kernel.org> # v5.1
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/file.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/fuse/file.c
++++ b/fs/fuse/file.c
+@@ -1735,10 +1735,16 @@ __acquires(fi->lock)
+ fuse_writepage_finish(fm, wpa);
+ spin_unlock(&fi->lock);
+
+- /* After fuse_writepage_finish() aux request list is private */
++ /* After rb_erase() aux request list is private */
+ for (aux = wpa->next; aux; aux = next) {
++ struct backing_dev_info *bdi = inode_to_bdi(aux->inode);
++
+ next = aux->next;
+ aux->next = NULL;
++
++ dec_wb_stat(&bdi->wb, WB_WRITEBACK);
++ dec_node_page_state(aux->ia.ap.pages[0], NR_WRITEBACK_TEMP);
++ wb_writeout_inc(&bdi->wb);
+ fuse_writepage_free(aux);
+ }
+
--- /dev/null
+From b18915248a15eae7d901262f108d6ff0ffb4ffc1 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Mon, 19 Aug 2024 19:52:30 +0200
+Subject: fuse: use unsigned type for getxattr/listxattr size truncation
+
+From: Jann Horn <jannh@google.com>
+
+commit b18915248a15eae7d901262f108d6ff0ffb4ffc1 upstream.
+
+The existing code uses min_t(ssize_t, outarg.size, XATTR_LIST_MAX) when
+parsing the FUSE daemon's response to a zero-length getxattr/listxattr
+request.
+On 32-bit kernels, where ssize_t and outarg.size are the same size, this is
+wrong: The min_t() will pass through any size values that are negative when
+interpreted as signed.
+fuse_listxattr() will then return this userspace-supplied negative value,
+which callers will treat as an error value.
+
+This kind of bug pattern can lead to fairly bad security bugs because of
+how error codes are used in the Linux kernel. If a caller were to convert
+the numeric error into an error pointer, like so:
+
+ struct foo *func(...) {
+ int len = fuse_getxattr(..., NULL, 0);
+ if (len < 0)
+ return ERR_PTR(len);
+ ...
+ }
+
+then it would end up returning this userspace-supplied negative value cast
+to a pointer - but the caller of this function wouldn't recognize it as an
+error pointer (IS_ERR_VALUE() only detects values in the narrow range in
+which legitimate errno values are), and so it would just be treated as a
+kernel pointer.
+
+I think there is at least one theoretical codepath where this could happen,
+but that path would involve virtio-fs with submounts plus some weird
+SELinux configuration, so I think it's probably not a concern in practice.
+
+Cc: stable@vger.kernel.org # v4.9
+Fixes: 63401ccdb2ca ("fuse: limit xattr returned size")
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/xattr.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/fuse/xattr.c
++++ b/fs/fuse/xattr.c
+@@ -81,7 +81,7 @@ ssize_t fuse_getxattr(struct inode *inod
+ }
+ ret = fuse_simple_request(fm, &args);
+ if (!ret && !size)
+- ret = min_t(ssize_t, outarg.size, XATTR_SIZE_MAX);
++ ret = min_t(size_t, outarg.size, XATTR_SIZE_MAX);
+ if (ret == -ENOSYS) {
+ fm->fc->no_getxattr = 1;
+ ret = -EOPNOTSUPP;
+@@ -143,7 +143,7 @@ ssize_t fuse_listxattr(struct dentry *en
+ }
+ ret = fuse_simple_request(fm, &args);
+ if (!ret && !size)
+- ret = min_t(ssize_t, outarg.size, XATTR_LIST_MAX);
++ ret = min_t(size_t, outarg.size, XATTR_LIST_MAX);
+ if (ret > 0 && size)
+ ret = fuse_verify_xattr_list(list, ret);
+ if (ret == -ENOSYS) {
--- /dev/null
+From 469e5e4713989fdd5e3e502b922e7be0da2464b9 Mon Sep 17 00:00:00 2001
+From: Jonathan Bell <jonathan@raspberrypi.com>
+Date: Wed, 21 Aug 2024 08:06:31 +0900
+Subject: mmc: core: apply SD quirks earlier during probe
+
+From: Jonathan Bell <jonathan@raspberrypi.com>
+
+commit 469e5e4713989fdd5e3e502b922e7be0da2464b9 upstream.
+
+Applying MMC_QUIRK_BROKEN_SD_CACHE is broken, as the card's SD quirks are
+referenced in sd_parse_ext_reg_perf() prior to the quirks being initialized
+in mmc_blk_probe().
+
+To fix this problem, let's split out an SD-specific list of quirks and
+apply in mmc_sd_init_card() instead. In this way, sd_read_ext_regs() to has
+the available information for not assigning the SD_EXT_PERF_CACHE as one of
+the (un)supported features, which in turn allows mmc_sd_init_card() to
+properly skip execution of sd_enable_cache().
+
+Fixes: c467c8f08185 ("mmc: Add MMC_QUIRK_BROKEN_SD_CACHE for Kingston Canvas Go Plus from 11/2019")
+Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
+Co-developed-by: Keita Aihara <keita.aihara@sony.com>
+Signed-off-by: Keita Aihara <keita.aihara@sony.com>
+Reviewed-by: Dragan Simic <dsimic@manjaro.org>
+Reviewed-by: Avri Altman <avri.altman@wdc.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240820230631.GA436523@sony.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/quirks.h | 22 +++++++++++++---------
+ drivers/mmc/core/sd.c | 4 ++++
+ 2 files changed, 17 insertions(+), 9 deletions(-)
+
+--- a/drivers/mmc/core/quirks.h
++++ b/drivers/mmc/core/quirks.h
+@@ -15,6 +15,19 @@
+
+ #include "card.h"
+
++static const struct mmc_fixup __maybe_unused mmc_sd_fixups[] = {
++ /*
++ * Kingston Canvas Go! Plus microSD cards never finish SD cache flush.
++ * This has so far only been observed on cards from 11/2019, while new
++ * cards from 2023/05 do not exhibit this behavior.
++ */
++ _FIXUP_EXT("SD64G", CID_MANFID_KINGSTON_SD, 0x5449, 2019, 11,
++ 0, -1ull, SDIO_ANY_ID, SDIO_ANY_ID, add_quirk_sd,
++ MMC_QUIRK_BROKEN_SD_CACHE, EXT_CSD_REV_ANY),
++
++ END_FIXUP
++};
++
+ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = {
+ #define INAND_CMD38_ARG_EXT_CSD 113
+ #define INAND_CMD38_ARG_ERASE 0x00
+@@ -54,15 +67,6 @@ static const struct mmc_fixup __maybe_un
+ MMC_QUIRK_BLK_NO_CMD23),
+
+ /*
+- * Kingston Canvas Go! Plus microSD cards never finish SD cache flush.
+- * This has so far only been observed on cards from 11/2019, while new
+- * cards from 2023/05 do not exhibit this behavior.
+- */
+- _FIXUP_EXT("SD64G", CID_MANFID_KINGSTON_SD, 0x5449, 2019, 11,
+- 0, -1ull, SDIO_ANY_ID, SDIO_ANY_ID, add_quirk_sd,
+- MMC_QUIRK_BROKEN_SD_CACHE, EXT_CSD_REV_ANY),
+-
+- /*
+ * Some SD cards lockup while using CMD23 multiblock transfers.
+ */
+ MMC_FIXUP("AF SD", CID_MANFID_ATP, CID_OEMID_ANY, add_quirk_sd,
+--- a/drivers/mmc/core/sd.c
++++ b/drivers/mmc/core/sd.c
+@@ -26,6 +26,7 @@
+ #include "host.h"
+ #include "bus.h"
+ #include "mmc_ops.h"
++#include "quirks.h"
+ #include "sd.h"
+ #include "sd_ops.h"
+
+@@ -1475,6 +1476,9 @@ retry:
+ goto free_card;
+ }
+
++ /* Apply quirks prior to card setup */
++ mmc_fixup_device(card, mmc_sd_fixups);
++
+ err = mmc_sd_setup_card(host, card, oldcard != NULL);
+ if (err)
+ goto free_card;
--- /dev/null
+From aea62c744a9ae2a8247c54ec42138405216414da Mon Sep 17 00:00:00 2001
+From: Seunghwan Baek <sh8267.baek@samsung.com>
+Date: Thu, 29 Aug 2024 15:18:22 +0900
+Subject: mmc: cqhci: Fix checking of CQHCI_HALT state
+
+From: Seunghwan Baek <sh8267.baek@samsung.com>
+
+commit aea62c744a9ae2a8247c54ec42138405216414da upstream.
+
+To check if mmc cqe is in halt state, need to check set/clear of CQHCI_HALT
+bit. At this time, we need to check with &, not &&.
+
+Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
+Cc: stable@vger.kernel.org
+Signed-off-by: Seunghwan Baek <sh8267.baek@samsung.com>
+Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/20240829061823.3718-2-sh8267.baek@samsung.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/cqhci-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/cqhci-core.c
++++ b/drivers/mmc/host/cqhci-core.c
+@@ -612,7 +612,7 @@ static int cqhci_request(struct mmc_host
+ cqhci_writel(cq_host, 0, CQHCI_CTL);
+ mmc->cqe_on = true;
+ pr_debug("%s: cqhci: CQE on\n", mmc_hostname(mmc));
+- if (cqhci_readl(cq_host, CQHCI_CTL) && CQHCI_HALT) {
++ if (cqhci_readl(cq_host, CQHCI_CTL) & CQHCI_HALT) {
+ pr_err("%s: cqhci: CQE failed to exit halt state\n",
+ mmc_hostname(mmc));
+ }
--- /dev/null
+From 8396c793ffdf28bb8aee7cfe0891080f8cab7890 Mon Sep 17 00:00:00 2001
+From: Sam Protsenko <semen.protsenko@linaro.org>
+Date: Wed, 6 Mar 2024 17:20:52 -0600
+Subject: mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K
+
+From: Sam Protsenko <semen.protsenko@linaro.org>
+
+commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890 upstream.
+
+Commit 616f87661792 ("mmc: pass queue_limits to blk_mq_alloc_disk") [1]
+revealed the long living issue in dw_mmc.c driver, existing since the
+time when it was first introduced in commit f95f3850f7a9 ("mmc: dw_mmc:
+Add Synopsys DesignWare mmc host driver."), also making kernel boot
+broken on platforms using dw_mmc driver with 16K or 64K pages enabled,
+with this message in dmesg:
+
+ mmcblk: probe of mmc0:0001 failed with error -22
+
+That's happening because mmc_blk_probe() fails when it calls
+blk_validate_limits() consequently, which returns the error due to
+failed max_segment_size check in this code:
+
+ /*
+ * The maximum segment size has an odd historic 64k default that
+ * drivers probably should override. Just like the I/O size we
+ * require drivers to at least handle a full page per segment.
+ */
+ ...
+ if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
+ return -EINVAL;
+
+In case when IDMAC (Internal DMA Controller) is used, dw_mmc.c always
+sets .max_seg_size to 4 KiB:
+
+ mmc->max_seg_size = 0x1000;
+
+The comment in the code above explains why it's incorrect. Arnd
+suggested setting .max_seg_size to .max_req_size to fix it, which is
+also what some other drivers are doing:
+
+ $ grep -rl 'max_seg_size.*=.*max_req_size' drivers/mmc/host/ | \
+ wc -l
+ 18
+
+This change is not only fixing the boot with 16K/64K pages, but also
+leads to a better MMC performance. The linear write performance was
+tested on E850-96 board (eMMC only), before commit [1] (where it's
+possible to boot with 16K/64K pages without this fix, to be able to do
+a comparison). It was tested with this command:
+
+ # dd if=/dev/zero of=somefile bs=1M count=500 oflag=sync
+
+Test results are as follows:
+
+ - 4K pages, .max_seg_size = 4 KiB: 94.2 MB/s
+ - 4K pages, .max_seg_size = .max_req_size = 512 KiB: 96.9 MB/s
+ - 16K pages, .max_seg_size = 4 KiB: 126 MB/s
+ - 16K pages, .max_seg_size = .max_req_size = 2 MiB: 128 MB/s
+ - 64K pages, .max_seg_size = 4 KiB: 138 MB/s
+ - 64K pages, .max_seg_size = .max_req_size = 8 MiB: 138 MB/s
+
+Unfortunately, SD card controller is not enabled in E850-96 yet, so it
+wasn't possible for me to run the test on some cheap SD cards to check
+this patch's impact on those. But it's possible that this change might
+also reduce the writes count, thus improving SD/eMMC longevity.
+
+All credit for the analysis and the suggested solution goes to Arnd.
+
+[1] https://lore.kernel.org/all/20240215070300.2200308-18-hch@lst.de/
+
+Fixes: f95f3850f7a9 ("mmc: dw_mmc: Add Synopsys DesignWare mmc host driver.")
+Suggested-by: Arnd Bergmann <arnd@arndb.de>
+Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
+Closes: https://lore.kernel.org/all/CA+G9fYtddf2Fd3be+YShHP6CmSDNcn0ptW8qg+stUKW+Cn0rjQ@mail.gmail.com/
+Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240306232052.21317-1-semen.protsenko@linaro.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/dw_mmc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/dw_mmc.c
++++ b/drivers/mmc/host/dw_mmc.c
+@@ -2952,8 +2952,8 @@ static int dw_mci_init_slot(struct dw_mc
+ if (host->use_dma == TRANS_MODE_IDMAC) {
+ mmc->max_segs = host->ring_size;
+ mmc->max_blk_size = 65535;
+- mmc->max_seg_size = 0x1000;
+- mmc->max_req_size = mmc->max_seg_size * host->ring_size;
++ mmc->max_req_size = DW_MCI_DESC_DATA_LENGTH * host->ring_size;
++ mmc->max_seg_size = mmc->max_req_size;
+ mmc->max_blk_count = mmc->max_req_size / 512;
+ } else if (host->use_dma == TRANS_MODE_EDMAC) {
+ mmc->max_segs = 64;
--- /dev/null
+From 6e540da4c1db7b840e347c4dfe48359b18b7e376 Mon Sep 17 00:00:00 2001
+From: Liao Chen <liaochen4@huawei.com>
+Date: Mon, 26 Aug 2024 12:48:51 +0000
+Subject: mmc: sdhci-of-aspeed: fix module autoloading
+
+From: Liao Chen <liaochen4@huawei.com>
+
+commit 6e540da4c1db7b840e347c4dfe48359b18b7e376 upstream.
+
+Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
+based on the alias from of_device_id table.
+
+Signed-off-by: Liao Chen <liaochen4@huawei.com>
+Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
+Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240826124851.379759-1-liaochen4@huawei.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-of-aspeed.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mmc/host/sdhci-of-aspeed.c
++++ b/drivers/mmc/host/sdhci-of-aspeed.c
+@@ -510,6 +510,7 @@ static const struct of_device_id aspeed_
+ { .compatible = "aspeed,ast2600-sdhci", .data = &ast2600_sdhci_pdata, },
+ { }
+ };
++MODULE_DEVICE_TABLE(of, aspeed_sdhci_of_match);
+
+ static struct platform_driver aspeed_sdhci_driver = {
+ .driver = {
--- /dev/null
+From 532f8bcd1c2c4e8112f62e1922fd1703bc0ffce0 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Date: Tue, 27 Aug 2024 14:37:22 -0400
+Subject: Revert "Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE"
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+commit 532f8bcd1c2c4e8112f62e1922fd1703bc0ffce0 upstream.
+
+This reverts commit 59b047bc98084f8af2c41483e4d68a5adf2fa7f7 which
+breaks compatibility with commands like:
+
+bluetoothd[46328]: @ MGMT Command: Load.. (0x0013) plen 74 {0x0001} [hci0]
+ Keys: 2
+ BR/EDR Address: C0:DC:DA:A5:E5:47 (Samsung Electronics Co.,Ltd)
+ Key type: Authenticated key from P-256 (0x03)
+ Central: 0x00
+ Encryption size: 16
+ Diversifier[2]: 0000
+ Randomizer[8]: 0000000000000000
+ Key[16]: 6ed96089bd9765be2f2c971b0b95f624
+ LE Address: D7:2A:DE:1E:73:A2 (Static)
+ Key type: Unauthenticated key from P-256 (0x02)
+ Central: 0x00
+ Encryption size: 16
+ Diversifier[2]: 0000
+ Randomizer[8]: 0000000000000000
+ Key[16]: 87dd2546ededda380ffcdc0a8faa4597
+@ MGMT Event: Command Status (0x0002) plen 3 {0x0001} [hci0]
+ Load Long Term Keys (0x0013)
+ Status: Invalid Parameters (0x0d)
+
+Cc: stable@vger.kernel.org
+Link: https://github.com/bluez/bluez/issues/875
+Fixes: 59b047bc9808 ("Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE")
+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_core.h | 5 -----
+ net/bluetooth/mgmt.c | 25 +++++++------------------
+ net/bluetooth/smp.c | 7 -------
+ 3 files changed, 7 insertions(+), 30 deletions(-)
+
+--- a/include/net/bluetooth/hci_core.h
++++ b/include/net/bluetooth/hci_core.h
+@@ -188,7 +188,6 @@ struct blocked_key {
+ struct smp_csrk {
+ bdaddr_t bdaddr;
+ u8 bdaddr_type;
+- u8 link_type;
+ u8 type;
+ u8 val[16];
+ };
+@@ -198,7 +197,6 @@ struct smp_ltk {
+ struct rcu_head rcu;
+ bdaddr_t bdaddr;
+ u8 bdaddr_type;
+- u8 link_type;
+ u8 authenticated;
+ u8 type;
+ u8 enc_size;
+@@ -213,7 +211,6 @@ struct smp_irk {
+ bdaddr_t rpa;
+ bdaddr_t bdaddr;
+ u8 addr_type;
+- u8 link_type;
+ u8 val[16];
+ };
+
+@@ -221,8 +218,6 @@ struct link_key {
+ struct list_head list;
+ struct rcu_head rcu;
+ bdaddr_t bdaddr;
+- u8 bdaddr_type;
+- u8 link_type;
+ u8 type;
+ u8 val[HCI_LINK_KEY_SIZE];
+ u8 pin_len;
+--- a/net/bluetooth/mgmt.c
++++ b/net/bluetooth/mgmt.c
+@@ -2827,8 +2827,7 @@ static int load_link_keys(struct sock *s
+ for (i = 0; i < key_count; i++) {
+ struct mgmt_link_key_info *key = &cp->keys[i];
+
+- /* Considering SMP over BREDR/LE, there is no need to check addr_type */
+- if (key->type > 0x08)
++ if (key->addr.type != BDADDR_BREDR || key->type > 0x08)
+ return mgmt_cmd_status(sk, hdev->id,
+ MGMT_OP_LOAD_LINK_KEYS,
+ MGMT_STATUS_INVALID_PARAMS);
+@@ -7065,7 +7064,6 @@ static int load_irks(struct sock *sk, st
+
+ for (i = 0; i < irk_count; i++) {
+ struct mgmt_irk_info *irk = &cp->irks[i];
+- u8 addr_type = le_addr_type(irk->addr.type);
+
+ if (hci_is_blocked_key(hdev,
+ HCI_BLOCKED_KEY_TYPE_IRK,
+@@ -7075,12 +7073,8 @@ static int load_irks(struct sock *sk, st
+ continue;
+ }
+
+- /* When using SMP over BR/EDR, the addr type should be set to BREDR */
+- if (irk->addr.type == BDADDR_BREDR)
+- addr_type = BDADDR_BREDR;
+-
+ hci_add_irk(hdev, &irk->addr.bdaddr,
+- addr_type, irk->val,
++ le_addr_type(irk->addr.type), irk->val,
+ BDADDR_ANY);
+ }
+
+@@ -7161,7 +7155,6 @@ static int load_long_term_keys(struct so
+ for (i = 0; i < key_count; i++) {
+ struct mgmt_ltk_info *key = &cp->keys[i];
+ u8 type, authenticated;
+- u8 addr_type = le_addr_type(key->addr.type);
+
+ if (hci_is_blocked_key(hdev,
+ HCI_BLOCKED_KEY_TYPE_LTK,
+@@ -7196,12 +7189,8 @@ static int load_long_term_keys(struct so
+ continue;
+ }
+
+- /* When using SMP over BR/EDR, the addr type should be set to BREDR */
+- if (key->addr.type == BDADDR_BREDR)
+- addr_type = BDADDR_BREDR;
+-
+ hci_add_ltk(hdev, &key->addr.bdaddr,
+- addr_type, type, authenticated,
++ le_addr_type(key->addr.type), type, authenticated,
+ key->val, key->enc_size, key->ediv, key->rand);
+ }
+
+@@ -9450,7 +9439,7 @@ void mgmt_new_link_key(struct hci_dev *h
+
+ ev.store_hint = persistent;
+ bacpy(&ev.key.addr.bdaddr, &key->bdaddr);
+- ev.key.addr.type = link_to_bdaddr(key->link_type, key->bdaddr_type);
++ ev.key.addr.type = BDADDR_BREDR;
+ ev.key.type = key->type;
+ memcpy(ev.key.val, key->val, HCI_LINK_KEY_SIZE);
+ ev.key.pin_len = key->pin_len;
+@@ -9501,7 +9490,7 @@ void mgmt_new_ltk(struct hci_dev *hdev,
+ ev.store_hint = persistent;
+
+ bacpy(&ev.key.addr.bdaddr, &key->bdaddr);
+- ev.key.addr.type = link_to_bdaddr(key->link_type, key->bdaddr_type);
++ ev.key.addr.type = link_to_bdaddr(LE_LINK, key->bdaddr_type);
+ ev.key.type = mgmt_ltk_type(key);
+ ev.key.enc_size = key->enc_size;
+ ev.key.ediv = key->ediv;
+@@ -9530,7 +9519,7 @@ void mgmt_new_irk(struct hci_dev *hdev,
+
+ bacpy(&ev.rpa, &irk->rpa);
+ bacpy(&ev.irk.addr.bdaddr, &irk->bdaddr);
+- ev.irk.addr.type = link_to_bdaddr(irk->link_type, irk->addr_type);
++ ev.irk.addr.type = link_to_bdaddr(LE_LINK, irk->addr_type);
+ memcpy(ev.irk.val, irk->val, sizeof(irk->val));
+
+ mgmt_event(MGMT_EV_NEW_IRK, hdev, &ev, sizeof(ev), NULL);
+@@ -9559,7 +9548,7 @@ void mgmt_new_csrk(struct hci_dev *hdev,
+ ev.store_hint = persistent;
+
+ bacpy(&ev.key.addr.bdaddr, &csrk->bdaddr);
+- ev.key.addr.type = link_to_bdaddr(csrk->link_type, csrk->bdaddr_type);
++ ev.key.addr.type = link_to_bdaddr(LE_LINK, csrk->bdaddr_type);
+ ev.key.type = csrk->type;
+ memcpy(ev.key.val, csrk->val, sizeof(csrk->val));
+
+--- a/net/bluetooth/smp.c
++++ b/net/bluetooth/smp.c
+@@ -1061,7 +1061,6 @@ static void smp_notify_keys(struct l2cap
+ }
+
+ if (smp->remote_irk) {
+- smp->remote_irk->link_type = hcon->type;
+ mgmt_new_irk(hdev, smp->remote_irk, persistent);
+
+ /* Now that user space can be considered to know the
+@@ -1081,28 +1080,24 @@ static void smp_notify_keys(struct l2cap
+ }
+
+ if (smp->csrk) {
+- smp->csrk->link_type = hcon->type;
+ smp->csrk->bdaddr_type = hcon->dst_type;
+ bacpy(&smp->csrk->bdaddr, &hcon->dst);
+ mgmt_new_csrk(hdev, smp->csrk, persistent);
+ }
+
+ if (smp->responder_csrk) {
+- smp->responder_csrk->link_type = hcon->type;
+ smp->responder_csrk->bdaddr_type = hcon->dst_type;
+ bacpy(&smp->responder_csrk->bdaddr, &hcon->dst);
+ mgmt_new_csrk(hdev, smp->responder_csrk, persistent);
+ }
+
+ if (smp->ltk) {
+- smp->ltk->link_type = hcon->type;
+ smp->ltk->bdaddr_type = hcon->dst_type;
+ bacpy(&smp->ltk->bdaddr, &hcon->dst);
+ mgmt_new_ltk(hdev, smp->ltk, persistent);
+ }
+
+ if (smp->responder_ltk) {
+- smp->responder_ltk->link_type = hcon->type;
+ smp->responder_ltk->bdaddr_type = hcon->dst_type;
+ bacpy(&smp->responder_ltk->bdaddr, &hcon->dst);
+ mgmt_new_ltk(hdev, smp->responder_ltk, persistent);
+@@ -1122,8 +1117,6 @@ static void smp_notify_keys(struct l2cap
+ key = hci_add_link_key(hdev, smp->conn->hcon, &hcon->dst,
+ smp->link_key, type, 0, &persistent);
+ if (key) {
+- key->link_type = hcon->type;
+- key->bdaddr_type = hcon->dst_type;
+ mgmt_new_link_key(hdev, key, persistent);
+
+ /* Don't keep debug keys around if the relevant
nvme-pci-add-sleep-quirk-for-samsung-990-evo.patch
rust-types-make-opaque-get-const.patch
rust-macros-provide-correct-provenance-when-constructing-this_module.patch
+revert-bluetooth-mgmt-smp-fix-address-type-when-using-smp-over-bredr-le.patch
+bluetooth-mgmt-ignore-keys-being-loaded-with-invalid-type.patch
+mmc-core-apply-sd-quirks-earlier-during-probe.patch
+mmc-dw_mmc-fix-idmac-operation-with-pages-bigger-than-4k.patch
+mmc-sdhci-of-aspeed-fix-module-autoloading.patch
+mmc-cqhci-fix-checking-of-cqhci_halt-state.patch
+fuse-update-stats-for-pages-in-dropped-aux-writeback-list.patch
+fuse-use-unsigned-type-for-getxattr-listxattr-size-truncation.patch
+fuse-fix-memory-leak-in-fuse_create_open.patch