From: Greg Kroah-Hartman Date: Mon, 16 May 2022 08:01:13 +0000 (+0200) Subject: 5.17-stable patches X-Git-Tag: v4.9.315~43 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=98cd531968494f45bc7a0bf05c5b4ca38a7af2b9;p=thirdparty%2Fkernel%2Fstable-queue.git 5.17-stable patches added patches: firmware_loader-use-kernel-credentials-when-reading-firmware.patch kvm-ppc-book3s-pr-enable-msr_dr-for-switch_mmu_context.patch tty-n_gsm-fix-buffer-over-read-in-gsm_dlci_data.patch tty-n_gsm-fix-invalid-gsmtty_write_room-result.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 usb-gadget-uvc-allow-for-application-to-cleanly-shutdown.patch usb-xhci-mtk-fix-fs-isoc-s-transfer-error.patch x86-mm-fix-marking-of-unused-sub-pmd-ranges.patch --- diff --git a/queue-5.17/firmware_loader-use-kernel-credentials-when-reading-firmware.patch b/queue-5.17/firmware_loader-use-kernel-credentials-when-reading-firmware.patch new file mode 100644 index 00000000000..1ad741555e8 --- /dev/null +++ b/queue-5.17/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 +@@ -735,6 +735,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; + +@@ -751,6 +753,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. */ +@@ -776,6 +790,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.17/kvm-ppc-book3s-pr-enable-msr_dr-for-switch_mmu_context.patch b/queue-5.17/kvm-ppc-book3s-pr-enable-msr_dr-for-switch_mmu_context.patch new file mode 100644 index 00000000000..c33d4ff7093 --- /dev/null +++ b/queue-5.17/kvm-ppc-book3s-pr-enable-msr_dr-for-switch_mmu_context.patch @@ -0,0 +1,66 @@ +From ee8348496c77e3737d0a6cda307a521f2cff954f Mon Sep 17 00:00:00 2001 +From: Alexander Graf +Date: Tue, 10 May 2022 14:37:17 +0200 +Subject: KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context() + +From: Alexander Graf + +commit ee8348496c77e3737d0a6cda307a521f2cff954f upstream. + +Commit 863771a28e27 ("powerpc/32s: Convert switch_mmu_context() to C") +moved the switch_mmu_context() to C. While in principle a good idea, it +meant that the function now uses the stack. The stack is not accessible +from real mode though. + +So to keep calling the function, let's turn on MSR_DR while we call it. +That way, all pointer references to the stack are handled virtually. + +In addition, make sure to save/restore r12 on the stack, as it may get +clobbered by the C function. + +Fixes: 863771a28e27 ("powerpc/32s: Convert switch_mmu_context() to C") +Cc: stable@vger.kernel.org # v5.14+ +Reported-by: Matt Evans +Signed-off-by: Alexander Graf +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20220510123717.24508-1-graf@amazon.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kvm/book3s_32_sr.S | 26 +++++++++++++++++++++----- + 1 file changed, 21 insertions(+), 5 deletions(-) + +--- a/arch/powerpc/kvm/book3s_32_sr.S ++++ b/arch/powerpc/kvm/book3s_32_sr.S +@@ -122,11 +122,27 @@ + + /* 0x0 - 0xb */ + +- /* 'current->mm' needs to be in r4 */ +- tophys(r4, r2) +- lwz r4, MM(r4) +- tophys(r4, r4) +- /* This only clobbers r0, r3, r4 and r5 */ ++ /* switch_mmu_context() needs paging, let's enable it */ ++ mfmsr r9 ++ ori r11, r9, MSR_DR ++ mtmsr r11 ++ sync ++ ++ /* switch_mmu_context() clobbers r12, rescue it */ ++ SAVE_GPR(12, r1) ++ ++ /* Calling switch_mmu_context(, current->mm, ); */ ++ lwz r4, MM(r2) + bl switch_mmu_context + ++ /* restore r12 */ ++ REST_GPR(12, r1) ++ ++ /* Disable paging again */ ++ mfmsr r9 ++ li r6, MSR_DR ++ andc r9, r9, r6 ++ mtmsr r9 ++ sync ++ + .endm diff --git a/queue-5.17/series b/queue-5.17/series index c1d5535da01..055ad47e998 100644 --- a/queue-5.17/series +++ b/queue-5.17/series @@ -68,3 +68,13 @@ tcp-drop-the-hash_32-part-from-the-index-calculation.patch block-do-not-call-folio_next-on-an-unreferenced-foli.patch interconnect-restore-sync-state-by-ignoring-ipa-virt.patch perf-tests-fix-coresight-perf-test-failure.patch +firmware_loader-use-kernel-credentials-when-reading-firmware.patch +kvm-ppc-book3s-pr-enable-msr_dr-for-switch_mmu_context.patch +usb-xhci-mtk-fix-fs-isoc-s-transfer-error.patch +x86-mm-fix-marking-of-unused-sub-pmd-ranges.patch +tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch +tty-n_gsm-fix-buffer-over-read-in-gsm_dlci_data.patch +tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch +tty-n_gsm-fix-invalid-gsmtty_write_room-result.patch +usb-gadget-uvc-allow-for-application-to-cleanly-shutdown.patch +usb-cdc-wdm-fix-reading-stuck-on-device-close.patch diff --git a/queue-5.17/tty-n_gsm-fix-buffer-over-read-in-gsm_dlci_data.patch b/queue-5.17/tty-n_gsm-fix-buffer-over-read-in-gsm_dlci_data.patch new file mode 100644 index 00000000000..36c16433af7 --- /dev/null +++ b/queue-5.17/tty-n_gsm-fix-buffer-over-read-in-gsm_dlci_data.patch @@ -0,0 +1,37 @@ +From fd442e5ba30aaa75ea47b32149e7a3110dc20a46 Mon Sep 17 00:00:00 2001 +From: Daniel Starke +Date: Wed, 4 May 2022 10:17:31 +0200 +Subject: tty: n_gsm: fix buffer over-read in gsm_dlci_data() + +From: Daniel Starke + +commit fd442e5ba30aaa75ea47b32149e7a3110dc20a46 upstream. + +'len' is decreased after each octet that has its EA bit set to 0, which +means that the value is encoded with additional octets. However, the final +octet does not decreases 'len' which results in 'len' being one byte too +long. A buffer over-read may occur in tty_insert_flip_string() as it tries +to read one byte more than the passed content size of 'data'. +Decrease 'len' also for the final octet which has the EA bit set to 1 to +write the correct number of bytes from the internal receive buffer to the +virtual tty. + +Fixes: 2e124b4a390c ("TTY: switch tty_flip_buffer_push") +Cc: stable@vger.kernel.org +Signed-off-by: Daniel Starke +Link: https://lore.kernel.org/r/20220504081733.3494-1-daniel.starke@siemens.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/n_gsm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/tty/n_gsm.c ++++ b/drivers/tty/n_gsm.c +@@ -1658,6 +1658,7 @@ static void gsm_dlci_data(struct gsm_dlc + if (len == 0) + return; + } ++ len--; + slen++; + tty = tty_port_tty_get(port); + if (tty) { diff --git a/queue-5.17/tty-n_gsm-fix-invalid-gsmtty_write_room-result.patch b/queue-5.17/tty-n_gsm-fix-invalid-gsmtty_write_room-result.patch new file mode 100644 index 00000000000..1abc2d30738 --- /dev/null +++ b/queue-5.17/tty-n_gsm-fix-invalid-gsmtty_write_room-result.patch @@ -0,0 +1,64 @@ +From 9361ebfbb79fd1bc8594a487c01ad52cdaa391ea Mon Sep 17 00:00:00 2001 +From: Daniel Starke +Date: Wed, 4 May 2022 10:17:33 +0200 +Subject: tty: n_gsm: fix invalid gsmtty_write_room() result + +From: Daniel Starke + +commit 9361ebfbb79fd1bc8594a487c01ad52cdaa391ea upstream. + +gsmtty_write() does not prevent the user to use the full fifo size of 4096 +bytes as allocated in gsm_dlci_alloc(). However, gsmtty_write_room() tries +to limit the return value by 'TX_SIZE' and returns a negative value if the +fifo has more than 'TX_SIZE' bytes stored. This is obviously wrong as +'TX_SIZE' is defined as 512. +Define 'TX_SIZE' to the fifo size and use it accordingly for allocation to +keep the current behavior. Return the correct remaining size of the fifo in +gsmtty_write_room() via kfifo_avail(). + +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-3-daniel.starke@siemens.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/n_gsm.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/drivers/tty/n_gsm.c ++++ b/drivers/tty/n_gsm.c +@@ -137,6 +137,7 @@ struct gsm_dlci { + int retries; + /* Uplink tty if active */ + struct tty_port port; /* The tty bound to this DLCI if there is one */ ++#define TX_SIZE 4096 /* Must be power of 2. */ + struct kfifo fifo; /* Queue fifo for the DLCI */ + int adaption; /* Adaption layer in use */ + int prev_adaption; +@@ -1731,7 +1732,7 @@ static struct gsm_dlci *gsm_dlci_alloc(s + return NULL; + spin_lock_init(&dlci->lock); + mutex_init(&dlci->mutex); +- if (kfifo_alloc(&dlci->fifo, 4096, GFP_KERNEL) < 0) { ++ if (kfifo_alloc(&dlci->fifo, TX_SIZE, GFP_KERNEL) < 0) { + kfree(dlci); + return NULL; + } +@@ -2976,8 +2977,6 @@ static struct tty_ldisc_ops tty_ldisc_pa + * Virtual tty side + */ + +-#define TX_SIZE 512 +- + /** + * gsm_modem_upd_via_data - send modem bits via convergence layer + * @dlci: channel +@@ -3217,7 +3216,7 @@ static unsigned int gsmtty_write_room(st + struct gsm_dlci *dlci = tty->driver_data; + if (dlci->state == DLCI_CLOSED) + return 0; +- return TX_SIZE - kfifo_len(&dlci->fifo); ++ return kfifo_avail(&dlci->fifo); + } + + static unsigned int gsmtty_chars_in_buffer(struct tty_struct *tty) diff --git a/queue-5.17/tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch b/queue-5.17/tty-n_gsm-fix-mux-activation-issues-in-gsm_config.patch new file mode 100644 index 00000000000..0a321a09272 --- /dev/null +++ b/queue-5.17/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 +@@ -2352,6 +2352,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; + +@@ -2419,10 +2420,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.17/tty-serial-digicolor-fix-possible-null-ptr-deref-in-digicolor_uart_probe.patch b/queue-5.17/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.17/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.17/usb-cdc-wdm-fix-reading-stuck-on-device-close.patch b/queue-5.17/usb-cdc-wdm-fix-reading-stuck-on-device-close.patch new file mode 100644 index 00000000000..a622232ea59 --- /dev/null +++ b/queue-5.17/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 +@@ -774,6 +774,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); diff --git a/queue-5.17/usb-gadget-uvc-allow-for-application-to-cleanly-shutdown.patch b/queue-5.17/usb-gadget-uvc-allow-for-application-to-cleanly-shutdown.patch new file mode 100644 index 00000000000..131988ed56d --- /dev/null +++ b/queue-5.17/usb-gadget-uvc-allow-for-application-to-cleanly-shutdown.patch @@ -0,0 +1,143 @@ +From b81ac4395bbeaf36e078dea1a48c02dd97b76235 Mon Sep 17 00:00:00 2001 +From: Dan Vacura +Date: Tue, 3 May 2022 15:10:38 -0500 +Subject: usb: gadget: uvc: allow for application to cleanly shutdown + +From: Dan Vacura + +commit b81ac4395bbeaf36e078dea1a48c02dd97b76235 upstream. + +Several types of kernel panics can occur due to timing during the uvc +gadget removal. This appears to be a problem with gadget resources being +managed by both the client application's v4l2 open/close and the UDC +gadget bind/unbind. Since the concept of USB_GADGET_DELAYED_STATUS +doesn't exist for unbind, add a wait to allow for the application to +close out. + +Some examples of the panics that can occur are: + +<1>[ 1147.652313] Unable to handle kernel NULL pointer dereference at +virtual address 0000000000000028 +<4>[ 1147.652510] Call trace: +<4>[ 1147.652514] usb_gadget_disconnect+0x74/0x1f0 +<4>[ 1147.652516] usb_gadget_deactivate+0x38/0x168 +<4>[ 1147.652520] usb_function_deactivate+0x54/0x90 +<4>[ 1147.652524] uvc_function_disconnect+0x14/0x38 +<4>[ 1147.652527] uvc_v4l2_release+0x34/0xa0 +<4>[ 1147.652537] __fput+0xdc/0x2c0 +<4>[ 1147.652540] ____fput+0x10/0x1c +<4>[ 1147.652545] task_work_run+0xe4/0x12c +<4>[ 1147.652549] do_notify_resume+0x108/0x168 + +<1>[ 282.950561][ T1472] Unable to handle kernel NULL pointer +dereference at virtual address 00000000000005b8 +<6>[ 282.953111][ T1472] Call trace: +<6>[ 282.953121][ T1472] usb_function_deactivate+0x54/0xd4 +<6>[ 282.953134][ T1472] uvc_v4l2_release+0xac/0x1e4 +<6>[ 282.953145][ T1472] v4l2_release+0x134/0x1f0 +<6>[ 282.953167][ T1472] __fput+0xf4/0x428 +<6>[ 282.953178][ T1472] ____fput+0x14/0x24 +<6>[ 282.953193][ T1472] task_work_run+0xac/0x130 + +<3>[ 213.410077][ T29] configfs-gadget gadget: uvc: Failed to queue +request (-108). +<1>[ 213.410116][ T29] Unable to handle kernel NULL pointer +dereference at virtual address 0000000000000003 +<6>[ 213.413460][ T29] Call trace: +<6>[ 213.413474][ T29] uvcg_video_pump+0x1f0/0x384 +<6>[ 213.413489][ T29] process_one_work+0x2a4/0x544 +<6>[ 213.413502][ T29] worker_thread+0x350/0x784 +<6>[ 213.413515][ T29] kthread+0x2ac/0x320 +<6>[ 213.413528][ T29] ret_from_fork+0x10/0x30 + +Signed-off-by: Dan Vacura +Cc: stable +Link: https://lore.kernel.org/r/20220503201039.71720-1-w36195@motorola.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/function/f_uvc.c | 25 +++++++++++++++++++++++++ + drivers/usb/gadget/function/uvc.h | 2 ++ + drivers/usb/gadget/function/uvc_v4l2.c | 3 ++- + 3 files changed, 29 insertions(+), 1 deletion(-) + +--- a/drivers/usb/gadget/function/f_uvc.c ++++ b/drivers/usb/gadget/function/f_uvc.c +@@ -890,13 +890,37 @@ static void uvc_function_unbind(struct u + { + struct usb_composite_dev *cdev = c->cdev; + struct uvc_device *uvc = to_uvc(f); ++ long wait_ret = 1; + + uvcg_info(f, "%s()\n", __func__); + ++ /* If we know we're connected via v4l2, then there should be a cleanup ++ * of the device from userspace either via UVC_EVENT_DISCONNECT or ++ * though the video device removal uevent. Allow some time for the ++ * application to close out before things get deleted. ++ */ ++ if (uvc->func_connected) { ++ uvcg_dbg(f, "waiting for clean disconnect\n"); ++ wait_ret = wait_event_interruptible_timeout(uvc->func_connected_queue, ++ uvc->func_connected == false, msecs_to_jiffies(500)); ++ uvcg_dbg(f, "done waiting with ret: %ld\n", wait_ret); ++ } ++ + device_remove_file(&uvc->vdev.dev, &dev_attr_function_name); + video_unregister_device(&uvc->vdev); + v4l2_device_unregister(&uvc->v4l2_dev); + ++ if (uvc->func_connected) { ++ /* Wait for the release to occur to ensure there are no longer any ++ * pending operations that may cause panics when resources are cleaned ++ * up. ++ */ ++ uvcg_warn(f, "%s no clean disconnect, wait for release\n", __func__); ++ wait_ret = wait_event_interruptible_timeout(uvc->func_connected_queue, ++ uvc->func_connected == false, msecs_to_jiffies(1000)); ++ uvcg_dbg(f, "done waiting for release with ret: %ld\n", wait_ret); ++ } ++ + usb_ep_free_request(cdev->gadget->ep0, uvc->control_req); + kfree(uvc->control_buf); + +@@ -915,6 +939,7 @@ static struct usb_function *uvc_alloc(st + + mutex_init(&uvc->video.mutex); + uvc->state = UVC_STATE_DISCONNECTED; ++ init_waitqueue_head(&uvc->func_connected_queue); + opts = fi_to_f_uvc_opts(fi); + + mutex_lock(&opts->lock); +--- a/drivers/usb/gadget/function/uvc.h ++++ b/drivers/usb/gadget/function/uvc.h +@@ -14,6 +14,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -129,6 +130,7 @@ struct uvc_device { + struct usb_function func; + struct uvc_video video; + bool func_connected; ++ wait_queue_head_t func_connected_queue; + + /* Descriptors */ + struct { +--- a/drivers/usb/gadget/function/uvc_v4l2.c ++++ b/drivers/usb/gadget/function/uvc_v4l2.c +@@ -253,10 +253,11 @@ uvc_v4l2_subscribe_event(struct v4l2_fh + + static void uvc_v4l2_disable(struct uvc_device *uvc) + { +- uvc->func_connected = false; + uvc_function_disconnect(uvc); + uvcg_video_enable(&uvc->video, 0); + uvcg_free_buffers(&uvc->video.queue); ++ uvc->func_connected = false; ++ wake_up_interruptible(&uvc->func_connected_queue); + } + + static int diff --git a/queue-5.17/usb-xhci-mtk-fix-fs-isoc-s-transfer-error.patch b/queue-5.17/usb-xhci-mtk-fix-fs-isoc-s-transfer-error.patch new file mode 100644 index 00000000000..cc7e7ebe88d --- /dev/null +++ b/queue-5.17/usb-xhci-mtk-fix-fs-isoc-s-transfer-error.patch @@ -0,0 +1,60 @@ +From c237566b78ad8c72bc0431c5d6171db8d12e6f94 Mon Sep 17 00:00:00 2001 +From: Chunfeng Yun +Date: Thu, 12 May 2022 14:49:30 +0800 +Subject: usb: xhci-mtk: fix fs isoc's transfer error + +From: Chunfeng Yun + +commit c237566b78ad8c72bc0431c5d6171db8d12e6f94 upstream. + +Due to the scheduler allocates the optimal bandwidth for FS ISOC endpoints, +this may be not enough actually and causes data transfer error, so come up +with an estimate that is no less than the worst case bandwidth used for +any one mframe, but may be an over-estimate. + +Fixes: 451d3912586a ("usb: xhci-mtk: update fs bus bandwidth by bw_budget_table") +Cc: stable@vger.kernel.org +Signed-off-by: Chunfeng Yun +Link: https://lore.kernel.org/r/20220512064931.31670-1-chunfeng.yun@mediatek.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-mtk-sch.c | 16 +++++++--------- + 1 file changed, 7 insertions(+), 9 deletions(-) + +--- a/drivers/usb/host/xhci-mtk-sch.c ++++ b/drivers/usb/host/xhci-mtk-sch.c +@@ -465,7 +465,7 @@ static int check_fs_bus_bw(struct mu3h_s + */ + for (j = 0; j < sch_ep->num_budget_microframes; j++) { + k = XHCI_MTK_BW_INDEX(base + j); +- tmp = tt->fs_bus_bw[k] + sch_ep->bw_budget_table[j]; ++ tmp = tt->fs_bus_bw[k] + sch_ep->bw_cost_per_microframe; + if (tmp > FS_PAYLOAD_MAX) + return -ESCH_BW_OVERFLOW; + } +@@ -539,19 +539,17 @@ static int check_sch_tt(struct mu3h_sch_ + static void update_sch_tt(struct mu3h_sch_ep_info *sch_ep, bool used) + { + struct mu3h_sch_tt *tt = sch_ep->sch_tt; ++ int bw_updated; + u32 base; +- int i, j, k; ++ int i, j; ++ ++ bw_updated = sch_ep->bw_cost_per_microframe * (used ? 1 : -1); + + for (i = 0; i < sch_ep->num_esit; i++) { + base = sch_ep->offset + i * sch_ep->esit; + +- for (j = 0; j < sch_ep->num_budget_microframes; j++) { +- k = XHCI_MTK_BW_INDEX(base + j); +- if (used) +- tt->fs_bus_bw[k] += sch_ep->bw_budget_table[j]; +- else +- tt->fs_bus_bw[k] -= sch_ep->bw_budget_table[j]; +- } ++ for (j = 0; j < sch_ep->num_budget_microframes; j++) ++ tt->fs_bus_bw[XHCI_MTK_BW_INDEX(base + j)] += bw_updated; + } + + if (used) diff --git a/queue-5.17/x86-mm-fix-marking-of-unused-sub-pmd-ranges.patch b/queue-5.17/x86-mm-fix-marking-of-unused-sub-pmd-ranges.patch new file mode 100644 index 00000000000..1abf50e9e35 --- /dev/null +++ b/queue-5.17/x86-mm-fix-marking-of-unused-sub-pmd-ranges.patch @@ -0,0 +1,48 @@ +From 280abe14b6e0a38de9cc86fe6a019523aadd8f70 Mon Sep 17 00:00:00 2001 +From: Adrian-Ken Rueegsegger +Date: Mon, 9 May 2022 11:06:37 +0200 +Subject: x86/mm: Fix marking of unused sub-pmd ranges + +From: Adrian-Ken Rueegsegger + +commit 280abe14b6e0a38de9cc86fe6a019523aadd8f70 upstream. + +The unused part precedes the new range spanned by the start, end parameters +of vmemmap_use_new_sub_pmd(). This means it actually goes from +ALIGN_DOWN(start, PMD_SIZE) up to start. + +Use the correct address when applying the mark using memset. + +Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges") +Signed-off-by: Adrian-Ken Rueegsegger +Signed-off-by: Thomas Gleixner +Reviewed-by: Oscar Salvador +Reviewed-by: David Hildenbrand +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220509090637.24152-2-ken@codelabs.ch +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/mm/init_64.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/arch/x86/mm/init_64.c ++++ b/arch/x86/mm/init_64.c +@@ -902,6 +902,8 @@ static void __meminit vmemmap_use_sub_pm + + static void __meminit vmemmap_use_new_sub_pmd(unsigned long start, unsigned long end) + { ++ const unsigned long page = ALIGN_DOWN(start, PMD_SIZE); ++ + vmemmap_flush_unused_pmd(); + + /* +@@ -914,8 +916,7 @@ static void __meminit vmemmap_use_new_su + * Mark with PAGE_UNUSED the unused parts of the new memmap range + */ + if (!IS_ALIGNED(start, PMD_SIZE)) +- memset((void *)start, PAGE_UNUSED, +- start - ALIGN_DOWN(start, PMD_SIZE)); ++ memset((void *)page, PAGE_UNUSED, start - page); + + /* + * We want to avoid memset(PAGE_UNUSED) when populating the vmemmap of