--- /dev/null
+From b0d18907f836ea4ff811bc548c0f281827d305e5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Aug 2021 17:13:42 -0700
+Subject: io_uring: Use WRITE_ONCE() when writing to sq_flags
+
+From: Nadav Amit <namit@vmware.com>
+
+[ Upstream commit 20c0b380f971e7d48f5d978bc27d827f7eabb21a ]
+
+The compiler should be forbidden from any strange optimization for async
+writes to user visible data-structures. Without proper protection, the
+compiler can cause write-tearing or invent writes that would confuse the
+userspace.
+
+However, there are writes to sq_flags which are not protected by
+WRITE_ONCE(). Use WRITE_ONCE() for these writes.
+
+This is purely a theoretical issue. Presumably, any compiler is very
+unlikely to do such optimizations.
+
+Fixes: 75b28affdd6a ("io_uring: allocate the two rings together")
+Cc: Jens Axboe <axboe@kernel.dk>
+Cc: Pavel Begunkov <asml.silence@gmail.com>
+Signed-off-by: Nadav Amit <namit@vmware.com>
+Link: https://lore.kernel.org/r/20210808001342.964634-3-namit@vmware.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/io_uring.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/fs/io_uring.c b/fs/io_uring.c
+index f23ff39f7697..0a5f105c657c 100644
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -1482,7 +1482,8 @@ static bool __io_cqring_overflow_flush(struct io_ring_ctx *ctx, bool force)
+ if (all_flushed) {
+ clear_bit(0, &ctx->sq_check_overflow);
+ clear_bit(0, &ctx->cq_check_overflow);
+- ctx->rings->sq_flags &= ~IORING_SQ_CQ_OVERFLOW;
++ WRITE_ONCE(ctx->rings->sq_flags,
++ ctx->rings->sq_flags & ~IORING_SQ_CQ_OVERFLOW);
+ }
+
+ if (posted)
+@@ -1562,7 +1563,9 @@ static bool io_cqring_event_overflow(struct io_ring_ctx *ctx, u64 user_data,
+ if (list_empty(&ctx->cq_overflow_list)) {
+ set_bit(0, &ctx->sq_check_overflow);
+ set_bit(0, &ctx->cq_check_overflow);
+- ctx->rings->sq_flags |= IORING_SQ_CQ_OVERFLOW;
++ WRITE_ONCE(ctx->rings->sq_flags,
++ ctx->rings->sq_flags | IORING_SQ_CQ_OVERFLOW);
++
+ }
+ ocqe->cqe.user_data = user_data;
+ ocqe->cqe.res = res;
+@@ -6790,14 +6793,16 @@ static inline void io_ring_set_wakeup_flag(struct io_ring_ctx *ctx)
+ {
+ /* Tell userspace we may need a wakeup call */
+ spin_lock_irq(&ctx->completion_lock);
+- ctx->rings->sq_flags |= IORING_SQ_NEED_WAKEUP;
++ WRITE_ONCE(ctx->rings->sq_flags,
++ ctx->rings->sq_flags | IORING_SQ_NEED_WAKEUP);
+ spin_unlock_irq(&ctx->completion_lock);
+ }
+
+ static inline void io_ring_clear_wakeup_flag(struct io_ring_ctx *ctx)
+ {
+ spin_lock_irq(&ctx->completion_lock);
+- ctx->rings->sq_flags &= ~IORING_SQ_NEED_WAKEUP;
++ WRITE_ONCE(ctx->rings->sq_flags,
++ ctx->rings->sq_flags & ~IORING_SQ_NEED_WAKEUP);
+ spin_unlock_irq(&ctx->completion_lock);
+ }
+
+--
+2.30.2
+
mtd-cfi_cmdset_0002-fix-crash-when-erasing-writing-amd-cards.patch
+io_uring-use-write_once-when-writing-to-sq_flags.patch
+usb-core-avoid-warnings-for-0-length-descriptor-requ.patch
+usb-core-fix-incorrect-pipe-calculation-in-do_proc_c.patch
--- /dev/null
+From 9be944d6ecb2dcaf0cfb1755212281fbbae2a987 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Jun 2021 11:23:07 -0400
+Subject: USB: core: Avoid WARNings for 0-length descriptor requests
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+[ Upstream commit 60dfe484cef45293e631b3a6e8995f1689818172 ]
+
+The USB core has utility routines to retrieve various types of
+descriptors. These routines will now provoke a WARN if they are asked
+to retrieve 0 bytes (USB "receive" requests must not have zero
+length), so avert this by checking the size argument at the start.
+
+CC: Johan Hovold <johan@kernel.org>
+Reported-and-tested-by: syzbot+7dbcd9ff34dc4ed45240@syzkaller.appspotmail.com
+Reviewed-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/20210607152307.GD1768031@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/core/message.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
+index 30e9e680c74c..4d59d927ae3e 100644
+--- a/drivers/usb/core/message.c
++++ b/drivers/usb/core/message.c
+@@ -783,6 +783,9 @@ int usb_get_descriptor(struct usb_device *dev, unsigned char type,
+ int i;
+ int result;
+
++ if (size <= 0) /* No point in asking for no data */
++ return -EINVAL;
++
+ memset(buf, 0, size); /* Make sure we parse really received data */
+
+ for (i = 0; i < 3; ++i) {
+@@ -832,6 +835,9 @@ static int usb_get_string(struct usb_device *dev, unsigned short langid,
+ int i;
+ int result;
+
++ if (size <= 0) /* No point in asking for no data */
++ return -EINVAL;
++
+ for (i = 0; i < 3; ++i) {
+ /* retry on length 0 or stall; some devices are flakey */
+ result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
+--
+2.30.2
+
--- /dev/null
+From 6640f393c464e0c7a93c3a7669563a0454fc32ad Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 12 Jul 2021 14:54:36 -0400
+Subject: USB: core: Fix incorrect pipe calculation in do_proc_control()
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+[ Upstream commit b0863f1927323110e3d0d69f6adb6a91018a9a3c ]
+
+When the user submits a control URB via usbfs, the user supplies the
+bRequestType value and the kernel uses it to compute the pipe value.
+However, do_proc_control() performs this computation incorrectly in
+the case where the bRequestType direction bit is set to USB_DIR_IN and
+the URB's transfer length is 0: The pipe's direction is also set to IN
+but it should be OUT, which is the direction the actual transfer will
+use regardless of bRequestType.
+
+Commit 5cc59c418fde ("USB: core: WARN if pipe direction != setup
+packet direction") added a check to compare the direction bit in the
+pipe value to a control URB's actual direction and to WARN if they are
+different. This can be triggered by the incorrect computation
+mentioned above, as found by syzbot.
+
+This patch fixes the computation, thus avoiding the WARNing.
+
+Reported-and-tested-by: syzbot+72af3105289dcb4c055b@syzkaller.appspotmail.com
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/20210712185436.GB326369@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/core/devio.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
+index 2218941d35a3..73b60f013b20 100644
+--- a/drivers/usb/core/devio.c
++++ b/drivers/usb/core/devio.c
+@@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_dev_state *ps,
+ "wIndex=%04x wLength=%04x\n",
+ ctrl->bRequestType, ctrl->bRequest, ctrl->wValue,
+ ctrl->wIndex, ctrl->wLength);
+- if (ctrl->bRequestType & 0x80) {
++ if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) {
+ pipe = usb_rcvctrlpipe(dev, 0);
+ snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0);
+
+--
+2.30.2
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
