--- /dev/null
+From 15a62b81175885b5adfcaf49870466e3603f06c7 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Mon, 26 Aug 2024 07:49:34 +0200
+Subject: bus: integrator-lm: fix OF node leak in probe()
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+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 <krzysztof.kozlowski@linaro.org>
+Acked-by: Liviu Dudau <liviu.dudau@arm.com>
+Link: https://lore.kernel.org/20240826054934.10724-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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");
--- /dev/null
+From ce3d2d6b150ba8528f3218ebf0cee2c2c572662d Mon Sep 17 00:00:00 2001
+From: Pavan Kumar Paluri <papaluri@amd.com>
+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 <papaluri@amd.com>
+
+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:
+ <TASK>
+ 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
+ </TASK>
+ 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 <papaluri@amd.com>
+Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From f0e5311aa8022107d63c54e2f03684ec097d1394 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 28 Aug 2024 01:45:48 +0200
+Subject: firmware_loader: Block path traversal
+
+From: Jann Horn <jannh@google.com>
+
+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 <dakr@kernel.org>
+Fixes: abb139e75c2c ("firmware: teach the kernel to load firmware files directly from the filesystem")
+Signed-off-by: Jann Horn <jannh@google.com>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Link: https://lore.kernel.org/r/20240828-firmware-traversal-v3-1-c76529c63b5f@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
+ *
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
--- /dev/null
+From f16dd10ba342c429b1e36ada545fb36d4d1f0e63 Mon Sep 17 00:00:00 2001
+From: Florian Fainelli <florian.fainelli@broadcom.com>
+Date: Fri, 6 Sep 2024 15:54:33 -0700
+Subject: tty: rp2: Fix reset with non forgiving PCIe host bridges
+
+From: Florian Fainelli <florian.fainelli@broadcom.com>
+
+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 <stable@kernel.org>
+Suggested-by: Jim Quinlan <james.quinlan@broadcom.com>
+Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
+Link: https://lore.kernel.org/r/20240906225435.707837-1-florian.fainelli@broadcom.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 8265d06b7794493d82c5c21a12d7ba43eccc30cb Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Thu, 12 Sep 2024 14:32:59 +0200
+Subject: USB: appledisplay: close race between probe and completion handler
+
+From: Oliver Neukum <oneukum@suse.com>
+
+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 <oneukum@suse.com>
+CC: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240912123317.1026049-1-oneukum@suse.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From b41c1fa155ba56d125885b0191aabaf3c508d0a3 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+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 <oneukum@suse.com>
+
+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 <oneukum@suse.com>
+Cc: stable <stable@kernel.org>
+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 <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 49cd2f4d747eeb3050b76245a7f72aa99dbd3310 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Thu, 12 Sep 2024 14:54:43 +0200
+Subject: USB: misc: cypress_cy7c63: check for short transfer
+
+From: Oliver Neukum <oneukum@suse.com>
+
+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 <oneukum@suse.com>
+CC: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240912125449.1030536-1-oneukum@suse.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
