--- /dev/null
+From 56446f218af1133c802dad8e9e116f07f381846c Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 6 Sep 2018 12:48:22 +0300
+Subject: CIFS: fix wrapping bugs in num_entries()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 56446f218af1133c802dad8e9e116f07f381846c upstream.
+
+The problem is that "entryptr + next_offset" and "entryptr + len + size"
+can wrap. I ended up changing the type of "entryptr" because it makes
+the math easier when we don't have to do so much casting.
+
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb2pdu.c | 25 +++++++++++++++----------
+ 1 file changed, 15 insertions(+), 10 deletions(-)
+
+--- a/fs/cifs/smb2pdu.c
++++ b/fs/cifs/smb2pdu.c
+@@ -2565,33 +2565,38 @@ num_entries(char *bufstart, char *end_of
+ int len;
+ unsigned int entrycount = 0;
+ unsigned int next_offset = 0;
+- FILE_DIRECTORY_INFO *entryptr;
++ char *entryptr;
++ FILE_DIRECTORY_INFO *dir_info;
+
+ if (bufstart == NULL)
+ return 0;
+
+- entryptr = (FILE_DIRECTORY_INFO *)bufstart;
++ entryptr = bufstart;
+
+ while (1) {
+- entryptr = (FILE_DIRECTORY_INFO *)
+- ((char *)entryptr + next_offset);
+-
+- if ((char *)entryptr + size > end_of_buf) {
++ if (entryptr + next_offset < entryptr ||
++ entryptr + next_offset > end_of_buf ||
++ entryptr + next_offset + size > end_of_buf) {
+ cifs_dbg(VFS, "malformed search entry would overflow\n");
+ break;
+ }
+
+- len = le32_to_cpu(entryptr->FileNameLength);
+- if ((char *)entryptr + len + size > end_of_buf) {
++ entryptr = entryptr + next_offset;
++ dir_info = (FILE_DIRECTORY_INFO *)entryptr;
++
++ len = le32_to_cpu(dir_info->FileNameLength);
++ if (entryptr + len < entryptr ||
++ entryptr + len > end_of_buf ||
++ entryptr + len + size > end_of_buf) {
+ cifs_dbg(VFS, "directory entry name would overflow frame end of buf %p\n",
+ end_of_buf);
+ break;
+ }
+
+- *lastentry = (char *)entryptr;
++ *lastentry = entryptr;
+ entrycount++;
+
+- next_offset = le32_to_cpu(entryptr->NextEntryOffset);
++ next_offset = le32_to_cpu(dir_info->NextEntryOffset);
+ if (!next_offset)
+ break;
+ }
--- /dev/null
+From 8ad8aa353524d89fa2e09522f3078166ff78ec42 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 6 Sep 2018 12:47:51 +0300
+Subject: cifs: prevent integer overflow in nxt_dir_entry()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 8ad8aa353524d89fa2e09522f3078166ff78ec42 upstream.
+
+The "old_entry + le32_to_cpu(pDirInfo->NextEntryOffset)" can wrap
+around so I have added a check for integer overflow.
+
+Reported-by: Dr Silvio Cesare of InfoSect <silvio.cesare@gmail.com>
+Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/readdir.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+--- a/fs/cifs/readdir.c
++++ b/fs/cifs/readdir.c
+@@ -376,8 +376,15 @@ static char *nxt_dir_entry(char *old_ent
+
+ new_entry = old_entry + sizeof(FIND_FILE_STANDARD_INFO) +
+ pfData->FileNameLength;
+- } else
+- new_entry = old_entry + le32_to_cpu(pDirInfo->NextEntryOffset);
++ } else {
++ u32 next_offset = le32_to_cpu(pDirInfo->NextEntryOffset);
++
++ if (old_entry + next_offset < old_entry) {
++ cifs_dbg(VFS, "invalid offset %u\n", next_offset);
++ return NULL;
++ }
++ new_entry = old_entry + next_offset;
++ }
+ cifs_dbg(FYI, "new entry %p old entry %p\n", new_entry, old_entry);
+ /* validate that new_entry is not past end of SMB */
+ if (new_entry >= end_of_smb) {
--- /dev/null
+From 816e846c2eb9129a3e0afa5f920c8bbc71efecaa Mon Sep 17 00:00:00 2001
+From: Aaron Knister <aaron.s.knister@nasa.gov>
+Date: Fri, 24 Aug 2018 08:42:46 -0400
+Subject: IB/ipoib: Avoid a race condition between start_xmit and cm_rep_handler
+
+From: Aaron Knister <aaron.s.knister@nasa.gov>
+
+commit 816e846c2eb9129a3e0afa5f920c8bbc71efecaa upstream.
+
+Inside of start_xmit() the call to check if the connection is up and the
+queueing of the packets for later transmission is not atomic which leaves
+a window where cm_rep_handler can run, set the connection up, dequeue
+pending packets and leave the subsequently queued packets by start_xmit()
+sitting on neigh->queue until they're dropped when the connection is torn
+down. This only applies to connected mode. These dropped packets can
+really upset TCP, for example, and cause multi-minute delays in
+transmission for open connections.
+
+Here's the code in start_xmit where we check to see if the connection is
+up:
+
+ if (ipoib_cm_get(neigh)) {
+ if (ipoib_cm_up(neigh)) {
+ ipoib_cm_send(dev, skb, ipoib_cm_get(neigh));
+ goto unref;
+ }
+ }
+
+The race occurs if cm_rep_handler execution occurs after the above
+connection check (specifically if it gets to the point where it acquires
+priv->lock to dequeue pending skb's) but before the below code snippet in
+start_xmit where packets are queued.
+
+ if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ push_pseudo_header(skb, phdr->hwaddr);
+ spin_lock_irqsave(&priv->lock, flags);
+ __skb_queue_tail(&neigh->queue, skb);
+ spin_unlock_irqrestore(&priv->lock, flags);
+ } else {
+ ++dev->stats.tx_dropped;
+ dev_kfree_skb_any(skb);
+ }
+
+The patch acquires the netif tx lock in cm_rep_handler for the section
+where it sets the connection up and dequeues and retransmits deferred
+skb's.
+
+Fixes: 839fcaba355a ("IPoIB: Connected mode experimental support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Aaron Knister <aaron.s.knister@nasa.gov>
+Tested-by: Ira Weiny <ira.weiny@intel.com>
+Reviewed-by: Ira Weiny <ira.weiny@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
++++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+@@ -1009,12 +1009,14 @@ static int ipoib_cm_rep_handler(struct i
+
+ skb_queue_head_init(&skqueue);
+
++ netif_tx_lock_bh(p->dev);
+ spin_lock_irq(&priv->lock);
+ set_bit(IPOIB_FLAG_OPER_UP, &p->flags);
+ if (p->neigh)
+ while ((skb = __skb_dequeue(&p->neigh->queue)))
+ __skb_queue_tail(&skqueue, skb);
+ spin_unlock_irq(&priv->lock);
++ netif_tx_unlock_bh(p->dev);
+
+ while ((skb = __skb_dequeue(&skqueue))) {
+ skb->dev = p->dev;
--- /dev/null
+From c86ba91be75702c013bbf7379542920b6920e98f Mon Sep 17 00:00:00 2001
+From: Corey Minyard <cminyard@mvista.com>
+Date: Thu, 23 Aug 2018 15:22:35 -0500
+Subject: ipmi: Move BT capabilities detection to the detect call
+
+From: Corey Minyard <cminyard@mvista.com>
+
+commit c86ba91be75702c013bbf7379542920b6920e98f upstream.
+
+The capabilities detection was being done as part of the normal
+state machine, but it was possible for it to be running while
+the upper layers of the IPMI driver were initializing the
+device, resulting in error and failure to initialize.
+
+Move the capabilities detection to the the detect function,
+so it's done before anything else runs on the device. This also
+simplifies the state machine and removes some code, as a bonus.
+
+Signed-off-by: Corey Minyard <cminyard@mvista.com>
+Reported-by: Andrew Banman <abanman@hpe.com>
+Tested-by: Andrew Banman <abanman@hpe.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/ipmi/ipmi_bt_sm.c | 92 +++++++++++++++++++++--------------------
+ 1 file changed, 48 insertions(+), 44 deletions(-)
+
+--- a/drivers/char/ipmi/ipmi_bt_sm.c
++++ b/drivers/char/ipmi/ipmi_bt_sm.c
+@@ -77,8 +77,6 @@ enum bt_states {
+ BT_STATE_RESET3,
+ BT_STATE_RESTART,
+ BT_STATE_PRINTME,
+- BT_STATE_CAPABILITIES_BEGIN,
+- BT_STATE_CAPABILITIES_END,
+ BT_STATE_LONG_BUSY /* BT doesn't get hosed :-) */
+ };
+
+@@ -104,7 +102,6 @@ struct si_sm_data {
+ int error_retries; /* end of "common" fields */
+ int nonzero_status; /* hung BMCs stay all 0 */
+ enum bt_states complete; /* to divert the state machine */
+- int BT_CAP_outreqs;
+ long BT_CAP_req2rsp;
+ int BT_CAP_retries; /* Recommended retries */
+ };
+@@ -155,8 +152,6 @@ static char *state2txt(unsigned char sta
+ case BT_STATE_RESET3: return("RESET3");
+ case BT_STATE_RESTART: return("RESTART");
+ case BT_STATE_LONG_BUSY: return("LONG_BUSY");
+- case BT_STATE_CAPABILITIES_BEGIN: return("CAP_BEGIN");
+- case BT_STATE_CAPABILITIES_END: return("CAP_END");
+ }
+ return("BAD STATE");
+ }
+@@ -203,7 +198,6 @@ static unsigned int bt_init_data(struct
+ bt->complete = BT_STATE_IDLE; /* end here */
+ bt->BT_CAP_req2rsp = BT_NORMAL_TIMEOUT * USEC_PER_SEC;
+ bt->BT_CAP_retries = BT_NORMAL_RETRY_LIMIT;
+- /* BT_CAP_outreqs == zero is a flag to read BT Capabilities */
+ return 3; /* We claim 3 bytes of space; ought to check SPMI table */
+ }
+
+@@ -469,7 +463,7 @@ static enum si_sm_result error_recovery(
+
+ static enum si_sm_result bt_event(struct si_sm_data *bt, long time)
+ {
+- unsigned char status, BT_CAP[8];
++ unsigned char status;
+ static enum bt_states last_printed = BT_STATE_PRINTME;
+ int i;
+
+@@ -522,12 +516,6 @@ static enum si_sm_result bt_event(struct
+ if (status & BT_H_BUSY) /* clear a leftover H_BUSY */
+ BT_CONTROL(BT_H_BUSY);
+
+- bt->timeout = bt->BT_CAP_req2rsp;
+-
+- /* Read BT capabilities if it hasn't been done yet */
+- if (!bt->BT_CAP_outreqs)
+- BT_STATE_CHANGE(BT_STATE_CAPABILITIES_BEGIN,
+- SI_SM_CALL_WITHOUT_DELAY);
+ BT_SI_SM_RETURN(SI_SM_IDLE);
+
+ case BT_STATE_XACTION_START:
+@@ -632,37 +620,6 @@ static enum si_sm_result bt_event(struct
+ BT_STATE_CHANGE(BT_STATE_XACTION_START,
+ SI_SM_CALL_WITH_DELAY);
+
+- /*
+- * Get BT Capabilities, using timing of upper level state machine.
+- * Set outreqs to prevent infinite loop on timeout.
+- */
+- case BT_STATE_CAPABILITIES_BEGIN:
+- bt->BT_CAP_outreqs = 1;
+- {
+- unsigned char GetBT_CAP[] = { 0x18, 0x36 };
+- bt->state = BT_STATE_IDLE;
+- bt_start_transaction(bt, GetBT_CAP, sizeof(GetBT_CAP));
+- }
+- bt->complete = BT_STATE_CAPABILITIES_END;
+- BT_STATE_CHANGE(BT_STATE_XACTION_START,
+- SI_SM_CALL_WITH_DELAY);
+-
+- case BT_STATE_CAPABILITIES_END:
+- i = bt_get_result(bt, BT_CAP, sizeof(BT_CAP));
+- bt_init_data(bt, bt->io);
+- if ((i == 8) && !BT_CAP[2]) {
+- bt->BT_CAP_outreqs = BT_CAP[3];
+- bt->BT_CAP_req2rsp = BT_CAP[6] * USEC_PER_SEC;
+- bt->BT_CAP_retries = BT_CAP[7];
+- } else
+- printk(KERN_WARNING "IPMI BT: using default values\n");
+- if (!bt->BT_CAP_outreqs)
+- bt->BT_CAP_outreqs = 1;
+- printk(KERN_WARNING "IPMI BT: req2rsp=%ld secs retries=%d\n",
+- bt->BT_CAP_req2rsp / USEC_PER_SEC, bt->BT_CAP_retries);
+- bt->timeout = bt->BT_CAP_req2rsp;
+- return SI_SM_CALL_WITHOUT_DELAY;
+-
+ default: /* should never occur */
+ return error_recovery(bt,
+ status,
+@@ -673,6 +630,11 @@ static enum si_sm_result bt_event(struct
+
+ static int bt_detect(struct si_sm_data *bt)
+ {
++ unsigned char GetBT_CAP[] = { 0x18, 0x36 };
++ unsigned char BT_CAP[8];
++ enum si_sm_result smi_result;
++ int rv;
++
+ /*
+ * It's impossible for the BT status and interrupt registers to be
+ * all 1's, (assuming a properly functioning, self-initialized BMC)
+@@ -683,6 +645,48 @@ static int bt_detect(struct si_sm_data *
+ if ((BT_STATUS == 0xFF) && (BT_INTMASK_R == 0xFF))
+ return 1;
+ reset_flags(bt);
++
++ /*
++ * Try getting the BT capabilities here.
++ */
++ rv = bt_start_transaction(bt, GetBT_CAP, sizeof(GetBT_CAP));
++ if (rv) {
++ dev_warn(bt->io->dev,
++ "Can't start capabilities transaction: %d\n", rv);
++ goto out_no_bt_cap;
++ }
++
++ smi_result = SI_SM_CALL_WITHOUT_DELAY;
++ for (;;) {
++ if (smi_result == SI_SM_CALL_WITH_DELAY ||
++ smi_result == SI_SM_CALL_WITH_TICK_DELAY) {
++ schedule_timeout_uninterruptible(1);
++ smi_result = bt_event(bt, jiffies_to_usecs(1));
++ } else if (smi_result == SI_SM_CALL_WITHOUT_DELAY) {
++ smi_result = bt_event(bt, 0);
++ } else
++ break;
++ }
++
++ rv = bt_get_result(bt, BT_CAP, sizeof(BT_CAP));
++ bt_init_data(bt, bt->io);
++ if (rv < 8) {
++ dev_warn(bt->io->dev, "bt cap response too short: %d\n", rv);
++ goto out_no_bt_cap;
++ }
++
++ if (BT_CAP[2]) {
++ dev_warn(bt->io->dev, "Error fetching bt cap: %x\n", BT_CAP[2]);
++out_no_bt_cap:
++ dev_warn(bt->io->dev, "using default values\n");
++ } else {
++ bt->BT_CAP_req2rsp = BT_CAP[6] * USEC_PER_SEC;
++ bt->BT_CAP_retries = BT_CAP[7];
++ }
++
++ dev_info(bt->io->dev, "req2rsp=%ld secs retries=%d\n",
++ bt->BT_CAP_req2rsp / USEC_PER_SEC, bt->BT_CAP_retries);
++
+ return 0;
+ }
+
--- /dev/null
+From 8d2d8935d30cc2acc57a3196dc10dfa8d5cbcdab Mon Sep 17 00:00:00 2001
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+Date: Mon, 6 Aug 2018 17:47:33 +0300
+Subject: mei: ignore not found client in the enumeration
+
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+
+commit 8d2d8935d30cc2acc57a3196dc10dfa8d5cbcdab upstream.
+
+Some of the ME clients are available only for BIOS operation and are
+removed during hand off to an OS. However the removal is not instant.
+A client may be visible on the client list when the mei driver requests
+for enumeration, while the subsequent request for properties will be
+answered with client not found error value. The default behavior
+for an error is to perform client reset while this error is harmless and
+the link reset should be prevented. This issue started to be visible due to
+suspend/resume timing changes. Currently reported only on the Haswell
+based system.
+
+Fixes:
+[33.564957] mei_me 0000:00:16.0: hbm: properties response: wrong status = 1 CLIENT_NOT_FOUND
+[33.564978] mei_me 0000:00:16.0: mei_irq_read_handler ret = -71.
+[33.565270] mei_me 0000:00:16.0: unexpected reset: dev_state = INIT_CLIENTS fw status = 1E000255 60002306 00000200 00004401 00000000 00000010
+
+Cc: <stable@vger.kernel.org>
+Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
+Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
+Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/mei/hbm.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/misc/mei/hbm.c
++++ b/drivers/misc/mei/hbm.c
+@@ -1137,15 +1137,18 @@ int mei_hbm_dispatch(struct mei_device *
+
+ props_res = (struct hbm_props_response *)mei_msg;
+
+- if (props_res->status) {
++ if (props_res->status == MEI_HBMS_CLIENT_NOT_FOUND) {
++ dev_dbg(dev->dev, "hbm: properties response: %d CLIENT_NOT_FOUND\n",
++ props_res->me_addr);
++ } else if (props_res->status) {
+ dev_err(dev->dev, "hbm: properties response: wrong status = %d %s\n",
+ props_res->status,
+ mei_hbm_status_str(props_res->status));
+ return -EPROTO;
++ } else {
++ mei_hbm_me_cl_add(dev, props_res);
+ }
+
+- mei_hbm_me_cl_add(dev, props_res);
+-
+ /* request property for the next client */
+ if (mei_hbm_prop_req(dev, props_res->me_addr + 1))
+ return -EIO;
--- /dev/null
+From de916736aaaadddbd6061472969f667b14204aa9 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Wed, 15 Aug 2018 10:50:41 -0500
+Subject: misc: hmc6352: fix potential Spectre v1
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit de916736aaaadddbd6061472969f667b14204aa9 upstream.
+
+val is indirectly controlled by user-space, hence leading to a
+potential exploitation of the Spectre variant 1 vulnerability.
+
+This issue was detected with the help of Smatch:
+
+drivers/misc/hmc6352.c:54 compass_store() warn: potential spectre issue
+'map' [r]
+
+Fix this by sanitizing val before using it to index map
+
+Notice that given that speculation windows are large, the policy is
+to kill the speculation on the first load and not worry if it can be
+completed with a dependent load/store [1].
+
+[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/misc/hmc6352.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/misc/hmc6352.c
++++ b/drivers/misc/hmc6352.c
+@@ -27,6 +27,7 @@
+ #include <linux/err.h>
+ #include <linux/delay.h>
+ #include <linux/sysfs.h>
++#include <linux/nospec.h>
+
+ static DEFINE_MUTEX(compass_mutex);
+
+@@ -50,6 +51,7 @@ static int compass_store(struct device *
+ return ret;
+ if (val >= strlen(map))
+ return -EINVAL;
++ val = array_index_nospec(val, strlen(map));
+ mutex_lock(&compass_mutex);
+ ret = compass_command(c, map[val]);
+ mutex_unlock(&compass_mutex);
--- /dev/null
+From 3c398f3c3bef21961eaaeb93227fa66d440dc83d Mon Sep 17 00:00:00 2001
+From: Andreas Kemnade <andreas@kemnade.info>
+Date: Sun, 2 Sep 2018 09:30:58 +0200
+Subject: mmc: omap_hsmmc: fix wakeirq handling on removal
+
+From: Andreas Kemnade <andreas@kemnade.info>
+
+commit 3c398f3c3bef21961eaaeb93227fa66d440dc83d upstream.
+
+after unbinding mmc I get things like this:
+[ 185.294067] mmc1: card 0001 removed
+[ 185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -13
+
+The wakeirq stays in /proc-interrupts
+
+rebinding shows this:
+[ 289.795959] genirq: Flags mismatch irq 112. 0000200a (480b4000.mmc:wakeup) vs. 0000200a (480b4000.mmc:wakeup)
+[ 289.808959] omap_hsmmc 480b4000.mmc: Unable to request wake IRQ
+[ 289.815338] omap_hsmmc 480b4000.mmc: no SDIO IRQ support, falling back to polling
+
+That bug seems to be introduced by switching from devm_request_irq()
+to generic wakeirq handling.
+
+So let us cleanup at removal.
+
+Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
+Fixes: 5b83b2234be6 ("mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq")
+Cc: stable@vger.kernel.org # v4.2+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/omap_hsmmc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mmc/host/omap_hsmmc.c
++++ b/drivers/mmc/host/omap_hsmmc.c
+@@ -2215,6 +2215,7 @@ static int omap_hsmmc_remove(struct plat
+ dma_release_channel(host->tx_chan);
+ dma_release_channel(host->rx_chan);
+
++ dev_pm_clear_wake_irq(host->dev);
+ pm_runtime_dont_use_autosuspend(host->dev);
+ pm_runtime_put_sync(host->dev);
+ pm_runtime_disable(host->dev);
--- /dev/null
+From 994b15b983a72e1148a173b61e5b279219bb45ae Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trondmy@gmail.com>
+Date: Wed, 5 Sep 2018 14:07:14 -0400
+Subject: NFSv4.1 fix infinite loop on I/O.
+
+From: Trond Myklebust <trondmy@gmail.com>
+
+commit 994b15b983a72e1148a173b61e5b279219bb45ae upstream.
+
+The previous fix broke recovery of delegated stateids because it assumes
+that if we did not mark the delegation as suspect, then the delegation has
+effectively been revoked, and so it removes that delegation irrespectively
+of whether or not it is valid and still in use. While this is "mostly
+harmless" for ordinary I/O, we've seen pNFS fail with LAYOUTGET spinning
+in an infinite loop while complaining that we're using an invalid stateid
+(in this case the all-zero stateid).
+
+What we rather want to do here is ensure that the delegation is always
+correctly marked as needing testing when that is the case. So we want
+to close the loophole offered by nfs4_schedule_stateid_recovery(),
+which marks the state as needing to be reclaimed, but not the
+delegation that may be backing it.
+
+Fixes: 0e3d3e5df07dc ("NFSv4.1 fix infinite loop on IO BAD_STATEID error")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Cc: stable@vger.kernel.org # v4.11+
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfs/nfs4proc.c | 10 +++++++---
+ fs/nfs/nfs4state.c | 2 ++
+ 2 files changed, 9 insertions(+), 3 deletions(-)
+
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -2539,14 +2539,18 @@ static void nfs41_check_delegation_state
+ }
+
+ nfs4_stateid_copy(&stateid, &delegation->stateid);
+- if (test_bit(NFS_DELEGATION_REVOKED, &delegation->flags) ||
+- !test_and_clear_bit(NFS_DELEGATION_TEST_EXPIRED,
+- &delegation->flags)) {
++ if (test_bit(NFS_DELEGATION_REVOKED, &delegation->flags)) {
+ rcu_read_unlock();
+ nfs_finish_clear_delegation_stateid(state, &stateid);
+ return;
+ }
+
++ if (!test_and_clear_bit(NFS_DELEGATION_TEST_EXPIRED,
++ &delegation->flags)) {
++ rcu_read_unlock();
++ return;
++ }
++
+ cred = get_rpccred(delegation->cred);
+ rcu_read_unlock();
+ status = nfs41_test_and_free_expired_stateid(server, &stateid, cred);
+--- a/fs/nfs/nfs4state.c
++++ b/fs/nfs/nfs4state.c
+@@ -1336,6 +1336,8 @@ int nfs4_schedule_stateid_recovery(const
+
+ if (!nfs4_state_mark_reclaim_nograce(clp, state))
+ return -EBADF;
++ nfs_inode_find_delegation_state_and_recover(state->inode,
++ &state->stateid);
+ dprintk("%s: scheduling stateid recovery for server %s\n", __func__,
+ clp->cl_hostname);
+ nfs4_schedule_state_manager(clp);
--- /dev/null
+From 02e184476eff848273826c1d6617bb37e5bcc7ad Mon Sep 17 00:00:00 2001
+From: Yabin Cui <yabinc@google.com>
+Date: Thu, 23 Aug 2018 15:59:35 -0700
+Subject: perf/core: Force USER_DS when recording user stack data
+
+From: Yabin Cui <yabinc@google.com>
+
+commit 02e184476eff848273826c1d6617bb37e5bcc7ad upstream.
+
+Perf can record user stack data in response to a synchronous request, such
+as a tracepoint firing. If this happens under set_fs(KERNEL_DS), then we
+end up reading user stack data using __copy_from_user_inatomic() under
+set_fs(KERNEL_DS). I think this conflicts with the intention of using
+set_fs(KERNEL_DS). And it is explicitly forbidden by hardware on ARM64
+when both CONFIG_ARM64_UAO and CONFIG_ARM64_PAN are used.
+
+So fix this by forcing USER_DS when recording user stack data.
+
+Signed-off-by: Yabin Cui <yabinc@google.com>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: <stable@vger.kernel.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Fixes: 88b0193d9418 ("perf/callchain: Force USER_DS when invoking perf_callchain_user()")
+Link: http://lkml.kernel.org/r/20180823225935.27035-1-yabinc@google.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/events/core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/kernel/events/core.c
++++ b/kernel/events/core.c
+@@ -5563,6 +5563,7 @@ perf_output_sample_ustack(struct perf_ou
+ unsigned long sp;
+ unsigned int rem;
+ u64 dyn_size;
++ mm_segment_t fs;
+
+ /*
+ * We dump:
+@@ -5580,7 +5581,10 @@ perf_output_sample_ustack(struct perf_ou
+
+ /* Data. */
+ sp = perf_user_stack_pointer(regs);
++ fs = get_fs();
++ set_fs(USER_DS);
+ rem = __output_copy_user(handle, (void *) sp, dump_size);
++ set_fs(fs);
+ dyn_size = dump_size - rem;
+
+ perf_output_skip(handle, rem);
--- /dev/null
+From 831b624df1b420c8f9281ed1307a8db23afb72df Mon Sep 17 00:00:00 2001
+From: Bin Yang <bin.yang@intel.com>
+Date: Wed, 12 Sep 2018 03:36:34 +0000
+Subject: pstore: Fix incorrect persistent ram buffer mapping
+
+From: Bin Yang <bin.yang@intel.com>
+
+commit 831b624df1b420c8f9281ed1307a8db23afb72df upstream.
+
+persistent_ram_vmap() returns the page start vaddr.
+persistent_ram_iomap() supports non-page-aligned mapping.
+
+persistent_ram_buffer_map() always adds offset-in-page to the vaddr
+returned from these two functions, which causes incorrect mapping of
+non-page-aligned persistent ram buffer.
+
+By default ftrace_size is 4096 and max_ftrace_cnt is nr_cpu_ids. Without
+this patch, the zone_sz in ramoops_init_przs() is 4096/nr_cpu_ids which
+might not be page aligned. If the offset-in-page > 2048, the vaddr will be
+in next page. If the next page is not mapped, it will cause kernel panic:
+
+[ 0.074231] BUG: unable to handle kernel paging request at ffffa19e0081b000
+...
+[ 0.075000] RIP: 0010:persistent_ram_new+0x1f8/0x39f
+...
+[ 0.075000] Call Trace:
+[ 0.075000] ramoops_init_przs.part.10.constprop.15+0x105/0x260
+[ 0.075000] ramoops_probe+0x232/0x3a0
+[ 0.075000] platform_drv_probe+0x3e/0xa0
+[ 0.075000] driver_probe_device+0x2cd/0x400
+[ 0.075000] __driver_attach+0xe4/0x110
+[ 0.075000] ? driver_probe_device+0x400/0x400
+[ 0.075000] bus_for_each_dev+0x70/0xa0
+[ 0.075000] driver_attach+0x1e/0x20
+[ 0.075000] bus_add_driver+0x159/0x230
+[ 0.075000] ? do_early_param+0x95/0x95
+[ 0.075000] driver_register+0x70/0xc0
+[ 0.075000] ? init_pstore_fs+0x4d/0x4d
+[ 0.075000] __platform_driver_register+0x36/0x40
+[ 0.075000] ramoops_init+0x12f/0x131
+[ 0.075000] do_one_initcall+0x4d/0x12c
+[ 0.075000] ? do_early_param+0x95/0x95
+[ 0.075000] kernel_init_freeable+0x19b/0x222
+[ 0.075000] ? rest_init+0xbb/0xbb
+[ 0.075000] kernel_init+0xe/0xfc
+[ 0.075000] ret_from_fork+0x3a/0x50
+
+Signed-off-by: Bin Yang <bin.yang@intel.com>
+[kees: add comments describing the mapping differences, updated commit log]
+Fixes: 24c3d2f342ed ("staging: android: persistent_ram: Make it possible to use memory outside of bootmem")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/pstore/ram_core.c | 17 ++++++++++++++---
+ 1 file changed, 14 insertions(+), 3 deletions(-)
+
+--- a/fs/pstore/ram_core.c
++++ b/fs/pstore/ram_core.c
+@@ -421,7 +421,12 @@ static void *persistent_ram_vmap(phys_ad
+ vaddr = vmap(pages, page_count, VM_MAP, prot);
+ kfree(pages);
+
+- return vaddr;
++ /*
++ * Since vmap() uses page granularity, we must add the offset
++ * into the page here, to get the byte granularity address
++ * into the mapping to represent the actual "start" location.
++ */
++ return vaddr + offset_in_page(start);
+ }
+
+ static void *persistent_ram_iomap(phys_addr_t start, size_t size,
+@@ -440,6 +445,11 @@ static void *persistent_ram_iomap(phys_a
+ else
+ va = ioremap_wc(start, size);
+
++ /*
++ * Since request_mem_region() and ioremap() are byte-granularity
++ * there is no need handle anything special like we do when the
++ * vmap() case in persistent_ram_vmap() above.
++ */
+ return va;
+ }
+
+@@ -460,7 +470,7 @@ static int persistent_ram_buffer_map(phy
+ return -ENOMEM;
+ }
+
+- prz->buffer = prz->vaddr + offset_in_page(start);
++ prz->buffer = prz->vaddr;
+ prz->buffer_size = size - sizeof(struct persistent_ram_buffer);
+
+ return 0;
+@@ -507,7 +517,8 @@ void persistent_ram_free(struct persiste
+
+ if (prz->vaddr) {
+ if (pfn_valid(prz->paddr >> PAGE_SHIFT)) {
+- vunmap(prz->vaddr);
++ /* We must vunmap() at page-granularity. */
++ vunmap(prz->vaddr - offset_in_page(prz->paddr));
+ } else {
+ iounmap(prz->vaddr);
+ release_mem_region(prz->paddr, prz->size);
--- /dev/null
+From 954a8e3aea87e896e320cf648c1a5bbe47de443e Mon Sep 17 00:00:00 2001
+From: Parav Pandit <parav@mellanox.com>
+Date: Thu, 30 Aug 2018 08:35:19 +0300
+Subject: RDMA/cma: Protect cma dev list with lock
+
+From: Parav Pandit <parav@mellanox.com>
+
+commit 954a8e3aea87e896e320cf648c1a5bbe47de443e upstream.
+
+When AF_IB addresses are used during rdma_resolve_addr() a lock is not
+held. A cma device can get removed while list traversal is in progress
+which may lead to crash. ie
+
+ CPU0 CPU1
+ ==== ====
+rdma_resolve_addr()
+ cma_resolve_ib_dev()
+ list_for_each() cma_remove_one()
+ cur_dev->device mutex_lock(&lock)
+ list_del();
+ mutex_unlock(&lock);
+ cma_process_remove();
+
+
+Therefore, hold a lock while traversing the list which avoids such
+situation.
+
+Cc: <stable@vger.kernel.org> # 3.10
+Fixes: f17df3b0dede ("RDMA/cma: Add support for AF_IB to rdma_resolve_addr()")
+Signed-off-by: Parav Pandit <parav@mellanox.com>
+Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
+Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
+Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/core/cma.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/infiniband/core/cma.c
++++ b/drivers/infiniband/core/cma.c
+@@ -673,6 +673,7 @@ static int cma_resolve_ib_dev(struct rdm
+ dgid = (union ib_gid *) &addr->sib_addr;
+ pkey = ntohs(addr->sib_pkey);
+
++ mutex_lock(&lock);
+ list_for_each_entry(cur_dev, &dev_list, list) {
+ for (p = 1; p <= cur_dev->device->phys_port_cnt; ++p) {
+ if (!rdma_cap_af_ib(cur_dev->device, p))
+@@ -696,18 +697,19 @@ static int cma_resolve_ib_dev(struct rdm
+ cma_dev = cur_dev;
+ sgid = gid;
+ id_priv->id.port_num = p;
++ goto found;
+ }
+ }
+ }
+ }
+-
+- if (!cma_dev)
+- return -ENODEV;
++ mutex_unlock(&lock);
++ return -ENODEV;
+
+ found:
+ cma_attach_to_dev(id_priv, cma_dev);
+- addr = (struct sockaddr_ib *) cma_src_addr(id_priv);
+- memcpy(&addr->sib_addr, &sgid, sizeof sgid);
++ mutex_unlock(&lock);
++ addr = (struct sockaddr_ib *)cma_src_addr(id_priv);
++ memcpy(&addr->sib_addr, &sgid, sizeof(sgid));
+ cma_translate_ib(addr, &id_priv->id.route.addr.dev_addr);
+ return 0;
+ }
--- /dev/null
+From df3aa13c7bbb307e172c37f193f9a7aa058d4739 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Wed, 5 Sep 2018 17:56:46 +0200
+Subject: Revert "cdc-acm: implement put_char() and flush_chars()"
+
+From: Oliver Neukum <oneukum@suse.com>
+
+commit df3aa13c7bbb307e172c37f193f9a7aa058d4739 upstream.
+
+This reverts commit a81cf9799ad7299b03a4dff020d9685f9ac5f3e0.
+
+The patch causes a regression, which I cannot find the reason for.
+So let's revert for now, as a revert hurts only performance.
+
+Original report:
+I was trying to resolve the problem with Oliver but we don't get any conclusion
+for 5 months, so I am now sending this to mail list and cdc_acm authors.
+
+I am using simple request-response protocol to obtain the boiller parameters
+in constant intervals.
+
+A simple one transaction is:
+1. opening the /dev/ttyACM0
+2. sending the following 10-bytes request to the device:
+ unsigned char req[] = {0x02, 0xfe, 0x01, 0x05, 0x08, 0x02, 0x01, 0x69, 0xab, 0x03};
+3. reading response (frame of 74 bytes length).
+4. closing the descriptor
+I am doing this transaction with 5 seconds intervals.
+
+Before the bad commit everything was working correctly: I've got a requests and
+a responses in a timely manner.
+
+After the bad commit more time I am using the kernel module, more problems I have.
+The graph [2] is showing the problem.
+
+As you can see after module load all seems fine but after about 30 minutes I've got
+a plenty of EAGAINs when doing read()'s and trying to read back the data.
+
+When I rmmod and insmod the cdc_acm module again, then the situation is starting
+over again: running ok shortly after load, and more time it is running, more EAGAINs
+I have when calling read().
+
+As a bonus I can see the problem on the device itself:
+The device is configured as you can see here on this screen [3].
+It has two transmision LEDs: TX and RX. Blink duration is set for 100ms.
+This is a recording before the bad commit when all is working fine: [4]
+And this is with the bad commit: [5]
+As you can see the TX led is blinking wrongly long (indicating transmission?)
+and I have problems doing read() calls (EAGAIN).
+
+Reported-by: Mariusz Bialonczyk <manio@skyboo.net>
+Signed-off-by: Oliver Neukum <oneukum@suse.com>
+Fixes: a81cf9799ad7 ("cdc-acm: implement put_char() and flush_chars()")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/class/cdc-acm.c | 73 --------------------------------------------
+ drivers/usb/class/cdc-acm.h | 1
+ 2 files changed, 74 deletions(-)
+
+--- a/drivers/usb/class/cdc-acm.c
++++ b/drivers/usb/class/cdc-acm.c
+@@ -705,20 +705,9 @@ static int acm_tty_write(struct tty_stru
+ }
+
+ if (acm->susp_count) {
+- if (acm->putbuffer) {
+- /* now to preserve order */
+- usb_anchor_urb(acm->putbuffer->urb, &acm->delayed);
+- acm->putbuffer = NULL;
+- }
+ usb_anchor_urb(wb->urb, &acm->delayed);
+ spin_unlock_irqrestore(&acm->write_lock, flags);
+ return count;
+- } else {
+- if (acm->putbuffer) {
+- /* at this point there is no good way to handle errors */
+- acm_start_wb(acm, acm->putbuffer);
+- acm->putbuffer = NULL;
+- }
+ }
+
+ stat = acm_start_wb(acm, wb);
+@@ -729,66 +718,6 @@ static int acm_tty_write(struct tty_stru
+ return count;
+ }
+
+-static void acm_tty_flush_chars(struct tty_struct *tty)
+-{
+- struct acm *acm = tty->driver_data;
+- struct acm_wb *cur;
+- int err;
+- unsigned long flags;
+-
+- spin_lock_irqsave(&acm->write_lock, flags);
+-
+- cur = acm->putbuffer;
+- if (!cur) /* nothing to do */
+- goto out;
+-
+- acm->putbuffer = NULL;
+- err = usb_autopm_get_interface_async(acm->control);
+- if (err < 0) {
+- cur->use = 0;
+- acm->putbuffer = cur;
+- goto out;
+- }
+-
+- if (acm->susp_count)
+- usb_anchor_urb(cur->urb, &acm->delayed);
+- else
+- acm_start_wb(acm, cur);
+-out:
+- spin_unlock_irqrestore(&acm->write_lock, flags);
+- return;
+-}
+-
+-static int acm_tty_put_char(struct tty_struct *tty, unsigned char ch)
+-{
+- struct acm *acm = tty->driver_data;
+- struct acm_wb *cur;
+- int wbn;
+- unsigned long flags;
+-
+-overflow:
+- cur = acm->putbuffer;
+- if (!cur) {
+- spin_lock_irqsave(&acm->write_lock, flags);
+- wbn = acm_wb_alloc(acm);
+- if (wbn >= 0) {
+- cur = &acm->wb[wbn];
+- acm->putbuffer = cur;
+- }
+- spin_unlock_irqrestore(&acm->write_lock, flags);
+- if (!cur)
+- return 0;
+- }
+-
+- if (cur->len == acm->writesize) {
+- acm_tty_flush_chars(tty);
+- goto overflow;
+- }
+-
+- cur->buf[cur->len++] = ch;
+- return 1;
+-}
+-
+ static int acm_tty_write_room(struct tty_struct *tty)
+ {
+ struct acm *acm = tty->driver_data;
+@@ -1940,8 +1869,6 @@ static const struct tty_operations acm_o
+ .cleanup = acm_tty_cleanup,
+ .hangup = acm_tty_hangup,
+ .write = acm_tty_write,
+- .put_char = acm_tty_put_char,
+- .flush_chars = acm_tty_flush_chars,
+ .write_room = acm_tty_write_room,
+ .ioctl = acm_tty_ioctl,
+ .throttle = acm_tty_throttle,
+--- a/drivers/usb/class/cdc-acm.h
++++ b/drivers/usb/class/cdc-acm.h
+@@ -94,7 +94,6 @@ struct acm {
+ unsigned long read_urbs_free;
+ struct urb *read_urbs[ACM_NR];
+ struct acm_rb read_buffers[ACM_NR];
+- struct acm_wb *putbuffer; /* for acm_tty_put_char() */
+ int rx_buflimit;
+ spinlock_t read_lock;
+ int write_used; /* number of non-empty write buffers */
dmaengine-mv_xor_v2-kill-the-tasklets-upon-exit.patch
crypto-sharah-unregister-correct-algorithms-for-sahara-3.patch
xen-netfront-fix-warn-message-as-irq-device-name-has.patch
+rdma-cma-protect-cma-dev-list-with-lock.patch
+pstore-fix-incorrect-persistent-ram-buffer-mapping.patch
+xen-netfront-fix-waiting-for-xenbus-state-change.patch
+ib-ipoib-avoid-a-race-condition-between-start_xmit-and-cm_rep_handler.patch
+mmc-omap_hsmmc-fix-wakeirq-handling-on-removal.patch
+ipmi-move-bt-capabilities-detection-to-the-detect-call.patch
+tools-hv-fix-a-bug-in-the-key-delete-code.patch
+misc-hmc6352-fix-potential-spectre-v1.patch
+usb-don-t-die-twice-if-pci-xhci-host-is-not-responding-in-resume.patch
+mei-ignore-not-found-client-in-the-enumeration.patch
+usb-add-quirk-to-support-dji-cinessd.patch
+usb-uas-add-support-for-more-quirk-flags.patch
+usb-avoid-use-after-free-by-flushing-endpoints-early-in-usb_set_interface.patch
+usb-host-u132-hcd-fix-a-sleep-in-atomic-context-bug-in-u132_get_frame.patch
+usb-add-quirk-for-worlde-controller-ks49-or-prodipe-midi-49c-usb-controller.patch
+usb-gadget-udc-renesas_usb3-fix-maxpacket-size-of-ep0.patch
+usb-net2280-fix-erroneous-synchronization-change.patch
+usb-serial-io_ti-fix-array-underflow-in-completion-handler.patch
+usb-misc-uss720-fix-two-sleep-in-atomic-context-bugs.patch
+usb-serial-ti_usb_3410_5052-fix-array-underflow-in-completion-handler.patch
+usb-yurex-fix-buffer-over-read-in-yurex_write.patch
+usb-cdc-wdm-fix-a-sleep-in-atomic-context-bug-in-service_outstanding_interrupt.patch
+revert-cdc-acm-implement-put_char-and-flush_chars.patch
+cifs-prevent-integer-overflow-in-nxt_dir_entry.patch
+cifs-fix-wrapping-bugs-in-num_entries.patch
+perf-core-force-user_ds-when-recording-user-stack-data.patch
+nfsv4.1-fix-infinite-loop-on-i-o.patch
--- /dev/null
+From 86503bd35dec0ce363e9fdbf5299927422ed3899 Mon Sep 17 00:00:00 2001
+From: "K. Y. Srinivasan" <kys@microsoft.com>
+Date: Fri, 10 Aug 2018 23:06:07 +0000
+Subject: Tools: hv: Fix a bug in the key delete code
+
+From: K. Y. Srinivasan <kys@microsoft.com>
+
+commit 86503bd35dec0ce363e9fdbf5299927422ed3899 upstream.
+
+Fix a bug in the key delete code - the num_records range
+from 0 to num_records-1.
+
+Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
+Reported-by: David Binderman <dcb314@hotmail.com>
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/hv/hv_kvp_daemon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/hv/hv_kvp_daemon.c
++++ b/tools/hv/hv_kvp_daemon.c
+@@ -286,7 +286,7 @@ static int kvp_key_delete(int pool, cons
+ * Found a match; just move the remaining
+ * entries up.
+ */
+- if (i == num_records) {
++ if (i == (num_records - 1)) {
+ kvp_file_info[pool].num_records--;
+ kvp_update_file(pool);
+ return 0;
--- /dev/null
+From 9b83a1c301ad6d24988a128c69b42cbaaf537d82 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Maxence=20Dupr=C3=A8s?= <xpros64@hotmail.fr>
+Date: Wed, 8 Aug 2018 23:56:33 +0000
+Subject: USB: add quirk for WORLDE Controller KS49 or Prodipe MIDI 49C USB controller
+
+From: Maxence Duprès <xpros64@hotmail.fr>
+
+commit 9b83a1c301ad6d24988a128c69b42cbaaf537d82 upstream.
+
+WORLDE Controller KS49 or Prodipe MIDI 49C USB controller
+cause a -EPROTO error, a communication restart and loop again.
+
+This issue has already been fixed for KS25.
+https://lore.kernel.org/patchwork/patch/753077/
+
+I just add device 201 for KS49 in quirks.c to get it works.
+
+Signed-off-by: Laurent Roux <xpros64@hotmail.fr>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/quirks.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/usb/core/quirks.c
++++ b/drivers/usb/core/quirks.c
+@@ -37,6 +37,10 @@ static const struct usb_device_id usb_qu
+ /* CBM - Flash disk */
+ { USB_DEVICE(0x0204, 0x6025), .driver_info = USB_QUIRK_RESET_RESUME },
+
++ /* WORLDE Controller KS49 or Prodipe MIDI 49C USB controller */
++ { USB_DEVICE(0x0218, 0x0201), .driver_info =
++ USB_QUIRK_CONFIG_INTF_STRINGS },
++
+ /* WORLDE easy key (easykey.25) MIDI controller */
+ { USB_DEVICE(0x0218, 0x0401), .driver_info =
+ USB_QUIRK_CONFIG_INTF_STRINGS },
--- /dev/null
+From f45681f9becaa65111ed0a691ccf080a0cd5feb8 Mon Sep 17 00:00:00 2001
+From: Tim Anderson <tsa@biglakesoftware.com>
+Date: Thu, 9 Aug 2018 14:55:34 -0700
+Subject: USB: Add quirk to support DJI CineSSD
+
+From: Tim Anderson <tsa@biglakesoftware.com>
+
+commit f45681f9becaa65111ed0a691ccf080a0cd5feb8 upstream.
+
+This device does not correctly handle the LPM operations.
+
+Also, the device cannot handle ATA pass-through commands
+and locks up when attempted while running in super speed.
+
+This patch adds the equivalent quirk logic as found in uas.
+
+Signed-off-by: Tim Anderson <tsa@biglakesoftware.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/quirks.c | 3 +++
+ drivers/usb/storage/scsiglue.c | 9 +++++++++
+ drivers/usb/storage/unusual_devs.h | 7 +++++++
+ 3 files changed, 19 insertions(+)
+
+--- a/drivers/usb/core/quirks.c
++++ b/drivers/usb/core/quirks.c
+@@ -259,6 +259,9 @@ static const struct usb_device_id usb_qu
+ { USB_DEVICE(0x2040, 0x7200), .driver_info =
+ USB_QUIRK_CONFIG_INTF_STRINGS },
+
++ /* DJI CineSSD */
++ { USB_DEVICE(0x2ca3, 0x0031), .driver_info = USB_QUIRK_NO_LPM },
++
+ /* INTEL VALUE SSD */
+ { USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
+
+--- a/drivers/usb/storage/scsiglue.c
++++ b/drivers/usb/storage/scsiglue.c
+@@ -392,6 +392,15 @@ static int queuecommand_lck(struct scsi_
+ return 0;
+ }
+
++ if ((us->fflags & US_FL_NO_ATA_1X) &&
++ (srb->cmnd[0] == ATA_12 || srb->cmnd[0] == ATA_16)) {
++ memcpy(srb->sense_buffer, usb_stor_sense_invalidCDB,
++ sizeof(usb_stor_sense_invalidCDB));
++ srb->result = SAM_STAT_CHECK_CONDITION;
++ done(srb);
++ return 0;
++ }
++
+ /* enqueue the command and wake up the control thread */
+ srb->scsi_done = done;
+ us->srb = srb;
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -2307,6 +2307,13 @@ UNUSUAL_DEV( 0x2735, 0x100b, 0x0000, 0x
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_GO_SLOW ),
+
++/* Reported-by: Tim Anderson <tsa@biglakesoftware.com> */
++UNUSUAL_DEV( 0x2ca3, 0x0031, 0x0000, 0x9999,
++ "DJI",
++ "CineSSD",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_NO_ATA_1X),
++
+ /*
+ * Reported by Frederic Marchal <frederic.marchal@wowcompany.com>
+ * Mio Moov 330
--- /dev/null
+From f9a5b4f58b280c1d26255376713c132f93837621 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Mon, 3 Sep 2018 15:44:16 +0300
+Subject: usb: Avoid use-after-free by flushing endpoints early in usb_set_interface()
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit f9a5b4f58b280c1d26255376713c132f93837621 upstream.
+
+The steps taken by usb core to set a new interface is very different from
+what is done on the xHC host side.
+
+xHC hardware will do everything in one go. One command is used to set up
+new endpoints, free old endpoints, check bandwidth, and run the new
+endpoints.
+
+All this is done by xHC when usb core asks the hcd to check for
+available bandwidth. At this point usb core has not yet flushed the old
+endpoints, which will cause use-after-free issues in xhci driver as
+queued URBs are cancelled on a re-allocated endpoint.
+
+To resolve this add a call to usb_disable_interface() which will flush
+the endpoints before calling usb_hcd_alloc_bandwidth()
+
+Additional checks in xhci driver will also be implemented to gracefully
+handle stale URB cancel on freed and re-allocated endpoints
+
+Cc: <stable@vger.kernel.org>
+Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/message.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/usb/core/message.c
++++ b/drivers/usb/core/message.c
+@@ -1279,6 +1279,11 @@ void usb_enable_interface(struct usb_dev
+ * is submitted that needs that bandwidth. Some other operating systems
+ * allocate bandwidth early, when a configuration is chosen.
+ *
++ * xHCI reserves bandwidth and configures the alternate setting in
++ * usb_hcd_alloc_bandwidth(). If it fails the original interface altsetting
++ * may be disabled. Drivers cannot rely on any particular alternate
++ * setting being in effect after a failure.
++ *
+ * This call is synchronous, and may not be used in an interrupt context.
+ * Also, drivers must not change altsettings while urbs are scheduled for
+ * endpoints in that interface; all such urbs must first be completed
+@@ -1314,6 +1319,12 @@ int usb_set_interface(struct usb_device
+ alternate);
+ return -EINVAL;
+ }
++ /*
++ * usb3 hosts configure the interface in usb_hcd_alloc_bandwidth,
++ * including freeing dropped endpoint ring buffers.
++ * Make sure the interface endpoints are flushed before that
++ */
++ usb_disable_interface(dev, iface, false);
+
+ /* Make sure we have enough bandwidth for this alternate interface.
+ * Remove the current alt setting and add the new alt setting.
--- /dev/null
+From 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427 Mon Sep 17 00:00:00 2001
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+Date: Sat, 1 Sep 2018 16:12:10 +0800
+Subject: usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()
+
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+
+commit 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427 upstream.
+
+wdm_in_callback() is a completion handler function for the USB driver.
+So it should not sleep. But it calls service_outstanding_interrupt(),
+which calls usb_submit_urb() with GFP_KERNEL.
+
+To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
+
+This bug is found by my static analysis tool DSAC.
+
+Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/class/cdc-wdm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/class/cdc-wdm.c
++++ b/drivers/usb/class/cdc-wdm.c
+@@ -470,7 +470,7 @@ static int service_outstanding_interrupt
+
+ set_bit(WDM_RESPONDING, &desc->flags);
+ spin_unlock_irq(&desc->iuspin);
+- rv = usb_submit_urb(desc->response, GFP_KERNEL);
++ rv = usb_submit_urb(desc->response, GFP_ATOMIC);
+ spin_lock_irq(&desc->iuspin);
+ if (rv) {
+ dev_err(&desc->intf->dev,
--- /dev/null
+From f3dc41c5d22b2ca14a0802a65d8cdc33a3882d4e Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Tue, 4 Sep 2018 17:35:16 +0300
+Subject: usb: Don't die twice if PCI xhci host is not responding in resume
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit f3dc41c5d22b2ca14a0802a65d8cdc33a3882d4e upstream.
+
+usb_hc_died() should only be called once, and with the primary HCD
+as parameter. It will mark both primary and secondary hcd's dead.
+
+Remove the extra call to usb_cd_died with the shared hcd as parameter.
+
+Fixes: ff9d78b36f76 ("USB: Set usb_hcd->state and flags for shared roothubs")
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hcd-pci.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/usb/core/hcd-pci.c
++++ b/drivers/usb/core/hcd-pci.c
+@@ -528,8 +528,6 @@ static int resume_common(struct device *
+ event == PM_EVENT_RESTORE);
+ if (retval) {
+ dev_err(dev, "PCI post-resume error %d!\n", retval);
+- if (hcd->shared_hcd)
+- usb_hc_died(hcd->shared_hcd);
+ usb_hc_died(hcd);
+ }
+ }
--- /dev/null
+From dfe1a51d2a36647f74cbad478801efa7cf394376 Mon Sep 17 00:00:00 2001
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Date: Fri, 3 Aug 2018 12:12:46 +0900
+Subject: usb: gadget: udc: renesas_usb3: fix maxpacket size of ep0
+
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+commit dfe1a51d2a36647f74cbad478801efa7cf394376 upstream.
+
+This patch fixes an issue that maxpacket size of ep0 is incorrect
+for SuperSpeed. Otherwise, CDC NCM class with SuperSpeed doesn't
+work correctly on this driver because its control read data size
+is more than 64 bytes.
+
+Reported-by: Junki Kato <junki.kato.xk@renesas.com>
+Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
+Cc: <stable@vger.kernel.org> # v4.5+
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Tested-by: Junki Kato <junki.kato.xk@renesas.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/udc/renesas_usb3.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/gadget/udc/renesas_usb3.c
++++ b/drivers/usb/gadget/udc/renesas_usb3.c
+@@ -628,12 +628,15 @@ static void usb3_irq_epc_int_1_speed(str
+ switch (speed) {
+ case USB_STA_SPEED_SS:
+ usb3->gadget.speed = USB_SPEED_SUPER;
++ usb3->gadget.ep0->maxpacket = USB3_EP0_SS_MAX_PACKET_SIZE;
+ break;
+ case USB_STA_SPEED_HS:
+ usb3->gadget.speed = USB_SPEED_HIGH;
++ usb3->gadget.ep0->maxpacket = USB3_EP0_HSFS_MAX_PACKET_SIZE;
+ break;
+ case USB_STA_SPEED_FS:
+ usb3->gadget.speed = USB_SPEED_FULL;
++ usb3->gadget.ep0->maxpacket = USB3_EP0_HSFS_MAX_PACKET_SIZE;
+ break;
+ default:
+ usb3->gadget.speed = USB_SPEED_UNKNOWN;
+@@ -1858,7 +1861,7 @@ static int renesas_usb3_init_ep(struct r
+ /* for control pipe */
+ usb3->gadget.ep0 = &usb3_ep->ep;
+ usb_ep_set_maxpacket_limit(&usb3_ep->ep,
+- USB3_EP0_HSFS_MAX_PACKET_SIZE);
++ USB3_EP0_SS_MAX_PACKET_SIZE);
+ usb3_ep->ep.caps.type_control = true;
+ usb3_ep->ep.caps.dir_in = true;
+ usb3_ep->ep.caps.dir_out = true;
--- /dev/null
+From 6d4f268fa132742fe96dad22307c68d237356d88 Mon Sep 17 00:00:00 2001
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+Date: Sat, 1 Sep 2018 17:23:47 +0800
+Subject: usb: host: u132-hcd: Fix a sleep-in-atomic-context bug in u132_get_frame()
+
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+
+commit 6d4f268fa132742fe96dad22307c68d237356d88 upstream.
+
+i_usX2Y_subs_startup in usbusx2yaudio.c is a completion handler function
+for the USB driver. So it should not sleep, but it is can sleep
+according to the function call paths (from bottom to top) in Linux-4.16.
+
+[FUNC] msleep
+drivers/usb/host/u132-hcd.c, 2558:
+ msleep in u132_get_frame
+drivers/usb/core/hcd.c, 2231:
+ [FUNC_PTR]u132_get_frame in usb_hcd_get_frame_number
+drivers/usb/core/usb.c, 822:
+ usb_hcd_get_frame_number in usb_get_current_frame_number
+sound/usb/usx2y/usbusx2yaudio.c, 303:
+ usb_get_current_frame_number in i_usX2Y_urb_complete
+sound/usb/usx2y/usbusx2yaudio.c, 366:
+ i_usX2Y_urb_complete in i_usX2Y_subs_startup
+
+Note that [FUNC_PTR] means a function pointer call is used.
+
+To fix this bug, msleep() is replaced with mdelay().
+
+This bug is found by my static analysis tool DSAC.
+
+Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/u132-hcd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/host/u132-hcd.c
++++ b/drivers/usb/host/u132-hcd.c
+@@ -2559,7 +2559,7 @@ static int u132_get_frame(struct usb_hcd
+ } else {
+ int frame = 0;
+ dev_err(&u132->platform_dev->dev, "TODO: u132_get_frame\n");
+- msleep(100);
++ mdelay(100);
+ return frame;
+ }
+ }
--- /dev/null
+From bc8acc214d3f1cafebcbcd101a695bbac716595d Mon Sep 17 00:00:00 2001
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+Date: Sat, 1 Sep 2018 16:25:08 +0800
+Subject: usb: misc: uss720: Fix two sleep-in-atomic-context bugs
+
+From: Jia-Ju Bai <baijiaju1990@gmail.com>
+
+commit bc8acc214d3f1cafebcbcd101a695bbac716595d upstream.
+
+async_complete() in uss720.c is a completion handler function for the
+USB driver. So it should not sleep, but it is can sleep according to the
+function call paths (from bottom to top) in Linux-4.16.
+
+[FUNC] set_1284_register(GFP_KERNEL)
+drivers/usb/misc/uss720.c, 372:
+ set_1284_register in parport_uss720_frob_control
+drivers/parport/ieee1284.c, 560:
+ [FUNC_PTR]parport_uss720_frob_control in parport_ieee1284_ack_data_avail
+drivers/parport/ieee1284.c, 577:
+ parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt
+./include/linux/parport.h, 474:
+ parport_ieee1284_interrupt in parport_generic_irq
+drivers/usb/misc/uss720.c, 116:
+ parport_generic_irq in async_complete
+
+[FUNC] get_1284_register(GFP_KERNEL)
+drivers/usb/misc/uss720.c, 382:
+ get_1284_register in parport_uss720_read_status
+drivers/parport/ieee1284.c, 555:
+ [FUNC_PTR]parport_uss720_read_status in parport_ieee1284_ack_data_avail
+drivers/parport/ieee1284.c, 577:
+ parport_ieee1284_ack_data_avail in parport_ieee1284_interrupt
+./include/linux/parport.h, 474:
+ parport_ieee1284_interrupt in parport_generic_irq
+drivers/usb/misc/uss720.c, 116:
+ parport_generic_irq in async_complete
+
+Note that [FUNC_PTR] means a function pointer call is used.
+
+To fix these bugs, GFP_KERNEL is replaced with GFP_ATOMIC.
+
+These bugs are found by my static analysis tool DSAC.
+
+Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/misc/uss720.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/misc/uss720.c
++++ b/drivers/usb/misc/uss720.c
+@@ -385,7 +385,7 @@ static unsigned char parport_uss720_frob
+ mask &= 0x0f;
+ val &= 0x0f;
+ d = (priv->reg[1] & (~mask)) ^ val;
+- if (set_1284_register(pp, 2, d, GFP_KERNEL))
++ if (set_1284_register(pp, 2, d, GFP_ATOMIC))
+ return 0;
+ priv->reg[1] = d;
+ return d & 0xf;
+@@ -395,7 +395,7 @@ static unsigned char parport_uss720_read
+ {
+ unsigned char ret;
+
+- if (get_1284_register(pp, 1, &ret, GFP_KERNEL))
++ if (get_1284_register(pp, 1, &ret, GFP_ATOMIC))
+ return 0;
+ return ret & 0xf8;
+ }
--- /dev/null
+From dec3c23c9aa1815f07d98ae0375b4cbc10971e13 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Wed, 8 Aug 2018 11:20:39 -0400
+Subject: USB: net2280: Fix erroneous synchronization change
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit dec3c23c9aa1815f07d98ae0375b4cbc10971e13 upstream.
+
+Commit f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking
+for callbacks") was based on a serious misunderstanding. It
+introduced regressions into both the dummy-hcd and net2280 drivers.
+
+The problem in dummy-hcd was fixed by commit 7dbd8f4cabd9 ("USB:
+dummy-hcd: Fix erroneous synchronization change"), but the problem in
+net2280 remains. Namely: the ->disconnect(), ->suspend(), ->resume(),
+and ->reset() callbacks must be invoked without the private lock held;
+otherwise a deadlock will occur when the callback routine tries to
+interact with the UDC driver.
+
+This patch largely is a reversion of the relevant parts of
+f16443a034c7. It also drops the private lock around the calls to
+->suspend() and ->resume() (something the earlier patch forgot to do).
+This is safe from races with device interrupts because it occurs
+within the interrupt handler.
+
+Finally, the patch changes where the ->disconnect() callback is
+invoked when net2280_pullup() turns the pullup off. Rather than
+making the callback from within stop_activity() at a time when dropping
+the private lock could be unsafe, the callback is moved to a point
+after the lock has already been dropped.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Fixes: f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
+Reported-by: D. Ziesche <dziesche@zes.com>
+Tested-by: D. Ziesche <dziesche@zes.com>
+CC: <stable@vger.kernel.org>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/udc/net2280.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/gadget/udc/net2280.c
++++ b/drivers/usb/gadget/udc/net2280.c
+@@ -1549,11 +1549,14 @@ static int net2280_pullup(struct usb_gad
+ writel(tmp | BIT(USB_DETECT_ENABLE), &dev->usb->usbctl);
+ } else {
+ writel(tmp & ~BIT(USB_DETECT_ENABLE), &dev->usb->usbctl);
+- stop_activity(dev, dev->driver);
++ stop_activity(dev, NULL);
+ }
+
+ spin_unlock_irqrestore(&dev->lock, flags);
+
++ if (!is_on && dev->driver)
++ dev->driver->disconnect(&dev->gadget);
++
+ return 0;
+ }
+
+@@ -2470,8 +2473,11 @@ static void stop_activity(struct net2280
+ nuke(&dev->ep[i]);
+
+ /* report disconnect; the driver is already quiesced */
+- if (driver)
++ if (driver) {
++ spin_unlock(&dev->lock);
+ driver->disconnect(&dev->gadget);
++ spin_lock(&dev->lock);
++ }
+
+ usb_reinit(dev);
+ }
+@@ -3345,6 +3351,8 @@ next_endpoints:
+ BIT(PCI_RETRY_ABORT_INTERRUPT))
+
+ static void handle_stat1_irqs(struct net2280 *dev, u32 stat)
++__releases(dev->lock)
++__acquires(dev->lock)
+ {
+ struct net2280_ep *ep;
+ u32 tmp, num, mask, scratch;
+@@ -3385,12 +3393,14 @@ static void handle_stat1_irqs(struct net
+ if (disconnect || reset) {
+ stop_activity(dev, dev->driver);
+ ep0_start(dev);
++ spin_unlock(&dev->lock);
+ if (reset)
+ usb_gadget_udc_reset
+ (&dev->gadget, dev->driver);
+ else
+ (dev->driver->disconnect)
+ (&dev->gadget);
++ spin_lock(&dev->lock);
+ return;
+ }
+ }
+@@ -3409,6 +3419,7 @@ static void handle_stat1_irqs(struct net
+ tmp = BIT(SUSPEND_REQUEST_CHANGE_INTERRUPT);
+ if (stat & tmp) {
+ writel(tmp, &dev->regs->irqstat1);
++ spin_unlock(&dev->lock);
+ if (stat & BIT(SUSPEND_REQUEST_INTERRUPT)) {
+ if (dev->driver->suspend)
+ dev->driver->suspend(&dev->gadget);
+@@ -3419,6 +3430,7 @@ static void handle_stat1_irqs(struct net
+ dev->driver->resume(&dev->gadget);
+ /* at high speed, note erratum 0133 */
+ }
++ spin_lock(&dev->lock);
+ stat &= ~tmp;
+ }
+
--- /dev/null
+From 691a03cfe8ca483f9c48153b869d354e4ae3abef Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Tue, 21 Aug 2018 11:59:52 +0200
+Subject: USB: serial: io_ti: fix array underflow in completion handler
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 691a03cfe8ca483f9c48153b869d354e4ae3abef upstream.
+
+As reported by Dan Carpenter, a malicious USB device could set
+port_number to a negative value and we would underflow the port array in
+the interrupt completion handler.
+
+As these devices only have one or two ports, fix this by making sure we
+only consider the seventh bit when determining the port number (and
+ignore bits 0xb0 which are typically set to 0x30).
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable <stable@vger.kernel.org>
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/io_ti.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/serial/io_ti.h
++++ b/drivers/usb/serial/io_ti.h
+@@ -178,7 +178,7 @@ struct ump_interrupt {
+ } __attribute__((packed));
+
+
+-#define TIUMP_GET_PORT_FROM_CODE(c) (((c) >> 4) - 3)
++#define TIUMP_GET_PORT_FROM_CODE(c) (((c) >> 6) & 0x01)
+ #define TIUMP_GET_FUNC_FROM_CODE(c) ((c) & 0x0f)
+ #define TIUMP_INTERRUPT_CODE_LSR 0x03
+ #define TIUMP_INTERRUPT_CODE_MSR 0x04
--- /dev/null
+From 5dfdd24eb3d39d815bc952ae98128e967c9bba49 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Tue, 21 Aug 2018 11:59:53 +0200
+Subject: USB: serial: ti_usb_3410_5052: fix array underflow in completion handler
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 5dfdd24eb3d39d815bc952ae98128e967c9bba49 upstream.
+
+Similarly to a recently reported bug in io_ti, a malicious USB device
+could set port_number to a negative value and we would underflow the
+port array in the interrupt completion handler.
+
+As these devices only have one or two ports, fix this by making sure we
+only consider the seventh bit when determining the port number (and
+ignore bits 0xb0 which are typically set to 0x30).
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/ti_usb_3410_5052.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/serial/ti_usb_3410_5052.c
++++ b/drivers/usb/serial/ti_usb_3410_5052.c
+@@ -1129,7 +1129,7 @@ static void ti_break(struct tty_struct *
+
+ static int ti_get_port_from_code(unsigned char code)
+ {
+- return (code >> 4) - 3;
++ return (code >> 6) & 0x01;
+ }
+
+ static int ti_get_func_from_code(unsigned char code)
--- /dev/null
+From 42d1c6d4a06a77b3ab206a919b9050c3080f3a71 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Thu, 9 Aug 2018 16:03:37 +0200
+Subject: usb: uas: add support for more quirk flags
+
+From: Oliver Neukum <oneukum@suse.com>
+
+commit 42d1c6d4a06a77b3ab206a919b9050c3080f3a71 upstream.
+
+The hope that UAS devices would be less broken than old style storage
+devices has turned out to be unfounded. Make UAS support more of the
+quirk flags of the old driver.
+
+Signed-off-by: Oliver Neukum <oneukum@suse.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/uas.c | 21 +++++++++++++++++++++
+ 1 file changed, 21 insertions(+)
+
+--- a/drivers/usb/storage/uas.c
++++ b/drivers/usb/storage/uas.c
+@@ -842,6 +842,27 @@ static int uas_slave_configure(struct sc
+ sdev->skip_ms_page_8 = 1;
+ sdev->wce_default_on = 1;
+ }
++
++ /*
++ * Some disks return the total number of blocks in response
++ * to READ CAPACITY rather than the highest block number.
++ * If this device makes that mistake, tell the sd driver.
++ */
++ if (devinfo->flags & US_FL_FIX_CAPACITY)
++ sdev->fix_capacity = 1;
++
++ /*
++ * Some devices don't like MODE SENSE with page=0x3f,
++ * which is the command used for checking if a device
++ * is write-protected. Now that we tell the sd driver
++ * to do a 192-byte transfer with this command the
++ * majority of devices work fine, but a few still can't
++ * handle it. The sd driver will simply assume those
++ * devices are write-enabled.
++ */
++ if (devinfo->flags & US_FL_NO_WP_DETECT)
++ sdev->skip_ms_page_3f = 1;
++
+ scsi_change_queue_depth(sdev, devinfo->qdepth - 2);
+ return 0;
+ }
--- /dev/null
+From 7e10f14ebface44a48275c8d6dc1caae3668d5a9 Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Date: Wed, 15 Aug 2018 21:44:25 +0100
+Subject: USB: yurex: Fix buffer over-read in yurex_write()
+
+From: Ben Hutchings <ben.hutchings@codethink.co.uk>
+
+commit 7e10f14ebface44a48275c8d6dc1caae3668d5a9 upstream.
+
+If the written data starts with a digit, yurex_write() tries to parse
+it as an integer using simple_strtoull(). This requires a null-
+terminator, and currently there's no guarantee that there is one.
+
+(The sample program at
+https://github.com/NeoCat/YUREX-driver-for-Linux/blob/master/sample/yurex_clock.pl
+writes an integer without a null terminator. It seems like it must
+have worked by chance!)
+
+Always add a null byte after the written data. Enlarge the buffer
+to allow for this.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/misc/yurex.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/misc/yurex.c
++++ b/drivers/usb/misc/yurex.c
+@@ -431,13 +431,13 @@ static ssize_t yurex_write(struct file *
+ {
+ struct usb_yurex *dev;
+ int i, set = 0, retval = 0;
+- char buffer[16];
++ char buffer[16 + 1];
+ char *data = buffer;
+ unsigned long long c, c2 = 0;
+ signed long timeout = 0;
+ DEFINE_WAIT(wait);
+
+- count = min(sizeof(buffer), count);
++ count = min(sizeof(buffer) - 1, count);
+ dev = file->private_data;
+
+ /* verify that we actually have some data to write */
+@@ -456,6 +456,7 @@ static ssize_t yurex_write(struct file *
+ retval = -EFAULT;
+ goto error;
+ }
++ buffer[count] = 0;
+ memset(dev->cntl_buffer, CMD_PADDING, YUREX_BUF_SIZE);
+
+ switch (buffer[0]) {
--- /dev/null
+From 8edfe2e992b75aee3da9316e9697c531194c2f53 Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+Date: Fri, 7 Sep 2018 14:21:30 +0200
+Subject: xen/netfront: fix waiting for xenbus state change
+
+From: Juergen Gross <jgross@suse.com>
+
+commit 8edfe2e992b75aee3da9316e9697c531194c2f53 upstream.
+
+Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load
+module manually") added a new wait queue to wait on for a state change
+when the module is loaded manually. Unfortunately there is no wakeup
+anywhere to stop that waiting.
+
+Instead of introducing a new wait queue rename the existing
+module_unload_q to module_wq and use it for both purposes (loading and
+unloading).
+
+As any state change of the backend might be intended to stop waiting
+do the wake_up_all() in any case when netback_changed() is called.
+
+Fixes: 822fb18a82aba ("xen-netfront: wait xenbus state change when load module manually")
+Cc: <stable@vger.kernel.org> #4.18
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/xen-netfront.c | 24 ++++++++++--------------
+ 1 file changed, 10 insertions(+), 14 deletions(-)
+
+--- a/drivers/net/xen-netfront.c
++++ b/drivers/net/xen-netfront.c
+@@ -86,8 +86,7 @@ struct netfront_cb {
+ /* IRQ name is queue name with "-tx" or "-rx" appended */
+ #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
+
+-static DECLARE_WAIT_QUEUE_HEAD(module_load_q);
+-static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
++static DECLARE_WAIT_QUEUE_HEAD(module_wq);
+
+ struct netfront_stats {
+ u64 packets;
+@@ -1350,11 +1349,11 @@ static struct net_device *xennet_create_
+ netif_carrier_off(netdev);
+
+ xenbus_switch_state(dev, XenbusStateInitialising);
+- wait_event(module_load_q,
+- xenbus_read_driver_state(dev->otherend) !=
+- XenbusStateClosed &&
+- xenbus_read_driver_state(dev->otherend) !=
+- XenbusStateUnknown);
++ wait_event(module_wq,
++ xenbus_read_driver_state(dev->otherend) !=
++ XenbusStateClosed &&
++ xenbus_read_driver_state(dev->otherend) !=
++ XenbusStateUnknown);
+ return netdev;
+
+ exit:
+@@ -2039,15 +2038,14 @@ static void netback_changed(struct xenbu
+
+ dev_dbg(&dev->dev, "%s\n", xenbus_strstate(backend_state));
+
++ wake_up_all(&module_wq);
++
+ switch (backend_state) {
+ case XenbusStateInitialising:
+ case XenbusStateInitialised:
+ case XenbusStateReconfiguring:
+ case XenbusStateReconfigured:
+- break;
+-
+ case XenbusStateUnknown:
+- wake_up_all(&module_unload_q);
+ break;
+
+ case XenbusStateInitWait:
+@@ -2063,12 +2061,10 @@ static void netback_changed(struct xenbu
+ break;
+
+ case XenbusStateClosed:
+- wake_up_all(&module_unload_q);
+ if (dev->state == XenbusStateClosed)
+ break;
+ /* Missed the backend's CLOSING state -- fallthrough */
+ case XenbusStateClosing:
+- wake_up_all(&module_unload_q);
+ xenbus_frontend_closed(dev);
+ break;
+ }
+@@ -2176,14 +2172,14 @@ static int xennet_remove(struct xenbus_d
+
+ if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {
+ xenbus_switch_state(dev, XenbusStateClosing);
+- wait_event(module_unload_q,
++ wait_event(module_wq,
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateClosing ||
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateUnknown);
+
+ xenbus_switch_state(dev, XenbusStateClosed);
+- wait_event(module_unload_q,
++ wait_event(module_wq,
+ xenbus_read_driver_state(dev->otherend) ==
+ XenbusStateClosed ||
+ xenbus_read_driver_state(dev->otherend) ==