--- /dev/null
+From b5e6fa7a12572c82f1e7f2f51fbb02a322291291 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:39:44 +0200
+Subject: Bluetooth: bfusb: fix division by zero in send path
+
+From: Johan Hovold <johan@kernel.org>
+
+commit b5e6fa7a12572c82f1e7f2f51fbb02a322291291 upstream.
+
+Add the missing bulk-out endpoint sanity check to probe() to avoid
+division by zero in bfusb_send_frame() in case a malicious device has
+broken descriptors (or when doing descriptor fuzz testing).
+
+Note that USB core will reject URBs submitted for endpoints with zero
+wMaxPacketSize but that drivers doing packet-size calculations still
+need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
+endpoint descriptors with maxpacket=0")).
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/bfusb.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/bluetooth/bfusb.c
++++ b/drivers/bluetooth/bfusb.c
+@@ -629,6 +629,9 @@ static int bfusb_probe(struct usb_interf
+ data->bulk_out_ep = bulk_out_ep->desc.bEndpointAddress;
+ data->bulk_pkt_size = le16_to_cpu(bulk_out_ep->desc.wMaxPacketSize);
+
++ if (!data->bulk_pkt_size)
++ goto done;
++
+ rwlock_init(&data->lock);
+
+ data->reassembly = NULL;
--- /dev/null
+From 60c6a63a3d3080a62f3e0e20084f58dbeff16748 Mon Sep 17 00:00:00 2001
+From: "Mark-YW.Chen" <mark-yw.chen@mediatek.com>
+Date: Thu, 14 Oct 2021 00:22:04 +0800
+Subject: Bluetooth: btusb: fix memory leak in btusb_mtk_submit_wmt_recv_urb()
+
+From: Mark-YW.Chen <mark-yw.chen@mediatek.com>
+
+commit 60c6a63a3d3080a62f3e0e20084f58dbeff16748 upstream.
+
+Driver should free `usb->setup_packet` to avoid the leak.
+
+$ cat /sys/kernel/debug/kmemleak
+unreferenced object 0xffffffa564a58080 (size 128):
+ backtrace:
+ [<000000007eb8dd70>] kmem_cache_alloc_trace+0x22c/0x384
+ [<000000008a44191d>] btusb_mtk_hci_wmt_sync+0x1ec/0x994
+ [btusb]
+ [<00000000ca7189a3>] btusb_mtk_setup+0x6b8/0x13cc
+ [btusb]
+ [<00000000c6105069>] hci_dev_do_open+0x290/0x974
+ [bluetooth]
+ [<00000000a583f8b8>] hci_power_on+0xdc/0x3cc [bluetooth]
+ [<000000005d80e687>] process_one_work+0x514/0xc80
+ [<00000000f4d57637>] worker_thread+0x818/0xd0c
+ [<00000000dc7bdb55>] kthread+0x2f8/0x3b8
+ [<00000000f9999513>] ret_from_fork+0x10/0x30
+
+Fixes: a1c49c434e150 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
+Signed-off-by: Mark-YW.Chen <mark-yw.chen@mediatek.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/btusb.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -2568,6 +2568,7 @@ static void btusb_mtk_wmt_recv(struct ur
+ skb = bt_skb_alloc(HCI_WMT_MAX_EVENT_SIZE, GFP_ATOMIC);
+ if (!skb) {
+ hdev->stat.err_rx++;
++ kfree(urb->setup_packet);
+ return;
+ }
+
+@@ -2588,6 +2589,7 @@ static void btusb_mtk_wmt_recv(struct ur
+ data->evt_skb = skb_clone(skb, GFP_ATOMIC);
+ if (!data->evt_skb) {
+ kfree_skb(skb);
++ kfree(urb->setup_packet);
+ return;
+ }
+ }
+@@ -2596,6 +2598,7 @@ static void btusb_mtk_wmt_recv(struct ur
+ if (err < 0) {
+ kfree_skb(data->evt_skb);
+ data->evt_skb = NULL;
++ kfree(urb->setup_packet);
+ return;
+ }
+
+@@ -2606,6 +2609,7 @@ static void btusb_mtk_wmt_recv(struct ur
+ wake_up_bit(&data->flags,
+ BTUSB_TX_WAIT_VND_EVT);
+ }
++ kfree(urb->setup_packet);
+ return;
+ } else if (urb->status == -ENOENT) {
+ /* Avoid suspend failed when usb_kill_urb */
+@@ -2626,6 +2630,7 @@ static void btusb_mtk_wmt_recv(struct ur
+ usb_anchor_urb(urb, &data->ctrl_anchor);
+ err = usb_submit_urb(urb, GFP_ATOMIC);
+ if (err < 0) {
++ kfree(urb->setup_packet);
+ /* -EPERM: urb is being killed;
+ * -ENODEV: device got disconnected
+ */
--- /dev/null
+From e53e97f805cb1abeea000a61549d42f92cb10804 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Wed, 24 Nov 2021 11:48:50 +0200
+Subject: mmc: sdhci-pci: Add PCI ID for Intel ADL
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit e53e97f805cb1abeea000a61549d42f92cb10804 upstream.
+
+Add PCI ID for Intel ADL eMMC host controller.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20211124094850.1783220-1-adrian.hunter@intel.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-pci-core.c | 1 +
+ drivers/mmc/host/sdhci-pci.h | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-pci-core.c
++++ b/drivers/mmc/host/sdhci-pci-core.c
+@@ -1936,6 +1936,7 @@ static const struct pci_device_id pci_id
+ SDHCI_PCI_DEVICE(INTEL, JSL_SD, intel_byt_sd),
+ SDHCI_PCI_DEVICE(INTEL, LKF_EMMC, intel_glk_emmc),
+ SDHCI_PCI_DEVICE(INTEL, LKF_SD, intel_byt_sd),
++ SDHCI_PCI_DEVICE(INTEL, ADL_EMMC, intel_glk_emmc),
+ SDHCI_PCI_DEVICE(O2, 8120, o2),
+ SDHCI_PCI_DEVICE(O2, 8220, o2),
+ SDHCI_PCI_DEVICE(O2, 8221, o2),
+--- a/drivers/mmc/host/sdhci-pci.h
++++ b/drivers/mmc/host/sdhci-pci.h
+@@ -59,6 +59,7 @@
+ #define PCI_DEVICE_ID_INTEL_JSL_SD 0x4df8
+ #define PCI_DEVICE_ID_INTEL_LKF_EMMC 0x98c4
+ #define PCI_DEVICE_ID_INTEL_LKF_SD 0x98f8
++#define PCI_DEVICE_ID_INTEL_ADL_EMMC 0x54c4
+
+ #define PCI_DEVICE_ID_SYSKONNECT_8000 0x8000
+ #define PCI_DEVICE_ID_VIA_95D0 0x95d0
workqueue-fix-unbind_workers-vs-wq_worker_running-race.patch
+bluetooth-btusb-fix-memory-leak-in-btusb_mtk_submit_wmt_recv_urb.patch
+bluetooth-bfusb-fix-division-by-zero-in-send-path.patch
+usb-core-fix-bug-in-resuming-hub-s-handling-of-wakeup-requests.patch
+usb-fix-slab-out-of-bounds-write-bug-in-usb_hcd_poll_rh_status.patch
+mmc-sdhci-pci-add-pci-id-for-intel-adl.patch
--- /dev/null
+From 0f663729bb4afc92a9986b66131ebd5b8a9254d1 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Sat, 1 Jan 2022 14:52:14 -0500
+Subject: USB: core: Fix bug in resuming hub's handling of wakeup requests
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 0f663729bb4afc92a9986b66131ebd5b8a9254d1 upstream.
+
+Bugzilla #213839 reports a 7-port hub that doesn't work properly when
+devices are plugged into some of the ports; the kernel goes into an
+unending disconnect/reinitialize loop as shown in the bug report.
+
+This "7-port hub" comprises two four-port hubs with one plugged into
+the other; the failures occur when a device is plugged into one of the
+downstream hub's ports. (These hubs have other problems too. For
+example, they bill themselves as USB-2.0 compliant but they only run
+at full speed.)
+
+It turns out that the failures are caused by bugs in both the kernel
+and the hub. The hub's bug is that it reports a different
+bmAttributes value in its configuration descriptor following a remote
+wakeup (0xe0 before, 0xc0 after -- the wakeup-support bit has
+changed).
+
+The kernel's bug is inside the hub driver's resume handler. When
+hub_activate() sees that one of the hub's downstream ports got a
+wakeup request from a child device, it notes this fact by setting the
+corresponding bit in the hub->change_bits variable. But this variable
+is meant for connection changes, not wakeup events; setting it causes
+the driver to believe the downstream port has been disconnected and
+then connected again (in addition to having received a wakeup
+request).
+
+Because of this, the hub driver then tries to check whether the device
+currently plugged into the downstream port is the same as the device
+that had been attached there before. Normally this check succeeds and
+wakeup handling continues with no harm done (which is why the bug
+remained undetected until now). But with these dodgy hubs, the check
+fails because the config descriptor has changed. This causes the hub
+driver to reinitialize the child device, leading to the
+disconnect/reinitialize loop described in the bug report.
+
+The proper way to note reception of a downstream wakeup request is
+to set a bit in the hub->event_bits variable instead of
+hub->change_bits. That way the hub driver will realize that something
+has happened to the port but will not think the port and child device
+have been disconnected. This patch makes that change.
+
+Cc: <stable@vger.kernel.org>
+Tested-by: Jonathan McDowell <noodles@earth.li>
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/YdCw7nSfWYPKWQoD@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/hub.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -1223,7 +1223,7 @@ static void hub_activate(struct usb_hub
+ */
+ if (portchange || (hub_is_superspeed(hub->hdev) &&
+ port_resumed))
+- set_bit(port1, hub->change_bits);
++ set_bit(port1, hub->event_bits);
+
+ } else if (udev->persist_enabled) {
+ #ifdef CONFIG_PM
--- /dev/null
+From 1d7d4c07932e04355d6e6528d44a2f2c9e354346 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 31 Dec 2021 21:07:12 -0500
+Subject: USB: Fix "slab-out-of-bounds Write" bug in usb_hcd_poll_rh_status
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 1d7d4c07932e04355d6e6528d44a2f2c9e354346 upstream.
+
+When the USB core code for getting root-hub status reports was
+originally written, it was assumed that the hub driver would be its
+only caller. But this isn't true now; user programs can use usbfs to
+communicate with root hubs and get status reports. When they do this,
+they may use a transfer_buffer that is smaller than the data returned
+by the HCD, which will lead to a buffer overflow error when
+usb_hcd_poll_rh_status() tries to store the status data. This was
+discovered by syzbot:
+
+BUG: KASAN: slab-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]
+BUG: KASAN: slab-out-of-bounds in usb_hcd_poll_rh_status+0x5f4/0x780 drivers/usb/core/hcd.c:776
+Write of size 2 at addr ffff88801da403c0 by task syz-executor133/4062
+
+This patch fixes the bug by reducing the amount of status data if it
+won't fit in the transfer_buffer. If some data gets discarded then
+the URB's completion status is set to -EOVERFLOW rather than 0, to let
+the user know what happened.
+
+Reported-and-tested-by: syzbot+3ae6a2b06f131ab9849f@syzkaller.appspotmail.com
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/Yc+3UIQJ2STbxNua@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/hcd.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/core/hcd.c
++++ b/drivers/usb/core/hcd.c
+@@ -753,6 +753,7 @@ void usb_hcd_poll_rh_status(struct usb_h
+ {
+ struct urb *urb;
+ int length;
++ int status;
+ unsigned long flags;
+ char buffer[6]; /* Any root hubs with > 31 ports? */
+
+@@ -770,11 +771,17 @@ void usb_hcd_poll_rh_status(struct usb_h
+ if (urb) {
+ clear_bit(HCD_FLAG_POLL_PENDING, &hcd->flags);
+ hcd->status_urb = NULL;
++ if (urb->transfer_buffer_length >= length) {
++ status = 0;
++ } else {
++ status = -EOVERFLOW;
++ length = urb->transfer_buffer_length;
++ }
+ urb->actual_length = length;
+ memcpy(urb->transfer_buffer, buffer, length);
+
+ usb_hcd_unlink_urb_from_ep(hcd, urb);
+- usb_hcd_giveback_urb(hcd, urb, 0);
++ usb_hcd_giveback_urb(hcd, urb, status);
+ } else {
+ length = 0;
+ set_bit(HCD_FLAG_POLL_PENDING, &hcd->flags);
projects / thirdparty / kernel / stable-queue.git / commitdiff
