From: Greg Kroah-Hartman Date: Tue, 1 Oct 2024 10:54:17 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v6.6.54~73 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=17c167367442877ff66468984e1086cbf4da3d4f;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: bus-integrator-lm-fix-of-node-leak-in-probe.patch crypto-ccp-properly-unregister-dev-sev-on-sev-platform_status-failure.patch firmware_loader-block-path-traversal.patch tty-rp2-fix-reset-with-non-forgiving-pcie-host-bridges.patch usb-appledisplay-close-race-between-probe-and-completion-handler.patch usb-class-cdc-acm-fix-race-between-get_serial-and-set_serial.patch usb-misc-cypress_cy7c63-check-for-short-transfer.patch --- diff --git a/queue-5.10/bus-integrator-lm-fix-of-node-leak-in-probe.patch b/queue-5.10/bus-integrator-lm-fix-of-node-leak-in-probe.patch new file mode 100644 index 00000000000..b61d6c36328 --- /dev/null +++ b/queue-5.10/bus-integrator-lm-fix-of-node-leak-in-probe.patch @@ -0,0 +1,33 @@ +From 15a62b81175885b5adfcaf49870466e3603f06c7 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Mon, 26 Aug 2024 07:49:34 +0200 +Subject: bus: integrator-lm: fix OF node leak in probe() + +From: Krzysztof Kozlowski + +commit 15a62b81175885b5adfcaf49870466e3603f06c7 upstream. + +Driver code is leaking OF node reference from of_find_matching_node() in +probe(). + +Fixes: ccea5e8a5918 ("bus: Add driver for Integrator/AP logic modules") +Cc: stable@vger.kernel.org +Signed-off-by: Krzysztof Kozlowski +Acked-by: Liviu Dudau +Link: https://lore.kernel.org/20240826054934.10724-2-krzysztof.kozlowski@linaro.org +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bus/arm-integrator-lm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/bus/arm-integrator-lm.c ++++ b/drivers/bus/arm-integrator-lm.c +@@ -84,6 +84,7 @@ static int integrator_ap_lm_probe(struct + return -ENODEV; + } + map = syscon_node_to_regmap(syscon); ++ of_node_put(syscon); + if (IS_ERR(map)) { + dev_err(dev, + "could not find Integrator/AP system controller\n"); diff --git a/queue-5.10/crypto-ccp-properly-unregister-dev-sev-on-sev-platform_status-failure.patch b/queue-5.10/crypto-ccp-properly-unregister-dev-sev-on-sev-platform_status-failure.patch new file mode 100644 index 00000000000..cf99d0d49d7 --- /dev/null +++ b/queue-5.10/crypto-ccp-properly-unregister-dev-sev-on-sev-platform_status-failure.patch @@ -0,0 +1,80 @@ +From ce3d2d6b150ba8528f3218ebf0cee2c2c572662d Mon Sep 17 00:00:00 2001 +From: Pavan Kumar Paluri +Date: Thu, 15 Aug 2024 07:25:00 -0500 +Subject: crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure + +From: Pavan Kumar Paluri + +commit ce3d2d6b150ba8528f3218ebf0cee2c2c572662d upstream. + +In case of sev PLATFORM_STATUS failure, sev_get_api_version() fails +resulting in sev_data field of psp_master nulled out. This later becomes +a problem when unloading the ccp module because the device has not been +unregistered (via misc_deregister()) before clearing the sev_data field +of psp_master. As a result, on reloading the ccp module, a duplicate +device issue is encountered as can be seen from the dmesg log below. + +on reloading ccp module via modprobe ccp + +Call Trace: + + dump_stack_lvl+0xd7/0xf0 + dump_stack+0x10/0x20 + sysfs_warn_dup+0x5c/0x70 + sysfs_create_dir_ns+0xbc/0xd + kobject_add_internal+0xb1/0x2f0 + kobject_add+0x7a/0xe0 + ? srso_alias_return_thunk+0x5/0xfbef5 + ? get_device_parent+0xd4/0x1e0 + ? __pfx_klist_children_get+0x10/0x10 + device_add+0x121/0x870 + ? srso_alias_return_thunk+0x5/0xfbef5 + device_create_groups_vargs+0xdc/0x100 + device_create_with_groups+0x3f/0x60 + misc_register+0x13b/0x1c0 + sev_dev_init+0x1d4/0x290 [ccp] + psp_dev_init+0x136/0x300 [ccp] + sp_init+0x6f/0x80 [ccp] + sp_pci_probe+0x2a6/0x310 [ccp] + ? srso_alias_return_thunk+0x5/0xfbef5 + local_pci_probe+0x4b/0xb0 + work_for_cpu_fn+0x1a/0x30 + process_one_work+0x203/0x600 + worker_thread+0x19e/0x350 + ? __pfx_worker_thread+0x10/0x10 + kthread+0xeb/0x120 + ? __pfx_kthread+0x10/0x10 + ret_from_fork+0x3c/0x60 + ? __pfx_kthread+0x10/0x10 + ret_from_fork_asm+0x1a/0x30 + + kobject: kobject_add_internal failed for sev with -EEXIST, don't try to register things with the same name in the same directory. + ccp 0000:22:00.1: sev initialization failed + ccp 0000:22:00.1: psp initialization failed + ccp 0000:a2:00.1: no command queues available + ccp 0000:a2:00.1: psp enabled + +Address this issue by unregistering the /dev/sev before clearing out +sev_data in case of PLATFORM_STATUS failure. + +Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") +Cc: stable@vger.kernel.org +Signed-off-by: Pavan Kumar Paluri +Acked-by: Tom Lendacky +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/crypto/ccp/sev-dev.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/crypto/ccp/sev-dev.c ++++ b/drivers/crypto/ccp/sev-dev.c +@@ -1129,6 +1129,8 @@ void sev_pci_init(void) + return; + + err: ++ sev_dev_destroy(psp_master); ++ + psp_master->sev_data = NULL; + } + diff --git a/queue-5.10/firmware_loader-block-path-traversal.patch b/queue-5.10/firmware_loader-block-path-traversal.patch new file mode 100644 index 00000000000..4b64e821f0a --- /dev/null +++ b/queue-5.10/firmware_loader-block-path-traversal.patch @@ -0,0 +1,106 @@ +From f0e5311aa8022107d63c54e2f03684ec097d1394 Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Wed, 28 Aug 2024 01:45:48 +0200 +Subject: firmware_loader: Block path traversal + +From: Jann Horn + +commit f0e5311aa8022107d63c54e2f03684ec097d1394 upstream. + +Most firmware names are hardcoded strings, or are constructed from fairly +constrained format strings where the dynamic parts are just some hex +numbers or such. + +However, there are a couple codepaths in the kernel where firmware file +names contain string components that are passed through from a device or +semi-privileged userspace; the ones I could find (not counting interfaces +that require root privileges) are: + + - lpfc_sli4_request_firmware_update() seems to construct the firmware + filename from "ModelName", a string that was previously parsed out of + some descriptor ("Vital Product Data") in lpfc_fill_vpd() + - nfp_net_fw_find() seems to construct a firmware filename from a model + name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I + think parses some descriptor that was read from the device. + (But this case likely isn't exploitable because the format string looks + like "netronome/nic_%s", and there shouldn't be any *folders* starting + with "netronome/nic_". The previous case was different because there, + the "%s" is *at the start* of the format string.) + - module_flash_fw_schedule() is reachable from the + ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as + GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is + enough to pass the privilege check), and takes a userspace-provided + firmware name. + (But I think to reach this case, you need to have CAP_NET_ADMIN over a + network namespace that a special kind of ethernet device is mapped into, + so I think this is not a viable attack path in practice.) + +Fix it by rejecting any firmware names containing ".." path components. + +For what it's worth, I went looking and haven't found any USB device +drivers that use the firmware loader dangerously. + +Cc: stable@vger.kernel.org +Reviewed-by: Danilo Krummrich +Fixes: abb139e75c2c ("firmware: teach the kernel to load firmware files directly from the filesystem") +Signed-off-by: Jann Horn +Acked-by: Luis Chamberlain +Link: https://lore.kernel.org/r/20240828-firmware-traversal-v3-1-c76529c63b5f@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/firmware_loader/main.c | 30 ++++++++++++++++++++++++++++++ + 1 file changed, 30 insertions(+) + +--- a/drivers/base/firmware_loader/main.c ++++ b/drivers/base/firmware_loader/main.c +@@ -786,6 +786,26 @@ static void fw_abort_batch_reqs(struct f + mutex_unlock(&fw_lock); + } + ++/* ++ * Reject firmware file names with ".." path components. ++ * There are drivers that construct firmware file names from device-supplied ++ * strings, and we don't want some device to be able to tell us "I would like to ++ * be sent my firmware from ../../../etc/shadow, please". ++ * ++ * Search for ".." surrounded by either '/' or start/end of string. ++ * ++ * This intentionally only looks at the firmware name, not at the firmware base ++ * directory or at symlink contents. ++ */ ++static bool name_contains_dotdot(const char *name) ++{ ++ size_t name_len = strlen(name); ++ ++ return strcmp(name, "..") == 0 || strncmp(name, "../", 3) == 0 || ++ strstr(name, "/../") != NULL || ++ (name_len >= 3 && strcmp(name+name_len-3, "/..") == 0); ++} ++ + /* called from request_firmware() and request_firmware_work_func() */ + static int + _request_firmware(const struct firmware **firmware_p, const char *name, +@@ -806,6 +826,14 @@ _request_firmware(const struct firmware + goto out; + } + ++ if (name_contains_dotdot(name)) { ++ dev_warn(device, ++ "Firmware load for '%s' refused, path contains '..' component\n", ++ name); ++ ret = -EINVAL; ++ goto out; ++ } ++ + ret = _request_firmware_prepare(&fw, name, device, buf, size, + offset, opt_flags); + if (ret <= 0) /* error or already assigned */ +@@ -876,6 +904,8 @@ _request_firmware(const struct firmware + * @name will be used as $FIRMWARE in the uevent environment and + * should be distinctive enough not to be confused with any other + * firmware image for this or any other device. ++ * It must not contain any ".." path components - "foo/bar..bin" is ++ * allowed, but "foo/../bar.bin" is not. + * + * Caller must hold the reference count of @device. + * diff --git a/queue-5.10/series b/queue-5.10/series index cd5b2edda5d..4472bd1f4d9 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -233,3 +233,10 @@ input-i8042-add-tuxedo-stellaris-16-gen5-amd-to-i8042-quirk-table.patch input-i8042-add-tuxedo-stellaris-15-slim-gen6-amd-to-i8042-quirk-table.patch input-i8042-add-another-board-name-for-tuxedo-stellaris-gen5-amd-line.patch drm-amd-display-round-calculated-vtotal.patch +usb-appledisplay-close-race-between-probe-and-completion-handler.patch +usb-misc-cypress_cy7c63-check-for-short-transfer.patch +usb-class-cdc-acm-fix-race-between-get_serial-and-set_serial.patch +bus-integrator-lm-fix-of-node-leak-in-probe.patch +firmware_loader-block-path-traversal.patch +tty-rp2-fix-reset-with-non-forgiving-pcie-host-bridges.patch +crypto-ccp-properly-unregister-dev-sev-on-sev-platform_status-failure.patch diff --git a/queue-5.10/tty-rp2-fix-reset-with-non-forgiving-pcie-host-bridges.patch b/queue-5.10/tty-rp2-fix-reset-with-non-forgiving-pcie-host-bridges.patch new file mode 100644 index 00000000000..c6eb679d45b --- /dev/null +++ b/queue-5.10/tty-rp2-fix-reset-with-non-forgiving-pcie-host-bridges.patch @@ -0,0 +1,44 @@ +From f16dd10ba342c429b1e36ada545fb36d4d1f0e63 Mon Sep 17 00:00:00 2001 +From: Florian Fainelli +Date: Fri, 6 Sep 2024 15:54:33 -0700 +Subject: tty: rp2: Fix reset with non forgiving PCIe host bridges + +From: Florian Fainelli + +commit f16dd10ba342c429b1e36ada545fb36d4d1f0e63 upstream. + +The write to RP2_GLOBAL_CMD followed by an immediate read of +RP2_GLOBAL_CMD in rp2_reset_asic() is intented to flush out the write, +however by then the device is already in reset and cannot respond to a +memory cycle access. + +On platforms such as the Raspberry Pi 4 and others using the +pcie-brcmstb.c driver, any memory access to a device that cannot respond +is met with a fatal system error, rather than being substituted with all +1s as is usually the case on PC platforms. + +Swapping the delay and the read ensures that the device has finished +resetting before we attempt to read from it. + +Fixes: 7d9f49afa451 ("serial: rp2: New driver for Comtrol RocketPort 2 cards") +Cc: stable +Suggested-by: Jim Quinlan +Signed-off-by: Florian Fainelli +Link: https://lore.kernel.org/r/20240906225435.707837-1-florian.fainelli@broadcom.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/rp2.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/rp2.c ++++ b/drivers/tty/serial/rp2.c +@@ -600,8 +600,8 @@ static void rp2_reset_asic(struct rp2_ca + u32 clk_cfg; + + writew(1, base + RP2_GLOBAL_CMD); +- readw(base + RP2_GLOBAL_CMD); + msleep(100); ++ readw(base + RP2_GLOBAL_CMD); + writel(0, base + RP2_CLK_PRESCALER); + + /* TDM clock configuration */ diff --git a/queue-5.10/usb-appledisplay-close-race-between-probe-and-completion-handler.patch b/queue-5.10/usb-appledisplay-close-race-between-probe-and-completion-handler.patch new file mode 100644 index 00000000000..ba0fa1c5058 --- /dev/null +++ b/queue-5.10/usb-appledisplay-close-race-between-probe-and-completion-handler.patch @@ -0,0 +1,66 @@ +From 8265d06b7794493d82c5c21a12d7ba43eccc30cb Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Thu, 12 Sep 2024 14:32:59 +0200 +Subject: USB: appledisplay: close race between probe and completion handler + +From: Oliver Neukum + +commit 8265d06b7794493d82c5c21a12d7ba43eccc30cb upstream. + +There is a small window during probing when IO is running +but the backlight is not registered. Processing events +during that time will crash. The completion handler +needs to check for a backlight before scheduling work. + +The bug is as old as the driver. + +Signed-off-by: Oliver Neukum +CC: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240912123317.1026049-1-oneukum@suse.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/misc/appledisplay.c | 15 +++++++++++---- + 1 file changed, 11 insertions(+), 4 deletions(-) + +--- a/drivers/usb/misc/appledisplay.c ++++ b/drivers/usb/misc/appledisplay.c +@@ -107,7 +107,12 @@ static void appledisplay_complete(struct + case ACD_BTN_BRIGHT_UP: + case ACD_BTN_BRIGHT_DOWN: + pdata->button_pressed = 1; +- schedule_delayed_work(&pdata->work, 0); ++ /* ++ * there is a window during which no device ++ * is registered ++ */ ++ if (pdata->bd ) ++ schedule_delayed_work(&pdata->work, 0); + break; + case ACD_BTN_NONE: + default: +@@ -202,6 +207,7 @@ static int appledisplay_probe(struct usb + const struct usb_device_id *id) + { + struct backlight_properties props; ++ struct backlight_device *backlight; + struct appledisplay *pdata; + struct usb_device *udev = interface_to_usbdev(iface); + struct usb_endpoint_descriptor *endpoint; +@@ -272,13 +278,14 @@ static int appledisplay_probe(struct usb + memset(&props, 0, sizeof(struct backlight_properties)); + props.type = BACKLIGHT_RAW; + props.max_brightness = 0xff; +- pdata->bd = backlight_device_register(bl_name, NULL, pdata, ++ backlight = backlight_device_register(bl_name, NULL, pdata, + &appledisplay_bl_data, &props); +- if (IS_ERR(pdata->bd)) { ++ if (IS_ERR(backlight)) { + dev_err(&iface->dev, "Backlight registration failed\n"); +- retval = PTR_ERR(pdata->bd); ++ retval = PTR_ERR(backlight); + goto error; + } ++ pdata->bd = backlight; + + /* Try to get brightness */ + brightness = appledisplay_bl_get_brightness(pdata->bd); diff --git a/queue-5.10/usb-class-cdc-acm-fix-race-between-get_serial-and-set_serial.patch b/queue-5.10/usb-class-cdc-acm-fix-race-between-get_serial-and-set_serial.patch new file mode 100644 index 00000000000..331b8219e76 --- /dev/null +++ b/queue-5.10/usb-class-cdc-acm-fix-race-between-get_serial-and-set_serial.patch @@ -0,0 +1,41 @@ +From b41c1fa155ba56d125885b0191aabaf3c508d0a3 Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Thu, 12 Sep 2024 16:19:06 +0200 +Subject: USB: class: CDC-ACM: fix race between get_serial and set_serial + +From: Oliver Neukum + +commit b41c1fa155ba56d125885b0191aabaf3c508d0a3 upstream. + +TIOCGSERIAL is an ioctl. Thus it must be atomic. It returns +two values. Racing with set_serial it can return an inconsistent +result. The mutex must be taken. + +In terms of logic the bug is as old as the driver. In terms of +code it goes back to the conversion to the get_serial and +set_serial methods. + +Signed-off-by: Oliver Neukum +Cc: stable +Fixes: 99f75a1fcd865 ("cdc-acm: switch to ->[sg]et_serial()") +Link: https://lore.kernel.org/r/20240912141916.1044393-1-oneukum@suse.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/class/cdc-acm.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/usb/class/cdc-acm.c ++++ b/drivers/usb/class/cdc-acm.c +@@ -942,10 +942,12 @@ static int get_serial_info(struct tty_st + struct acm *acm = tty->driver_data; + + ss->line = acm->minor; ++ mutex_lock(&acm->port.mutex); + ss->close_delay = jiffies_to_msecs(acm->port.close_delay) / 10; + ss->closing_wait = acm->port.closing_wait == ASYNC_CLOSING_WAIT_NONE ? + ASYNC_CLOSING_WAIT_NONE : + jiffies_to_msecs(acm->port.closing_wait) / 10; ++ mutex_unlock(&acm->port.mutex); + return 0; + } + diff --git a/queue-5.10/usb-misc-cypress_cy7c63-check-for-short-transfer.patch b/queue-5.10/usb-misc-cypress_cy7c63-check-for-short-transfer.patch new file mode 100644 index 00000000000..5a3754bcb5f --- /dev/null +++ b/queue-5.10/usb-misc-cypress_cy7c63-check-for-short-transfer.patch @@ -0,0 +1,42 @@ +From 49cd2f4d747eeb3050b76245a7f72aa99dbd3310 Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Thu, 12 Sep 2024 14:54:43 +0200 +Subject: USB: misc: cypress_cy7c63: check for short transfer + +From: Oliver Neukum + +commit 49cd2f4d747eeb3050b76245a7f72aa99dbd3310 upstream. + +As we process the second byte of a control transfer, transfers +of less than 2 bytes must be discarded. + +This bug is as old as the driver. + +SIgned-off-by: Oliver Neukum +CC: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240912125449.1030536-1-oneukum@suse.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/misc/cypress_cy7c63.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/usb/misc/cypress_cy7c63.c ++++ b/drivers/usb/misc/cypress_cy7c63.c +@@ -88,6 +88,9 @@ static int vendor_command(struct cypress + USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER, + address, data, iobuf, CYPRESS_MAX_REQSIZE, + USB_CTRL_GET_TIMEOUT); ++ /* we must not process garbage */ ++ if (retval < 2) ++ goto err_buf; + + /* store returned data (more READs to be added) */ + switch (request) { +@@ -107,6 +110,7 @@ static int vendor_command(struct cypress + break; + } + ++err_buf: + kfree(iobuf); + error: + return retval;