From 79bf8b43f28c8b95d56fde9e4088e97f8fd1f5c7 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 16 May 2022 10:03:25 +0200 Subject: [PATCH] 5.10-stable patches added patches: firmware_loader-use-kernel-credentials-when-reading-firmware.patch tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch usb-cdc-wdm-fix-reading-stuck-on-device-close.patch --- ...el-credentials-when-reading-firmware.patch | 87 +++++++++++++++++++ queue-5.10/series | 4 + ...-mux-activation-issues-in-gsm_config.patch | 60 +++++++++++++ ...ll-ptr-deref-in-digicolor_uart_probe.patch | 40 +++++++++ ...dm-fix-reading-stuck-on-device-close.patch | 56 ++++++++++++ 5 files changed, 247 insertions(+) create mode 100644 queue-5.10/firmware_loader-use-kernel-credentials-when-reading-firmware.patch create mode 100644 queue-5.10/tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch create mode 100644 queue-5.10/tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch create mode 100644 queue-5.10/usb-cdc-wdm-fix-reading-stuck-on-device-close.patch diff --git a/queue-5.10/firmware_loader-use-kernel-credentials-when-reading-firmware.patch b/queue-5.10/firmware_loader-use-kernel-credentials-when-reading-firmware.patch new file mode 100644 index 00000000000..adcfedfe568 --- /dev/null +++ b/queue-5.10/firmware_loader-use-kernel-credentials-when-reading-firmware.patch @@ -0,0 +1,87 @@ +From 581dd69830341d299b0c097fc366097ab497d679 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thi=C3=A9baud=20Weksteen?= +Date: Mon, 2 May 2022 10:49:52 +1000 +Subject: firmware_loader: use kernel credentials when reading firmware +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thiébaud Weksteen + +commit 581dd69830341d299b0c097fc366097ab497d679 upstream. + +Device drivers may decide to not load firmware when probed to avoid +slowing down the boot process should the firmware filesystem not be +available yet. In this case, the firmware loading request may be done +when a device file associated with the driver is first accessed. The +credentials of the userspace process accessing the device file may be +used to validate access to the firmware files requested by the driver. +Ensure that the kernel assumes the responsibility of reading the +firmware. + +This was observed on Android for a graphic driver loading their firmware +when the device file (e.g. /dev/mali0) was first opened by userspace +(i.e. surfaceflinger). The security context of surfaceflinger was used +to validate the access to the firmware file (e.g. +/vendor/firmware/mali.bin). + +Previously, Android configurations were not setting up the +firmware_class.path command line argument and were relying on the +userspace fallback mechanism. In this case, the security context of the +userspace daemon (i.e. ueventd) was consistently used to read firmware +files. More Android devices are now found to set firmware_class.path +which gives the kernel the opportunity to read the firmware directly +(via kernel_read_file_from_path_initns). In this scenario, the current +process credentials were used, even if unrelated to the loading of the +firmware file. + +Signed-off-by: Thiébaud Weksteen +Cc: # 5.10 +Reviewed-by: Paul Moore +Acked-by: Luis Chamberlain +Link: https://lore.kernel.org/r/20220502004952.3970800-1-tweek@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/firmware_loader/main.c | 17 +++++++++++++++++ + 1 file changed, 17 insertions(+) + +--- a/drivers/base/firmware_loader/main.c ++++ b/drivers/base/firmware_loader/main.c +@@ -793,6 +793,8 @@ _request_firmware(const struct firmware + size_t offset, u32 opt_flags) + { + struct firmware *fw = NULL; ++ struct cred *kern_cred = NULL; ++ const struct cred *old_cred; + bool nondirect = false; + int ret; + +@@ -809,6 +811,18 @@ _request_firmware(const struct firmware + if (ret <= 0) /* error or already assigned */ + goto out; + ++ /* ++ * We are about to try to access the firmware file. Because we may have been ++ * called by a driver when serving an unrelated request from userland, we use ++ * the kernel credentials to read the file. ++ */ ++ kern_cred = prepare_kernel_cred(NULL); ++ if (!kern_cred) { ++ ret = -ENOMEM; ++ goto out; ++ } ++ old_cred = override_creds(kern_cred); ++ + ret = fw_get_filesystem_firmware(device, fw->priv, "", NULL); + + /* Only full reads can support decompression, platform, and sysfs. */ +@@ -834,6 +848,9 @@ _request_firmware(const struct firmware + } else + ret = assign_fw(fw, device); + ++ revert_creds(old_cred); ++ put_cred(kern_cred); ++ + out: + if (ret < 0) { + fw_abort_batch_reqs(fw); diff --git a/queue-5.10/series b/queue-5.10/series index 5e805f7da20..c36b5546cb3 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -36,3 +36,7 @@ s390-disable-warray-bounds.patch net-emaclite-don-t-advertise-1000base-t-and-do-auto-.patch net-sfp-add-tx-fault-workaround-for-huawei-ma5671a-s.patch tcp-resalt-the-secret-every-10-seconds.patch +firmware_loader-use-kernel-credentials-when-reading-firmware.patch +tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch +tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch +usb-cdc-wdm-fix-reading-stuck-on-device-close.patch diff --git a/queue-5.10/tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch b/queue-5.10/tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch new file mode 100644 index 00000000000..0db04e15aa2 --- /dev/null +++ b/queue-5.10/tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch @@ -0,0 +1,60 @@ +From edd5f60c340086891fab094ad61270d6c80f9ca4 Mon Sep 17 00:00:00 2001 +From: Daniel Starke +Date: Wed, 4 May 2022 10:17:32 +0200 +Subject: tty: n_gsm: fix mux activation issues in gsm_config() + +From: Daniel Starke + +commit edd5f60c340086891fab094ad61270d6c80f9ca4 upstream. + +The current implementation activates the mux if it was restarted and opens +the control channel if the mux was previously closed and we are now acting +as initiator instead of responder, which is the default setting. +This has two issues. +1) No mux is activated if we keep all default values and only switch to +initiator. The control channel is not allocated but will be opened next +which results in a NULL pointer dereference. +2) Switching the configuration after it was once configured while keeping +the initiator value the same will not reopen the control channel if it was +closed due to parameter incompatibilities. The mux remains dead. + +Fix 1) by always activating the mux if it is dead after configuration. +Fix 2) by always opening the control channel after mux activation. + +Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") +Cc: stable@vger.kernel.org +Signed-off-by: Daniel Starke +Link: https://lore.kernel.org/r/20220504081733.3494-2-daniel.starke@siemens.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/n_gsm.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +--- a/drivers/tty/n_gsm.c ++++ b/drivers/tty/n_gsm.c +@@ -2276,6 +2276,7 @@ static void gsm_copy_config_values(struc + + static int gsm_config(struct gsm_mux *gsm, struct gsm_config *c) + { ++ int ret = 0; + int need_close = 0; + int need_restart = 0; + +@@ -2343,10 +2344,13 @@ static int gsm_config(struct gsm_mux *gs + * FIXME: We need to separate activation/deactivation from adding + * and removing from the mux array + */ +- if (need_restart) +- gsm_activate_mux(gsm); +- if (gsm->initiator && need_close) +- gsm_dlci_begin_open(gsm->dlci[0]); ++ if (gsm->dead) { ++ ret = gsm_activate_mux(gsm); ++ if (ret) ++ return ret; ++ if (gsm->initiator) ++ gsm_dlci_begin_open(gsm->dlci[0]); ++ } + return 0; + } + diff --git a/queue-5.10/tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch b/queue-5.10/tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch new file mode 100644 index 00000000000..9cc21eb5e3a --- /dev/null +++ b/queue-5.10/tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch @@ -0,0 +1,40 @@ +From 447ee1516f19f534a228dda237eddb202f23e163 Mon Sep 17 00:00:00 2001 +From: Yang Yingliang +Date: Thu, 5 May 2022 20:46:21 +0800 +Subject: tty/serial: digicolor: fix possible null-ptr-deref in digicolor_uart_probe() + +From: Yang Yingliang + +commit 447ee1516f19f534a228dda237eddb202f23e163 upstream. + +It will cause null-ptr-deref when using 'res', if platform_get_resource() +returns NULL, so move using 'res' after devm_ioremap_resource() that +will check it to avoid null-ptr-deref. +And use devm_platform_get_and_ioremap_resource() to simplify code. + +Fixes: 5930cb3511df ("serial: driver for Conexant Digicolor USART") +Signed-off-by: Yang Yingliang +Reviewed-by: Baruch Siach +Cc: stable +Link: https://lore.kernel.org/r/20220505124621.1592697-1-yangyingliang@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/digicolor-usart.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/tty/serial/digicolor-usart.c ++++ b/drivers/tty/serial/digicolor-usart.c +@@ -471,11 +471,10 @@ static int digicolor_uart_probe(struct p + if (IS_ERR(uart_clk)) + return PTR_ERR(uart_clk); + +- res = platform_get_resource(pdev, IORESOURCE_MEM, 0); +- dp->port.mapbase = res->start; +- dp->port.membase = devm_ioremap_resource(&pdev->dev, res); ++ dp->port.membase = devm_platform_get_and_ioremap_resource(pdev, 0, &res); + if (IS_ERR(dp->port.membase)) + return PTR_ERR(dp->port.membase); ++ dp->port.mapbase = res->start; + + irq = platform_get_irq(pdev, 0); + if (irq < 0) diff --git a/queue-5.10/usb-cdc-wdm-fix-reading-stuck-on-device-close.patch b/queue-5.10/usb-cdc-wdm-fix-reading-stuck-on-device-close.patch new file mode 100644 index 00000000000..cdcc75fc68b --- /dev/null +++ b/queue-5.10/usb-cdc-wdm-fix-reading-stuck-on-device-close.patch @@ -0,0 +1,56 @@ +From 01e01f5c89773c600a9f0b32c888de0146066c3a Mon Sep 17 00:00:00 2001 +From: Sergey Ryazanov +Date: Sun, 1 May 2022 20:58:28 +0300 +Subject: usb: cdc-wdm: fix reading stuck on device close + +From: Sergey Ryazanov + +commit 01e01f5c89773c600a9f0b32c888de0146066c3a upstream. + +cdc-wdm tracks whether a response reading request is in-progress and +blocks the next request from being sent until the previous request is +completed. As soon as last user closes the cdc-wdm device file, the +driver cancels any ongoing requests, resets the pending response +counter, but leaves the response reading in-progress flag +(WDM_RESPONDING) untouched. + +So if the user closes the device file during the response receive +request is being performed, no more data will be obtained from the +modem. The request will be cancelled, effectively preventing the +WDM_RESPONDING flag from being reseted. Keeping the flag set will +prevent a new response receive request from being sent, permanently +blocking the read path. The read path will staying blocked until the +module will be reloaded or till the modem will be re-attached. + +This stuck has been observed with a Huawei E3372 modem attached to an +OpenWrt router and using the comgt utility to set up a network +connection. + +Fix this issue by clearing the WDM_RESPONDING flag on the device file +close. + +Without this fix, the device reading stuck can be easily reproduced in a +few connection establishing attempts. With this fix, a load test for +modem connection re-establishing worked for several hours without any +issues. + +Fixes: 922a5eadd5a3 ("usb: cdc-wdm: Fix race between autosuspend and reading from the device") +Signed-off-by: Sergey Ryazanov +Cc: stable +Acked-by: Oliver Neukum +Link: https://lore.kernel.org/r/20220501175828.8185-1-ryazanov.s.a@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/class/cdc-wdm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/class/cdc-wdm.c ++++ b/drivers/usb/class/cdc-wdm.c +@@ -755,6 +755,7 @@ static int wdm_release(struct inode *ino + poison_urbs(desc); + spin_lock_irq(&desc->iuspin); + desc->resp_count = 0; ++ clear_bit(WDM_RESPONDING, &desc->flags); + spin_unlock_irq(&desc->iuspin); + desc->manage_power(desc->intf, 0); + unpoison_urbs(desc); -- 2.47.3