From: Sasha Levin Date: Thu, 19 Aug 2021 00:54:21 +0000 (-0400) Subject: Fixes for 5.13 X-Git-Tag: v5.13.13~41 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8b9b735c768297d630b256c37b82029c39b6b5cc;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.13 Signed-off-by: Sasha Levin --- diff --git a/queue-5.13/io_uring-use-write_once-when-writing-to-sq_flags.patch b/queue-5.13/io_uring-use-write_once-when-writing-to-sq_flags.patch new file mode 100644 index 00000000000..a09fc708637 --- /dev/null +++ b/queue-5.13/io_uring-use-write_once-when-writing-to-sq_flags.patch @@ -0,0 +1,78 @@ +From b0d18907f836ea4ff811bc548c0f281827d305e5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Aug 2021 17:13:42 -0700 +Subject: io_uring: Use WRITE_ONCE() when writing to sq_flags + +From: Nadav Amit + +[ 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 +Cc: Pavel Begunkov +Signed-off-by: Nadav Amit +Link: https://lore.kernel.org/r/20210808001342.964634-3-namit@vmware.com +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.13/series b/queue-5.13/series index 7e41e531978..c53a56271a3 100644 --- a/queue-5.13/series +++ b/queue-5.13/series @@ -1 +1,4 @@ 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 diff --git a/queue-5.13/usb-core-avoid-warnings-for-0-length-descriptor-requ.patch b/queue-5.13/usb-core-avoid-warnings-for-0-length-descriptor-requ.patch new file mode 100644 index 00000000000..828f5553b5a --- /dev/null +++ b/queue-5.13/usb-core-avoid-warnings-for-0-length-descriptor-requ.patch @@ -0,0 +1,52 @@ +From 9be944d6ecb2dcaf0cfb1755212281fbbae2a987 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Jun 2021 11:23:07 -0400 +Subject: USB: core: Avoid WARNings for 0-length descriptor requests + +From: Alan Stern + +[ 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 +Reported-and-tested-by: syzbot+7dbcd9ff34dc4ed45240@syzkaller.appspotmail.com +Reviewed-by: Johan Hovold +Signed-off-by: Alan Stern +Link: https://lore.kernel.org/r/20210607152307.GD1768031@rowland.harvard.edu +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.13/usb-core-fix-incorrect-pipe-calculation-in-do_proc_c.patch b/queue-5.13/usb-core-fix-incorrect-pipe-calculation-in-do_proc_c.patch new file mode 100644 index 00000000000..9c945305b48 --- /dev/null +++ b/queue-5.13/usb-core-fix-incorrect-pipe-calculation-in-do_proc_c.patch @@ -0,0 +1,50 @@ +From 6640f393c464e0c7a93c3a7669563a0454fc32ad Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 12 Jul 2021 14:54:36 -0400 +Subject: USB: core: Fix incorrect pipe calculation in do_proc_control() + +From: Alan Stern + +[ 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 +Link: https://lore.kernel.org/r/20210712185436.GB326369@rowland.harvard.edu +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + 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 +