--- /dev/null
+From a472cc0dde3eb057db71c80f102556eeced03805 Mon Sep 17 00:00:00 2001
+From: Tang Bin <tangbin@cmss.chinamobile.com>
+Date: Thu, 21 Oct 2021 09:34:22 +0800
+Subject: crypto: s5p-sss - Add error handling in s5p_aes_probe()
+
+From: Tang Bin <tangbin@cmss.chinamobile.com>
+
+commit a472cc0dde3eb057db71c80f102556eeced03805 upstream.
+
+The function s5p_aes_probe() does not perform sufficient error
+checking after executing platform_get_resource(), thus fix it.
+
+Fixes: c2afad6c6105 ("crypto: s5p-sss - Add HASH support for Exynos")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/s5p-sss.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/crypto/s5p-sss.c
++++ b/drivers/crypto/s5p-sss.c
+@@ -2166,6 +2166,8 @@ static int s5p_aes_probe(struct platform
+
+ variant = find_s5p_sss_version(pdev);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
++ if (!res)
++ return -EINVAL;
+
+ /*
+ * Note: HASH and PRNG uses the same registers in secss, avoid
--- /dev/null
+From 2ac5fb35cd520ab1851c9a4816c523b65276052f Mon Sep 17 00:00:00 2001
+From: jing yangyang <cgel.zte@gmail.com>
+Date: Thu, 19 Aug 2021 19:30:16 -0700
+Subject: firmware/psci: fix application of sizeof to pointer
+
+From: jing yangyang <cgel.zte@gmail.com>
+
+commit 2ac5fb35cd520ab1851c9a4816c523b65276052f upstream.
+
+sizeof when applied to a pointer typed expression gives the size of
+the pointer.
+
+./drivers/firmware/psci/psci_checker.c:158:41-47: ERROR application of sizeof to pointer
+
+This issue was detected with the help of Coccinelle.
+
+Fixes: 7401056de5f8 ("drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests")
+Cc: stable@vger.kernel.org
+Reported-by: Zeal Robot <zealci@zte.com.cn>
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
+Signed-off-by: jing yangyang <jing.yangyang@zte.com.cn>
+Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/psci_checker.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/firmware/psci_checker.c
++++ b/drivers/firmware/psci_checker.c
+@@ -162,7 +162,7 @@ static int alloc_init_cpu_groups(cpumask
+ if (!alloc_cpumask_var(&tmp, GFP_KERNEL))
+ return -ENOMEM;
+
+- cpu_groups = kcalloc(nb_available_cpus, sizeof(cpu_groups),
++ cpu_groups = kcalloc(nb_available_cpus, sizeof(*cpu_groups),
+ GFP_KERNEL);
+ if (!cpu_groups) {
+ free_cpumask_var(tmp);
--- /dev/null
+From c73ba202a851c0b611ef2c25e568fadeff5e667f Mon Sep 17 00:00:00 2001
+From: Sean Young <sean@mess.org>
+Date: Wed, 15 Sep 2021 18:14:07 +0200
+Subject: media: ir-kbd-i2c: improve responsiveness of hauppauge zilog receivers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sean Young <sean@mess.org>
+
+commit c73ba202a851c0b611ef2c25e568fadeff5e667f upstream.
+
+The IR receiver has two issues:
+
+ - Sometimes there is no response to a button press
+ - Sometimes a button press is repeated when it should not have been
+
+Hanging the polling interval fixes this behaviour.
+
+Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994050
+
+Cc: stable@vger.kernel.org
+Suggested-by: Joaquín Alberto Calderón Pozo <kini_calderon@hotmail.com>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ir-kbd-i2c.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/i2c/ir-kbd-i2c.c
++++ b/drivers/media/i2c/ir-kbd-i2c.c
+@@ -801,6 +801,7 @@ static int ir_probe(struct i2c_client *c
+ rc_proto = RC_PROTO_BIT_RC5 | RC_PROTO_BIT_RC6_MCE |
+ RC_PROTO_BIT_RC6_6A_32;
+ ir_codes = RC_MAP_HAUPPAUGE;
++ ir->polling_interval = 125;
+ probe_tx = true;
+ break;
+ }
--- /dev/null
+From fdc881783099c6343921ff017450831c8766d12a Mon Sep 17 00:00:00 2001
+From: Sean Young <sean@mess.org>
+Date: Sun, 17 Oct 2021 13:01:15 +0100
+Subject: media: ite-cir: IR receiver stop working after receive overflow
+
+From: Sean Young <sean@mess.org>
+
+commit fdc881783099c6343921ff017450831c8766d12a upstream.
+
+On an Intel NUC6iSYK, no IR is reported after a receive overflow.
+
+When a receiver overflow occurs, this condition is only cleared by
+reading the fifo. Make sure we read anything in the fifo.
+
+Fixes: 28c7afb07ccf ("media: ite-cir: check for receive overflow")
+Suggested-by: Bryan Pass <bryan.pass@gmail.com>
+Tested-by: Bryan Pass <bryan.pass@gmail.com>
+Cc: stable@vger.kernel.org>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/rc/ite-cir.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/rc/ite-cir.c
++++ b/drivers/media/rc/ite-cir.c
+@@ -292,7 +292,7 @@ static irqreturn_t ite_cir_isr(int irq,
+ }
+
+ /* check for the receive interrupt */
+- if (iflags & ITE_IRQ_RX_FIFO) {
++ if (iflags & (ITE_IRQ_RX_FIFO | ITE_IRQ_RX_FIFO_OVERRUN)) {
+ /* read the FIFO bytes */
+ rx_bytes =
+ dev->params.get_rx_bytes(dev, rx_buf,
--- /dev/null
+From 43592c8736e84025d7a45e61a46c3fa40536a364 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20L=C3=B6hle?= <CLoehle@hyperstone.com>
+Date: Thu, 16 Sep 2021 05:59:19 +0000
+Subject: mmc: dw_mmc: Dont wait for DRTO on Write RSP error
+
+From: Christian Löhle <CLoehle@hyperstone.com>
+
+commit 43592c8736e84025d7a45e61a46c3fa40536a364 upstream.
+
+Only wait for DRTO on reads, otherwise the driver hangs.
+
+The driver prevents sending CMD12 on response errors like CRCs. According
+to the comment this is because some cards have problems with this during
+the UHS tuning sequence. Unfortunately this workaround currently also
+applies for any command with data. On reads this will set the drto timer,
+which then triggers after a while. On writes this will not set any timer
+and the tasklet will not be scheduled again.
+
+I cannot test for the UHS workarounds need, but even if so, it should at
+most apply to reads. I have observed many hangs when CMD25 response
+contained a CRC error. This patch fixes this without touching the actual
+UHS tuning workaround.
+
+Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
+Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/af8f8b8674ba4fcc9a781019e4aeb72c@hyperstone.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/dw_mmc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/dw_mmc.c
++++ b/drivers/mmc/host/dw_mmc.c
+@@ -2039,7 +2039,8 @@ static void dw_mci_tasklet_func(unsigned
+ * delayed. Allowing the transfer to take place
+ * avoids races and keeps things simple.
+ */
+- if (err != -ETIMEDOUT) {
++ if (err != -ETIMEDOUT &&
++ host->dir_status == DW_MCI_RECV_STATUS) {
+ state = STATE_SENDING_DATA;
+ continue;
+ }
--- /dev/null
+From 8779e05ba8aaffec1829872ef9774a71f44f6580 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Tue, 5 Oct 2021 00:27:49 +0200
+Subject: parisc: Fix ptrace check on syscall return
+
+From: Helge Deller <deller@gmx.de>
+
+commit 8779e05ba8aaffec1829872ef9774a71f44f6580 upstream.
+
+The TIF_XXX flags are stored in the flags field in the thread_info
+struct (TI_FLAGS), not in the flags field of the task_struct structure
+(TASK_FLAGS).
+
+It seems this bug didn't generate any important side-effects, otherwise it
+wouldn't have went unnoticed for 12 years (since v2.6.32).
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Fixes: ecd3d4bc06e48 ("parisc: stop using task->ptrace for {single,block}step flags")
+Cc: Kyle McMartin <kyle@mcmartin.ca>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/entry.S | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/parisc/kernel/entry.S
++++ b/arch/parisc/kernel/entry.S
+@@ -1851,7 +1851,7 @@ syscall_restore:
+ LDREG TI_TASK-THREAD_SZ_ALGN-FRAME_SIZE(%r30),%r1
+
+ /* Are we being ptraced? */
+- ldw TASK_FLAGS(%r1),%r19
++ LDREG TI_FLAGS-THREAD_SZ_ALGN-FRAME_SIZE(%r30),%r19
+ ldi _TIF_SYSCALL_TRACE_MASK,%r2
+ and,COND(=) %r19,%r2,%r0
+ b,n syscall_restore_rfi
input-i8042-add-quirk-for-fujitsu-lifebook-t725.patch
libata-fix-read-log-timeout-value.patch
ocfs2-fix-data-corruption-on-truncate.patch
+mmc-dw_mmc-dont-wait-for-drto-on-write-rsp-error.patch
+parisc-fix-ptrace-check-on-syscall-return.patch
+tpm-check-for-integer-overflow-in-tpm2_map_response_body.patch
+firmware-psci-fix-application-of-sizeof-to-pointer.patch
+crypto-s5p-sss-add-error-handling-in-s5p_aes_probe.patch
+media-ite-cir-ir-receiver-stop-working-after-receive-overflow.patch
+media-ir-kbd-i2c-improve-responsiveness-of-hauppauge-zilog-receivers.patch
--- /dev/null
+From a0bcce2b2a169e10eb265c8f0ebdd5ae4c875670 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Wed, 8 Sep 2021 08:33:57 +0300
+Subject: tpm: Check for integer overflow in tpm2_map_response_body()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit a0bcce2b2a169e10eb265c8f0ebdd5ae4c875670 upstream.
+
+The "4 * be32_to_cpu(data->count)" multiplication can potentially
+overflow which would lead to memory corruption. Add a check for that.
+
+Cc: stable@vger.kernel.org
+Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/tpm/tpm2-space.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/char/tpm/tpm2-space.c
++++ b/drivers/char/tpm/tpm2-space.c
+@@ -419,6 +419,9 @@ static int tpm2_map_response_body(struct
+ if (be32_to_cpu(data->capability) != TPM2_CAP_HANDLES)
+ return 0;
+
++ if (be32_to_cpu(data->count) > (UINT_MAX - TPM_HEADER_SIZE - 9) / 4)
++ return -EFAULT;
++
+ if (len != TPM_HEADER_SIZE + 9 + 4 * be32_to_cpu(data->count))
+ return -EFAULT;
+