From: Greg Kroah-Hartman Date: Sun, 15 Dec 2024 08:40:50 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v5.4.288~66 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=3824374c3348f08b3e29d7ec5e175946e11bce94;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: usb-ehci-hcd-fix-call-balance-of-clocks-handling-routines.patch usb-gadget-u_serial-fix-the-issue-that-gs_start_io-crashed-due-to-accessing-null-pointer.patch xfs-don-t-drop-errno-values-when-we-fail-to-ficlone-the-entire-range.patch --- diff --git a/queue-5.4/series b/queue-5.4/series index 706c82c47a3..e5bbf88abb7 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -1,3 +1,6 @@ usb-host-max3421-hcd-correctly-abort-a-usb-request.patch ata-sata_highbank-fix-of-node-reference-leak-in-highbank_initialize_phys.patch usb-dwc2-hcd-fix-getportstatus-setportfeature.patch +usb-ehci-hcd-fix-call-balance-of-clocks-handling-routines.patch +usb-gadget-u_serial-fix-the-issue-that-gs_start_io-crashed-due-to-accessing-null-pointer.patch +xfs-don-t-drop-errno-values-when-we-fail-to-ficlone-the-entire-range.patch diff --git a/queue-5.4/usb-ehci-hcd-fix-call-balance-of-clocks-handling-routines.patch b/queue-5.4/usb-ehci-hcd-fix-call-balance-of-clocks-handling-routines.patch new file mode 100644 index 00000000000..0a11075df48 --- /dev/null +++ b/queue-5.4/usb-ehci-hcd-fix-call-balance-of-clocks-handling-routines.patch @@ -0,0 +1,52 @@ +From 97264eaaba0122a5b7e8ddd7bf4ff3ac57c2b170 Mon Sep 17 00:00:00 2001 +From: Vitalii Mordan +Date: Thu, 21 Nov 2024 14:47:00 +0300 +Subject: usb: ehci-hcd: fix call balance of clocks handling routines + +From: Vitalii Mordan + +commit 97264eaaba0122a5b7e8ddd7bf4ff3ac57c2b170 upstream. + +If the clocks priv->iclk and priv->fclk were not enabled in ehci_hcd_sh_probe, +they should not be disabled in any path. + +Conversely, if they was enabled in ehci_hcd_sh_probe, they must be disabled +in all error paths to ensure proper cleanup. + +Found by Linux Verification Center (linuxtesting.org) with Klever. + +Fixes: 63c845522263 ("usb: ehci-hcd: Add support for SuperH EHCI.") +Cc: stable@vger.kernel.org # ff30bd6a6618: sh: clk: Fix clk_enable() to return 0 on NULL clk +Signed-off-by: Vitalii Mordan +Reviewed-by: Alan Stern +Link: https://lore.kernel.org/r/20241121114700.2100520-1-mordan@ispras.ru +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/ehci-sh.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/drivers/usb/host/ehci-sh.c ++++ b/drivers/usb/host/ehci-sh.c +@@ -124,8 +124,12 @@ static int ehci_hcd_sh_probe(struct plat + if (IS_ERR(priv->iclk)) + priv->iclk = NULL; + +- clk_enable(priv->fclk); +- clk_enable(priv->iclk); ++ ret = clk_enable(priv->fclk); ++ if (ret) ++ goto fail_request_resource; ++ ret = clk_enable(priv->iclk); ++ if (ret) ++ goto fail_iclk; + + if (pdata && pdata->phy_init) + pdata->phy_init(); +@@ -144,6 +148,7 @@ static int ehci_hcd_sh_probe(struct plat + + fail_add_hcd: + clk_disable(priv->iclk); ++fail_iclk: + clk_disable(priv->fclk); + + fail_request_resource: diff --git a/queue-5.4/usb-gadget-u_serial-fix-the-issue-that-gs_start_io-crashed-due-to-accessing-null-pointer.patch b/queue-5.4/usb-gadget-u_serial-fix-the-issue-that-gs_start_io-crashed-due-to-accessing-null-pointer.patch new file mode 100644 index 00000000000..01240ca9d3c --- /dev/null +++ b/queue-5.4/usb-gadget-u_serial-fix-the-issue-that-gs_start_io-crashed-due-to-accessing-null-pointer.patch @@ -0,0 +1,81 @@ +From 4cfbca86f6a8b801f3254e0e3c8f2b1d2d64be2b Mon Sep 17 00:00:00 2001 +From: Lianqin Hu +Date: Tue, 3 Dec 2024 12:14:16 +0000 +Subject: usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer + +From: Lianqin Hu + +commit 4cfbca86f6a8b801f3254e0e3c8f2b1d2d64be2b upstream. + +Considering that in some extreme cases, +when u_serial driver is accessed by multiple threads, +Thread A is executing the open operation and calling the gs_open, +Thread B is executing the disconnect operation and calling the +gserial_disconnect function,The port->port_usb pointer will be set to NULL. + +E.g. + Thread A Thread B + gs_open() gadget_unbind_driver() + gs_start_io() composite_disconnect() + gs_start_rx() gserial_disconnect() + ... ... + spin_unlock(&port->port_lock) + status = usb_ep_queue() spin_lock(&port->port_lock) + spin_lock(&port->port_lock) port->port_usb = NULL + gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) + Crash + +This causes thread A to access a null pointer (port->port_usb is null) +when calling the gs_free_requests function, causing a crash. + +If port_usb is NULL, the release request will be skipped as it +will be done by gserial_disconnect. + +So add a null pointer check to gs_start_io before attempting +to access the value of the pointer port->port_usb. + +Call trace: + gs_start_io+0x164/0x25c + gs_open+0x108/0x13c + tty_open+0x314/0x638 + chrdev_open+0x1b8/0x258 + do_dentry_open+0x2c4/0x700 + vfs_open+0x2c/0x3c + path_openat+0xa64/0xc60 + do_filp_open+0xb8/0x164 + do_sys_openat2+0x84/0xf0 + __arm64_sys_openat+0x70/0x9c + invoke_syscall+0x58/0x114 + el0_svc_common+0x80/0xe0 + do_el0_svc+0x1c/0x28 + el0_svc+0x38/0x68 + +Fixes: c1dca562be8a ("usb gadget: split out serial core") +Cc: stable@vger.kernel.org +Suggested-by: Prashanth K +Signed-off-by: Lianqin Hu +Acked-by: Prashanth K +Link: https://lore.kernel.org/r/TYUPR06MB62178DC3473F9E1A537DCD02D2362@TYUPR06MB6217.apcprd06.prod.outlook.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/function/u_serial.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/usb/gadget/function/u_serial.c ++++ b/drivers/usb/gadget/function/u_serial.c +@@ -566,9 +566,12 @@ static int gs_start_io(struct gs_port *p + * we didn't in gs_start_tx() */ + tty_wakeup(port->port.tty); + } else { +- gs_free_requests(ep, head, &port->read_allocated); +- gs_free_requests(port->port_usb->in, &port->write_pool, +- &port->write_allocated); ++ /* Free reqs only if we are still connected */ ++ if (port->port_usb) { ++ gs_free_requests(ep, head, &port->read_allocated); ++ gs_free_requests(port->port_usb->in, &port->write_pool, ++ &port->write_allocated); ++ } + status = -EIO; + } + diff --git a/queue-5.4/xfs-don-t-drop-errno-values-when-we-fail-to-ficlone-the-entire-range.patch b/queue-5.4/xfs-don-t-drop-errno-values-when-we-fail-to-ficlone-the-entire-range.patch new file mode 100644 index 00000000000..bd5dee3931d --- /dev/null +++ b/queue-5.4/xfs-don-t-drop-errno-values-when-we-fail-to-ficlone-the-entire-range.patch @@ -0,0 +1,61 @@ +From 7ce31f20a0771d71779c3b0ec9cdf474cc3c8e9a Mon Sep 17 00:00:00 2001 +From: "Darrick J. Wong" +Date: Mon, 2 Dec 2024 10:57:27 -0800 +Subject: xfs: don't drop errno values when we fail to ficlone the entire range + +From: Darrick J. Wong + +commit 7ce31f20a0771d71779c3b0ec9cdf474cc3c8e9a upstream. + +Way back when we first implemented FICLONE for XFS, life was simple -- +either the the entire remapping completed, or something happened and we +had to return an errno explaining what happened. Neither of those +ioctls support returning partial results, so it's all or nothing. + +Then things got complicated when copy_file_range came along, because it +actually can return the number of bytes copied, so commit 3f68c1f562f1e4 +tried to make it so that we could return a partial result if the +REMAP_FILE_CAN_SHORTEN flag is set. This is also how FIDEDUPERANGE can +indicate that the kernel performed a partial deduplication. + +Unfortunately, the logic is wrong if an error stops the remapping and +CAN_SHORTEN is not set. Because those callers cannot return partial +results, it is an error for ->remap_file_range to return a positive +quantity that is less than the @len passed in. Implementations really +should be returning a negative errno in this case, because that's what +btrfs (which introduced FICLONE{,RANGE}) did. + +Therefore, ->remap_range implementations cannot silently drop an errno +that they might have when the number of bytes remapped is less than the +number of bytes requested and CAN_SHORTEN is not set. + +Found by running generic/562 on a 64k fsblock filesystem and wondering +why it reported corrupt files. + +Cc: # v4.20 +Fixes: 3fc9f5e409319e ("xfs: remove xfs_reflink_remap_range") +Really-Fixes: 3f68c1f562f1e4 ("xfs: support returning partial reflink results") +Signed-off-by: "Darrick J. Wong" +Reviewed-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_file.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/fs/xfs/xfs_file.c ++++ b/fs/xfs/xfs_file.c +@@ -1068,6 +1068,14 @@ out_unlock: + xfs_reflink_remap_unlock(file_in, file_out); + if (ret) + trace_xfs_reflink_remap_range_error(dest, ret, _RET_IP_); ++ /* ++ * If the caller did not set CAN_SHORTEN, then it is not prepared to ++ * handle partial results -- either the whole remap succeeds, or we ++ * must say why it did not. In this case, any error should be returned ++ * to the caller. ++ */ ++ if (ret && remapped < len && !(remap_flags & REMAP_FILE_CAN_SHORTEN)) ++ return ret; + return remapped > 0 ? remapped : ret; + } +