--- /dev/null
+From f867c771f98891841c217fa8459244ed0dd28921 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Date: Fri, 17 Jul 2020 00:12:15 +0900
+Subject: binder: Don't use mmput() from shrinker function.
+
+From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+
+commit f867c771f98891841c217fa8459244ed0dd28921 upstream.
+
+syzbot is reporting that mmput() from shrinker function has a risk of
+deadlock [1], for delayed_uprobe_add() from update_ref_ctr() calls
+kzalloc(GFP_KERNEL) with delayed_uprobe_lock held, and
+uprobe_clear_state() from __mmput() also holds delayed_uprobe_lock.
+
+Commit a1b2289cef92ef0e ("android: binder: drop lru lock in isolate
+callback") replaced mmput() with mmput_async() in order to avoid sleeping
+with spinlock held. But this patch replaces mmput() with mmput_async() in
+order not to start __mmput() from shrinker context.
+
+[1] https://syzkaller.appspot.com/bug?id=bc9e7303f537c41b2b0cc2dfcea3fc42964c2d45
+
+Reported-by: syzbot <syzbot+1068f09c44d151250c33@syzkaller.appspotmail.com>
+Reported-by: syzbot <syzbot+e5344baa319c9a96edec@syzkaller.appspotmail.com>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Reviewed-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Todd Kjos <tkjos@google.com>
+Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/4ba9adb2-43f5-2de0-22de-f6075c1fab50@i-love.sakura.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/android/binder_alloc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/android/binder_alloc.c
++++ b/drivers/android/binder_alloc.c
+@@ -948,7 +948,7 @@ enum lru_status binder_alloc_free_page(s
+ trace_binder_unmap_user_end(alloc, index);
+ }
+ up_read(&mm->mmap_sem);
+- mmput(mm);
++ mmput_async(mm);
+
+ trace_binder_unmap_kernel_start(alloc, index);
+
--- /dev/null
+From b34e7e298d7a5ed76b3aa327c240c29f1ef6dd22 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Wed, 15 Jul 2020 23:05:53 -0700
+Subject: /dev/mem: Add missing memory barriers for devmem_inode
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit b34e7e298d7a5ed76b3aa327c240c29f1ef6dd22 upstream.
+
+WRITE_ONCE() isn't the correct way to publish a pointer to a data
+structure, since it doesn't include a write memory barrier. Therefore
+other tasks may see that the pointer has been set but not see that the
+pointed-to memory has finished being initialized yet. Instead a
+primitive with "release" semantics is needed.
+
+Use smp_store_release() for this.
+
+The use of READ_ONCE() on the read side is still potentially correct if
+there's no control dependency, i.e. if all memory being "published" is
+transitively reachable via the pointer itself. But this pairing is
+somewhat confusing and error-prone. So just upgrade the read side to
+smp_load_acquire() so that it clearly pairs with smp_store_release().
+
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Russell King <linux@arm.linux.org.uk>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Fixes: 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Dan Williams <dan.j.williams@intel.com>
+Link: https://lore.kernel.org/r/20200716060553.24618-1-ebiggers@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/mem.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/char/mem.c
++++ b/drivers/char/mem.c
+@@ -814,7 +814,8 @@ static struct inode *devmem_inode;
+ #ifdef CONFIG_IO_STRICT_DEVMEM
+ void revoke_devmem(struct resource *res)
+ {
+- struct inode *inode = READ_ONCE(devmem_inode);
++ /* pairs with smp_store_release() in devmem_init_inode() */
++ struct inode *inode = smp_load_acquire(&devmem_inode);
+
+ /*
+ * Check that the initialization has completed. Losing the race
+@@ -1028,8 +1029,11 @@ static int devmem_init_inode(void)
+ return rc;
+ }
+
+- /* publish /dev/mem initialized */
+- WRITE_ONCE(devmem_inode, inode);
++ /*
++ * Publish /dev/mem initialized.
++ * Pairs with smp_load_acquire() in revoke_devmem().
++ */
++ smp_store_release(&devmem_inode, inode);
+
+ return 0;
+ }
--- /dev/null
+From 033724d6864245a11f8e04c066002e6ad22b3fd0 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Wed, 15 Jul 2020 10:51:02 +0900
+Subject: fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit 033724d6864245a11f8e04c066002e6ad22b3fd0 upstream.
+
+syzbot is reporting general protection fault in bitfill_aligned() [1]
+caused by integer underflow in bit_clear_margins(). The cause of this
+problem is when and how do_vc_resize() updates vc->vc_{cols,rows}.
+
+If vc_do_resize() fails (e.g. kzalloc() fails) when var.xres or var.yres
+is going to shrink, vc->vc_{cols,rows} will not be updated. This allows
+bit_clear_margins() to see info->var.xres < (vc->vc_cols * cw) or
+info->var.yres < (vc->vc_rows * ch). Unexpectedly large rw or bh will
+try to overrun the __iomem region and causes general protection fault.
+
+Also, vc_resize(vc, 0, 0) does not set vc->vc_{cols,rows} = 0 due to
+
+ new_cols = (cols ? cols : vc->vc_cols);
+ new_rows = (lines ? lines : vc->vc_rows);
+
+exception. Since cols and lines are calculated as
+
+ cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres);
+ rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
+ cols /= vc->vc_font.width;
+ rows /= vc->vc_font.height;
+ vc_resize(vc, cols, rows);
+
+in fbcon_modechanged(), var.xres < vc->vc_font.width makes cols = 0
+and var.yres < vc->vc_font.height makes rows = 0. This means that
+
+ const int fd = open("/dev/fb0", O_ACCMODE);
+ struct fb_var_screeninfo var = { };
+ ioctl(fd, FBIOGET_VSCREENINFO, &var);
+ var.xres = var.yres = 1;
+ ioctl(fd, FBIOPUT_VSCREENINFO, &var);
+
+easily reproduces integer underflow bug explained above.
+
+Of course, callers of vc_resize() are not handling vc_do_resize() failure
+is bad. But we can't avoid vc_resize(vc, 0, 0) which returns 0. Therefore,
+as a band-aid workaround, this patch checks integer underflow in
+"struct fbcon_ops"->clear_margins call, assuming that
+vc->vc_cols * vc->vc_font.width and vc->vc_rows * vc->vc_font.heigh do not
+cause integer overflow.
+
+[1] https://syzkaller.appspot.com/bug?id=a565882df74fa76f10d3a6fec4be31098dbb37c6
+
+Reported-and-tested-by: syzbot <syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200715015102.3814-1-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/core/bitblit.c | 4 ++--
+ drivers/video/fbdev/core/fbcon_ccw.c | 4 ++--
+ drivers/video/fbdev/core/fbcon_cw.c | 4 ++--
+ drivers/video/fbdev/core/fbcon_ud.c | 4 ++--
+ 4 files changed, 8 insertions(+), 8 deletions(-)
+
+--- a/drivers/video/fbdev/core/bitblit.c
++++ b/drivers/video/fbdev/core/bitblit.c
+@@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_
+ region.color = color;
+ region.rop = ROP_COPY;
+
+- if (rw && !bottom_only) {
++ if ((int) rw > 0 && !bottom_only) {
+ region.dx = info->var.xoffset + rs;
+ region.dy = 0;
+ region.width = rw;
+@@ -224,7 +224,7 @@ static void bit_clear_margins(struct vc_
+ info->fbops->fb_fillrect(info, ®ion);
+ }
+
+- if (bh) {
++ if ((int) bh > 0) {
+ region.dx = info->var.xoffset;
+ region.dy = info->var.yoffset + bs;
+ region.width = rs;
+--- a/drivers/video/fbdev/core/fbcon_ccw.c
++++ b/drivers/video/fbdev/core/fbcon_ccw.c
+@@ -201,7 +201,7 @@ static void ccw_clear_margins(struct vc_
+ region.color = color;
+ region.rop = ROP_COPY;
+
+- if (rw && !bottom_only) {
++ if ((int) rw > 0 && !bottom_only) {
+ region.dx = 0;
+ region.dy = info->var.yoffset;
+ region.height = rw;
+@@ -209,7 +209,7 @@ static void ccw_clear_margins(struct vc_
+ info->fbops->fb_fillrect(info, ®ion);
+ }
+
+- if (bh) {
++ if ((int) bh > 0) {
+ region.dx = info->var.xoffset + bs;
+ region.dy = 0;
+ region.height = info->var.yres_virtual;
+--- a/drivers/video/fbdev/core/fbcon_cw.c
++++ b/drivers/video/fbdev/core/fbcon_cw.c
+@@ -184,7 +184,7 @@ static void cw_clear_margins(struct vc_d
+ region.color = color;
+ region.rop = ROP_COPY;
+
+- if (rw && !bottom_only) {
++ if ((int) rw > 0 && !bottom_only) {
+ region.dx = 0;
+ region.dy = info->var.yoffset + rs;
+ region.height = rw;
+@@ -192,7 +192,7 @@ static void cw_clear_margins(struct vc_d
+ info->fbops->fb_fillrect(info, ®ion);
+ }
+
+- if (bh) {
++ if ((int) bh > 0) {
+ region.dx = info->var.xoffset;
+ region.dy = info->var.yoffset;
+ region.height = info->var.yres;
+--- a/drivers/video/fbdev/core/fbcon_ud.c
++++ b/drivers/video/fbdev/core/fbcon_ud.c
+@@ -231,7 +231,7 @@ static void ud_clear_margins(struct vc_d
+ region.color = color;
+ region.rop = ROP_COPY;
+
+- if (rw && !bottom_only) {
++ if ((int) rw > 0 && !bottom_only) {
+ region.dy = 0;
+ region.dx = info->var.xoffset;
+ region.width = rw;
+@@ -239,7 +239,7 @@ static void ud_clear_margins(struct vc_d
+ info->fbops->fb_fillrect(info, ®ion);
+ }
+
+- if (bh) {
++ if ((int) bh > 0) {
+ region.dy = info->var.yoffset;
+ region.dx = info->var.xoffset;
+ region.height = bh;
--- /dev/null
+From fbb1461ad1d6eacca9beb69a2f3ce1b5398d399b Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Fri, 3 Apr 2020 11:29:55 +0300
+Subject: iwlwifi: mvm: don't call iwl_mvm_free_inactive_queue() under RCU
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit fbb1461ad1d6eacca9beb69a2f3ce1b5398d399b upstream.
+
+iwl_mvm_free_inactive_queue() will sleep in synchronize_net() under
+some circumstances, so don't call it under RCU. There doesn't appear
+to be a need for RCU protection around this particular call.
+
+Cc: stable@vger.kernel.org # v5.4+
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/iwlwifi.20200403112332.0f49448c133d.I17fd308bc4a9491859c9b112f4eb5d2c3fc18d7d@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+@@ -1184,17 +1184,15 @@ static int iwl_mvm_inactivity_check(stru
+ for_each_set_bit(i, &changetid_queues, IWL_MAX_HW_QUEUES)
+ iwl_mvm_change_queue_tid(mvm, i);
+
++ rcu_read_unlock();
++
+ if (free_queue >= 0 && alloc_for_sta != IWL_MVM_INVALID_STA) {
+ ret = iwl_mvm_free_inactive_queue(mvm, free_queue, queue_owner,
+ alloc_for_sta);
+- if (ret) {
+- rcu_read_unlock();
++ if (ret)
+ return ret;
+- }
+ }
+
+- rcu_read_unlock();
+-
+ return free_queue;
+ }
+
--- /dev/null
+From ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51 Mon Sep 17 00:00:00 2001
+From: Fangrui Song <maskray@google.com>
+Date: Tue, 21 Jul 2020 10:31:23 -0700
+Subject: Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation
+
+From: Fangrui Song <maskray@google.com>
+
+commit ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51 upstream.
+
+When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
+$(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit,
+GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to
+/usr/bin/ and Clang as of 11 will search for both
+$(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle.
+
+GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle,
+$(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice,
+$(prefix)aarch64-linux-gnu/$needle rarely contains executables.
+
+To better model how GCC's -B/--prefix takes in effect in practice, newer
+Clang (since
+https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90)
+only searches for $(prefix)$needle. Currently it will find /usr/bin/as
+instead of /usr/bin/aarch64-linux-gnu-as.
+
+Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
+(/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the
+appropriate cross compiling GNU as (when -no-integrated-as is in
+effect).
+
+Cc: stable@vger.kernel.org
+Reported-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Fangrui Song <maskray@google.com>
+Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
+Tested-by: Nathan Chancellor <natechancellor@gmail.com>
+Tested-by: Nick Desaulniers <ndesaulniers@google.com>
+Link: https://github.com/ClangBuiltLinux/linux/issues/1099
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Makefile
++++ b/Makefile
+@@ -528,7 +528,7 @@ ifneq ($(shell $(CC) --version 2>&1 | he
+ ifneq ($(CROSS_COMPILE),)
+ CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
+ GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
+-CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)
++CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
+ GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
+ endif
+ ifneq ($(GCC_TOOLCHAIN),)
--- /dev/null
+From 0e6705182d4e1b77248a93470d6d7b3013d59b30 Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Thu, 23 Jul 2020 14:41:29 -0500
+Subject: Revert "cifs: Fix the target file was deleted when rename failed."
+
+From: Steve French <stfrench@microsoft.com>
+
+commit 0e6705182d4e1b77248a93470d6d7b3013d59b30 upstream.
+
+This reverts commit 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2.
+
+Upon additional testing with older servers, it was found that
+the original commit introduced a regression when using the old SMB1
+dialect and rsyncing over an existing file.
+
+The patch will need to be respun to address this, likely including
+a larger refactoring of the SMB1 and SMB3 rename code paths to make
+it less confusing and also to address some additional rename error
+cases that SMB3 may be able to workaround.
+
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reported-by: Patrick Fernie <patrick.fernie@gmail.com>
+CC: Stable <stable@vger.kernel.org>
+Acked-by: Ronnie Sahlberg <lsahlber@redhat.com>
+Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
+Acked-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/inode.c | 10 ++--------
+ 1 file changed, 2 insertions(+), 8 deletions(-)
+
+--- a/fs/cifs/inode.c
++++ b/fs/cifs/inode.c
+@@ -1791,7 +1791,6 @@ cifs_rename2(struct inode *source_dir, s
+ FILE_UNIX_BASIC_INFO *info_buf_target;
+ unsigned int xid;
+ int rc, tmprc;
+- bool new_target = d_really_is_negative(target_dentry);
+
+ if (flags & ~RENAME_NOREPLACE)
+ return -EINVAL;
+@@ -1868,13 +1867,8 @@ cifs_rename2(struct inode *source_dir, s
+ */
+
+ unlink_target:
+- /*
+- * If the target dentry was created during the rename, try
+- * unlinking it if it's not negative
+- */
+- if (new_target &&
+- d_really_is_positive(target_dentry) &&
+- (rc == -EACCES || rc == -EEXIST)) {
++ /* Try unlinking the target dentry if it's not negative */
++ if (d_really_is_positive(target_dentry) && (rc == -EACCES || rc == -EEXIST)) {
+ if (d_is_dir(target_dentry))
+ tmprc = cifs_rmdir(target_dir, target_dentry);
+ else
--- /dev/null
+From f4c23a140d80ef5e6d3d1f8f57007649014b60fa Mon Sep 17 00:00:00 2001
+From: Yang Yingliang <yangyingliang@huawei.com>
+Date: Tue, 21 Jul 2020 14:38:52 +0000
+Subject: serial: 8250: fix null-ptr-deref in serial8250_start_tx()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+commit f4c23a140d80ef5e6d3d1f8f57007649014b60fa upstream.
+
+I got null-ptr-deref in serial8250_start_tx():
+
+[ 78.114630] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
+[ 78.123778] Mem abort info:
+[ 78.126560] ESR = 0x86000007
+[ 78.129603] EC = 0x21: IABT (current EL), IL = 32 bits
+[ 78.134891] SET = 0, FnV = 0
+[ 78.137933] EA = 0, S1PTW = 0
+[ 78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=00000027d41a8600
+[ 78.147562] [0000000000000000] pgd=00000027893f0003, p4d=00000027893f0003, pud=00000027893f0003, pmd=00000027c9a20003, pte=0000000000000000
+[ 78.160029] Internal error: Oops: 86000007 [#1] SMP
+[ 78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd
+[ 78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48
+[ 78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020
+[ 78.222888] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
+[ 78.228435] pc : 0x0
+[ 78.230618] lr : serial8250_start_tx+0x160/0x260
+[ 78.235215] sp : ffff800062eefb80
+[ 78.238517] x29: ffff800062eefb80 x28: 0000000000000fff
+[ 78.243807] x27: ffff800062eefd80 x26: ffff202fd83b3000
+[ 78.249098] x25: ffff800062eefd80 x24: ffff202fd83b3000
+[ 78.254388] x23: ffff002fc5e50be8 x22: 0000000000000002
+[ 78.259679] x21: 0000000000000001 x20: 0000000000000000
+[ 78.264969] x19: ffffa688827eecc8 x18: 0000000000000000
+[ 78.270259] x17: 0000000000000000 x16: 0000000000000000
+[ 78.275550] x15: ffffa68881bc67a8 x14: 00000000000002e6
+[ 78.280841] x13: ffffa68881bc67a8 x12: 000000000000c539
+[ 78.286131] x11: d37a6f4de9bd37a7 x10: ffffa68881cccff0
+[ 78.291421] x9 : ffffa68881bc6000 x8 : ffffa688819daa88
+[ 78.296711] x7 : ffffa688822a0f20 x6 : ffffa688819e0000
+[ 78.302002] x5 : ffff800062eef9d0 x4 : ffffa68881e707a8
+[ 78.307292] x3 : 0000000000000000 x2 : 0000000000000002
+[ 78.312582] x1 : 0000000000000001 x0 : ffffa688827eecc8
+[ 78.317873] Call trace:
+[ 78.320312] 0x0
+[ 78.322147] __uart_start.isra.9+0x64/0x78
+[ 78.326229] uart_start+0xb8/0x1c8
+[ 78.329620] uart_flush_chars+0x24/0x30
+[ 78.333442] n_tty_receive_buf_common+0x7b0/0xc30
+[ 78.338128] n_tty_receive_buf+0x44/0x2c8
+[ 78.342122] tty_ioctl+0x348/0x11f8
+[ 78.345599] ksys_ioctl+0xd8/0xf8
+[ 78.348903] __arm64_sys_ioctl+0x2c/0xc8
+[ 78.352812] el0_svc_common.constprop.2+0x88/0x1b0
+[ 78.357583] do_el0_svc+0x44/0xd0
+[ 78.360887] el0_sync_handler+0x14c/0x1d0
+[ 78.364880] el0_sync+0x140/0x180
+[ 78.368185] Code: bad PC value
+
+SERIAL_PORT_DFNS is not defined on each arch, if it's not defined,
+serial8250_set_defaults() won't be called in serial8250_isa_init_ports(),
+so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref.
+Fix this problem by calling serial8250_set_defaults() after init uart port.
+
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/8250/8250_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/8250/8250_core.c
++++ b/drivers/tty/serial/8250/8250_core.c
+@@ -524,6 +524,7 @@ static void __init serial8250_isa_init_p
+ */
+ up->mcr_mask = ~ALPHA_KLUDGE_MCR;
+ up->mcr_force = ALPHA_KLUDGE_MCR;
++ serial8250_set_defaults(up);
+ }
+
+ /* chain base port ops to support Remote Supervisor Adapter */
+@@ -547,7 +548,6 @@ static void __init serial8250_isa_init_p
+ port->membase = old_serial_port[i].iomem_base;
+ port->iotype = old_serial_port[i].io_type;
+ port->regshift = old_serial_port[i].iomem_reg_shift;
+- serial8250_set_defaults(up);
+
+ port->irqflags |= irqflag;
+ if (serial8250_isa_config != NULL)
--- /dev/null
+From 551e553f0d4ab623e2a6f424ab5834f9c7b5229c Mon Sep 17 00:00:00 2001
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Date: Tue, 14 Jul 2020 15:41:12 +0300
+Subject: serial: 8250_mtk: Fix high-speed baud rates clamping
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+commit 551e553f0d4ab623e2a6f424ab5834f9c7b5229c upstream.
+
+Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250
+port") fixed limits of a baud rate setting for a generic 8250 port.
+In other words since that commit the baud rate has been permitted to be
+within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely
+normal for a standard 8250 UART port. But there are custom 8250 ports,
+which provide extended baud rate limits. In particular the Mediatek 8250
+port can work with baud rates up to "uartclk" speed.
+
+Normally that and any other peculiarity is supposed to be handled in a
+custom set_termios() callback implemented in the vendor-specific
+8250-port glue-driver. Currently that is how it's done for the most of
+the vendor-specific 8250 ports, but for some reason for Mediatek a
+solution has been spread out to both the glue-driver and to the generic
+8250-port code. Due to that a bug has been introduced, which permitted the
+extended baud rate limit for all even for standard 8250-ports. The bug
+has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud
+limit in generic 8250 port") by narrowing the baud rates limit back down to
+the normal bounds. Unfortunately by doing so we also broke the
+Mediatek-specific extended bauds feature.
+
+A fix of the problem described above is twofold. First since we can't get
+back the extended baud rate limits feature to the generic set_termios()
+function and that method supports only a standard baud rates range, the
+requested baud rate must be locally stored before calling it and then
+restored back to the new termios structure after the generic set_termios()
+finished its magic business. By doing so we still use the
+serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers,
+while the extended baud rate setting procedure will be performed later in
+the custom Mediatek-specific set_termios() callback. Second since a true
+baud rate is now fully calculated in the custom set_termios() method we
+need to locally update the port timeout by calling the
+uart_update_timeout() function. After the fixes described above are
+implemented in the 8250_mtk.c driver, the Mediatek 8250-port should
+get back to normally working with extended baud rates.
+
+Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com
+
+Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port")
+Reported-by: Daniel Winkler <danielwinkler@google.com>
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Cc: stable <stable@vger.kernel.org>
+Tested-by: Claire Chang <tientzu@chromium.org>
+Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ru
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/8250/8250_mtk.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/drivers/tty/serial/8250/8250_mtk.c
++++ b/drivers/tty/serial/8250/8250_mtk.c
+@@ -305,8 +305,21 @@ mtk8250_set_termios(struct uart_port *po
+ }
+ #endif
+
++ /*
++ * Store the requested baud rate before calling the generic 8250
++ * set_termios method. Standard 8250 port expects bauds to be
++ * no higher than (uartclk / 16) so the baud will be clamped if it
++ * gets out of that bound. Mediatek 8250 port supports speed
++ * higher than that, therefore we'll get original baud rate back
++ * after calling the generic set_termios method and recalculate
++ * the speed later in this method.
++ */
++ baud = tty_termios_baud_rate(termios);
++
+ serial8250_do_set_termios(port, termios, old);
+
++ tty_termios_encode_baud_rate(termios, baud, baud);
++
+ /*
+ * Mediatek UARTs use an extra highspeed register (MTK_UART_HIGHS)
+ *
+@@ -338,6 +351,11 @@ mtk8250_set_termios(struct uart_port *po
+ */
+ spin_lock_irqsave(&port->lock, flags);
+
++ /*
++ * Update the per-port timeout.
++ */
++ uart_update_timeout(port, termios->c_cflag, baud);
++
+ /* set DLAB we have cval saved in up->lcr from the call to the core */
+ serial_port_out(port, UART_LCR, up->lcr | UART_LCR_DLAB);
+ serial_dl_write(up, quot);
--- /dev/null
+From b374c562ee7ab3f3a1daf959c01868bae761571c Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 10 Jul 2020 15:59:46 +0200
+Subject: serial: tegra: fix CREAD handling for PIO
+
+From: Johan Hovold <johan@kernel.org>
+
+commit b374c562ee7ab3f3a1daf959c01868bae761571c upstream.
+
+Commit 33ae787b74fc ("serial: tegra: add support to ignore read") added
+support for dropping input in case CREAD isn't set, but for PIO the
+ignore_status_mask wasn't checked until after the character had been
+put in the receive buffer.
+
+Note that the NULL tty-port test is bogus and will be removed by a
+follow-on patch.
+
+Fixes: 33ae787b74fc ("serial: tegra: add support to ignore read")
+Cc: stable <stable@vger.kernel.org> # 5.4
+Cc: Shardar Shariff Md <smohammed@nvidia.com>
+Cc: Krishna Yarlagadda <kyarlagadda@nvidia.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Thierry Reding <treding@nvidia.com>
+Link: https://lore.kernel.org/r/20200710135947.2737-2-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/serial-tegra.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/serial-tegra.c
++++ b/drivers/tty/serial/serial-tegra.c
+@@ -651,11 +651,14 @@ static void tegra_uart_handle_rx_pio(str
+ ch = (unsigned char) tegra_uart_read(tup, UART_RX);
+ tup->uport.icount.rx++;
+
+- if (!uart_handle_sysrq_char(&tup->uport, ch) && tty)
+- tty_insert_flip_char(tty, ch, flag);
++ if (uart_handle_sysrq_char(&tup->uport, ch))
++ continue;
+
+ if (tup->uport.ignore_status_mask & UART_LSR_DR)
+ continue;
++
++ if (tty)
++ tty_insert_flip_char(tty, ch, flag);
+ } while (1);
+ }
+
asm-generic-mmiowb-allow-mmiowb_set_pending-when-pre.patch
drivers-perf-prevent-forced-unbinding-of-pmu-drivers.patch
risc-v-upgrade-smp_mb__after_spinlock-to-iorw-iorw.patch
+binder-don-t-use-mmput-from-shrinker-function.patch
+usb-xhci-mtk-fix-the-failure-of-bandwidth-allocation.patch
+usb-xhci-fix-asm2142-asm3142-dma-addressing.patch
+revert-cifs-fix-the-target-file-was-deleted-when-rename-failed.patch
+iwlwifi-mvm-don-t-call-iwl_mvm_free_inactive_queue-under-rcu.patch
+tty-xilinx_uartps-really-fix-id-assignment.patch
+staging-wlan-ng-properly-check-endpoint-types.patch
+staging-comedi-addi_apci_1032-check-insn_config_digital_trig-shift.patch
+staging-comedi-ni_6527-fix-insn_config_digital_trig-support.patch
+staging-comedi-addi_apci_1500-check-insn_config_digital_trig-shift.patch
+staging-comedi-addi_apci_1564-check-insn_config_digital_trig-shift.patch
+serial-tegra-fix-cread-handling-for-pio.patch
+serial-8250-fix-null-ptr-deref-in-serial8250_start_tx.patch
+serial-8250_mtk-fix-high-speed-baud-rates-clamping.patch
+dev-mem-add-missing-memory-barriers-for-devmem_inode.patch
+fbdev-detect-integer-underflow-at-struct-fbcon_ops-clear_margins.patch
+vt-reject-zero-sized-screen-buffer-size.patch
+makefile-fix-gcc_toolchain_dir-prefix-for-clang-cross-compilation.patch
--- /dev/null
+From 0bd0db42a030b75c20028c7ba6e327b9cb554116 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Fri, 17 Jul 2020 15:52:55 +0100
+Subject: staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 0bd0db42a030b75c20028c7ba6e327b9cb554116 upstream.
+
+The `INSN_CONFIG` comedi instruction with sub-instruction code
+`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
+used as a right shift amount for other bitmask values without being
+checked. Shift amounts greater than or equal to 32 will result in
+undefined behavior. Add code to deal with this.
+
+Fixes: 33cdce6293dcc ("staging: comedi: addi_apci_1032: conform to new INSN_CONFIG_DIGITAL_TRIG")
+Cc: <stable@vger.kernel.org> #3.8+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20200717145257.112660-3-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/addi_apci_1032.c | 20 ++++++++++++++------
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/addi_apci_1032.c
++++ b/drivers/staging/comedi/drivers/addi_apci_1032.c
+@@ -106,14 +106,22 @@ static int apci1032_cos_insn_config(stru
+ unsigned int *data)
+ {
+ struct apci1032_private *devpriv = dev->private;
+- unsigned int shift, oldmask;
++ unsigned int shift, oldmask, himask, lomask;
+
+ switch (data[0]) {
+ case INSN_CONFIG_DIGITAL_TRIG:
+ if (data[1] != 0)
+ return -EINVAL;
+ shift = data[3];
+- oldmask = (1U << shift) - 1;
++ if (shift < 32) {
++ oldmask = (1U << shift) - 1;
++ himask = data[4] << shift;
++ lomask = data[5] << shift;
++ } else {
++ oldmask = 0xffffffffu;
++ himask = 0;
++ lomask = 0;
++ }
+ switch (data[2]) {
+ case COMEDI_DIGITAL_TRIG_DISABLE:
+ devpriv->ctrl = 0;
+@@ -136,8 +144,8 @@ static int apci1032_cos_insn_config(stru
+ devpriv->mode2 &= oldmask;
+ }
+ /* configure specified channels */
+- devpriv->mode1 |= data[4] << shift;
+- devpriv->mode2 |= data[5] << shift;
++ devpriv->mode1 |= himask;
++ devpriv->mode2 |= lomask;
+ break;
+ case COMEDI_DIGITAL_TRIG_ENABLE_LEVELS:
+ if (devpriv->ctrl != (APCI1032_CTRL_INT_ENA |
+@@ -154,8 +162,8 @@ static int apci1032_cos_insn_config(stru
+ devpriv->mode2 &= oldmask;
+ }
+ /* configure specified channels */
+- devpriv->mode1 |= data[4] << shift;
+- devpriv->mode2 |= data[5] << shift;
++ devpriv->mode1 |= himask;
++ devpriv->mode2 |= lomask;
+ break;
+ default:
+ return -EINVAL;
--- /dev/null
+From fc846e9db67c7e808d77bf9e2ef3d49e3820ce5d Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Fri, 17 Jul 2020 15:52:57 +0100
+Subject: staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit fc846e9db67c7e808d77bf9e2ef3d49e3820ce5d upstream.
+
+The `INSN_CONFIG` comedi instruction with sub-instruction code
+`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
+used as a right shift amount for other bitmask values without being
+checked. Shift amounts greater than or equal to 32 will result in
+undefined behavior. Add code to deal with this, adjusting the checks
+for invalid channels so that enabled channel bits that would have been
+lost by shifting are also checked for validity. Only channels 0 to 15
+are valid.
+
+Fixes: a8c66b684efaf ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions")
+Cc: <stable@vger.kernel.org> #4.0+: ef75e14a6c93: staging: comedi: verify array index is correct before using it
+Cc: <stable@vger.kernel.org> #4.0+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20200717145257.112660-5-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/addi_apci_1500.c | 24 +++++++++++++++++++-----
+ 1 file changed, 19 insertions(+), 5 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/addi_apci_1500.c
++++ b/drivers/staging/comedi/drivers/addi_apci_1500.c
+@@ -452,13 +452,14 @@ static int apci1500_di_cfg_trig(struct c
+ struct apci1500_private *devpriv = dev->private;
+ unsigned int trig = data[1];
+ unsigned int shift = data[3];
+- unsigned int hi_mask = data[4] << shift;
+- unsigned int lo_mask = data[5] << shift;
+- unsigned int chan_mask = hi_mask | lo_mask;
+- unsigned int old_mask = (1 << shift) - 1;
++ unsigned int hi_mask;
++ unsigned int lo_mask;
++ unsigned int chan_mask;
++ unsigned int old_mask;
+ unsigned int pm;
+ unsigned int pt;
+ unsigned int pp;
++ unsigned int invalid_chan;
+
+ if (trig > 1) {
+ dev_dbg(dev->class_dev,
+@@ -466,7 +467,20 @@ static int apci1500_di_cfg_trig(struct c
+ return -EINVAL;
+ }
+
+- if (chan_mask > 0xffff) {
++ if (shift <= 16) {
++ hi_mask = data[4] << shift;
++ lo_mask = data[5] << shift;
++ old_mask = (1U << shift) - 1;
++ invalid_chan = (data[4] | data[5]) >> (16 - shift);
++ } else {
++ hi_mask = 0;
++ lo_mask = 0;
++ old_mask = 0xffff;
++ invalid_chan = data[4] | data[5];
++ }
++ chan_mask = hi_mask | lo_mask;
++
++ if (invalid_chan) {
+ dev_dbg(dev->class_dev, "invalid digital trigger channel\n");
+ return -EINVAL;
+ }
--- /dev/null
+From 926234f1b8434c4409aa4c53637aa3362ca07cea Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Fri, 17 Jul 2020 15:52:56 +0100
+Subject: staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 926234f1b8434c4409aa4c53637aa3362ca07cea upstream.
+
+The `INSN_CONFIG` comedi instruction with sub-instruction code
+`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
+used as a right shift amount for other bitmask values without being
+checked. Shift amounts greater than or equal to 32 will result in
+undefined behavior. Add code to deal with this.
+
+Fixes: 1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State interrupt subdevice and required functions")
+Cc: <stable@vger.kernel.org> #3.17+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20200717145257.112660-4-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/addi_apci_1564.c | 20 ++++++++++++++------
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
++++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
+@@ -331,14 +331,22 @@ static int apci1564_cos_insn_config(stru
+ unsigned int *data)
+ {
+ struct apci1564_private *devpriv = dev->private;
+- unsigned int shift, oldmask;
++ unsigned int shift, oldmask, himask, lomask;
+
+ switch (data[0]) {
+ case INSN_CONFIG_DIGITAL_TRIG:
+ if (data[1] != 0)
+ return -EINVAL;
+ shift = data[3];
+- oldmask = (1U << shift) - 1;
++ if (shift < 32) {
++ oldmask = (1U << shift) - 1;
++ himask = data[4] << shift;
++ lomask = data[5] << shift;
++ } else {
++ oldmask = 0xffffffffu;
++ himask = 0;
++ lomask = 0;
++ }
+ switch (data[2]) {
+ case COMEDI_DIGITAL_TRIG_DISABLE:
+ devpriv->ctrl = 0;
+@@ -362,8 +370,8 @@ static int apci1564_cos_insn_config(stru
+ devpriv->mode2 &= oldmask;
+ }
+ /* configure specified channels */
+- devpriv->mode1 |= data[4] << shift;
+- devpriv->mode2 |= data[5] << shift;
++ devpriv->mode1 |= himask;
++ devpriv->mode2 |= lomask;
+ break;
+ case COMEDI_DIGITAL_TRIG_ENABLE_LEVELS:
+ if (devpriv->ctrl != (APCI1564_DI_IRQ_ENA |
+@@ -380,8 +388,8 @@ static int apci1564_cos_insn_config(stru
+ devpriv->mode2 &= oldmask;
+ }
+ /* configure specified channels */
+- devpriv->mode1 |= data[4] << shift;
+- devpriv->mode2 |= data[5] << shift;
++ devpriv->mode1 |= himask;
++ devpriv->mode2 |= lomask;
+ break;
+ default:
+ return -EINVAL;
--- /dev/null
+From f07804ec77d77f8a9dcf570a24154e17747bc82f Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Fri, 17 Jul 2020 15:52:54 +0100
+Subject: staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit f07804ec77d77f8a9dcf570a24154e17747bc82f upstream.
+
+`ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions
+for the "interrupt" subdevice. When `data[0]` is
+`INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger. When
+`data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising
+and falling edge detection for the digital trigger, using a base channel
+number (or shift amount) in `data[3]`, a rising edge bitmask in
+`data[4]` and falling edge bitmask in `data[5]`.
+
+If the base channel number (shift amount) is greater than or equal to
+the number of channels (24) of the digital input subdevice, there are no
+changes to the rising and falling edges, so the mask of channels to be
+changed can be set to 0, otherwise the mask of channels to be changed,
+and the rising and falling edge bitmasks are shifted by the base channel
+number before calling `ni6527_set_edge_detection()` to change the
+appropriate registers. Unfortunately, the code is comparing the base
+channel (shift amount) to the interrupt subdevice's number of channels
+(1) instead of the digital input subdevice's number of channels (24).
+Fix it by comparing to 32 because all shift amounts for an `unsigned
+int` must be less than that and everything from bit 24 upwards is
+ignored by `ni6527_set_edge_detection()` anyway.
+
+Fixes: 110f9e687c1a8 ("staging: comedi: ni_6527: support INSN_CONFIG_DIGITAL_TRIG")
+Cc: <stable@vger.kernel.org> # 3.17+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20200717145257.112660-2-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/ni_6527.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/comedi/drivers/ni_6527.c
++++ b/drivers/staging/comedi/drivers/ni_6527.c
+@@ -332,7 +332,7 @@ static int ni6527_intr_insn_config(struc
+ case COMEDI_DIGITAL_TRIG_ENABLE_EDGES:
+ /* check shift amount */
+ shift = data[3];
+- if (shift >= s->n_chan) {
++ if (shift >= 32) {
+ mask = 0;
+ rising = 0;
+ falling = 0;
--- /dev/null
+From faaff9765664009c1c7c65551d32e9ed3b1dda8f Mon Sep 17 00:00:00 2001
+From: Rustam Kovhaev <rkovhaev@gmail.com>
+Date: Wed, 22 Jul 2020 09:10:52 -0700
+Subject: staging: wlan-ng: properly check endpoint types
+
+From: Rustam Kovhaev <rkovhaev@gmail.com>
+
+commit faaff9765664009c1c7c65551d32e9ed3b1dda8f upstream.
+
+As syzkaller detected, wlan-ng driver does not do sanity check of
+endpoints in prism2sta_probe_usb(), add check for xfer direction and type
+
+Reported-and-tested-by: syzbot+c2a1fa67c02faa0de723@syzkaller.appspotmail.com
+Link: https://syzkaller.appspot.com/bug?extid=c2a1fa67c02faa0de723
+Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200722161052.999754-1-rkovhaev@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/wlan-ng/prism2usb.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/wlan-ng/prism2usb.c
++++ b/drivers/staging/wlan-ng/prism2usb.c
+@@ -61,11 +61,25 @@ static int prism2sta_probe_usb(struct us
+ const struct usb_device_id *id)
+ {
+ struct usb_device *dev;
+-
++ const struct usb_endpoint_descriptor *epd;
++ const struct usb_host_interface *iface_desc = interface->cur_altsetting;
+ struct wlandevice *wlandev = NULL;
+ struct hfa384x *hw = NULL;
+ int result = 0;
+
++ if (iface_desc->desc.bNumEndpoints != 2) {
++ result = -ENODEV;
++ goto failed;
++ }
++
++ result = -EINVAL;
++ epd = &iface_desc->endpoint[1].desc;
++ if (!usb_endpoint_is_bulk_in(epd))
++ goto failed;
++ epd = &iface_desc->endpoint[2].desc;
++ if (!usb_endpoint_is_bulk_out(epd))
++ goto failed;
++
+ dev = interface_to_usbdev(interface);
+ wlandev = create_wlan();
+ if (!wlandev) {
--- /dev/null
+From 22a82fa7d6c3e16d56a036b1fa697a39b954adf0 Mon Sep 17 00:00:00 2001
+From: Helmut Grohne <helmut.grohne@intenta.de>
+Date: Mon, 13 Jul 2020 09:32:28 +0200
+Subject: tty: xilinx_uartps: Really fix id assignment
+
+From: Helmut Grohne <helmut.grohne@intenta.de>
+
+commit 22a82fa7d6c3e16d56a036b1fa697a39b954adf0 upstream.
+
+The problems started with the revert (18cc7ac8a28e28). The
+cdns_uart_console.index is statically assigned -1. When the port is
+registered, Linux assigns consecutive numbers to it. It turned out that
+when using ttyPS1 as console, the index is not updated as we are reusing
+the same cdns_uart_console instance for multiple ports. When registering
+ttyPS0, it gets updated from -1 to 0, but when registering ttyPS1, it
+already is 0 and not updated.
+
+That led to 2ae11c46d5fdc4. It assigns the index prior to registering
+the uart_driver once. Unfortunately, that ended up breaking the
+situation where the probe order does not match the id order. When using
+the same device tree for both uboot and linux, it is important that the
+serial0 alias points to the console. So some boards reverse those
+aliases. This was reported by Jan Kiszka. The proposed fix was reverting
+the index assignment and going back to the previous iteration.
+
+However such a reversed assignement (serial0 -> uart1, serial1 -> uart0)
+was already partially broken by the revert (18cc7ac8a28e28). While the
+ttyPS device works, the kmsg connection is already broken and kernel
+messages go missing. Reverting the id assignment does not fix this.
+
+>From the xilinx_uartps driver pov (after reverting the refactoring
+commits), there can be only one console. This manifests in static
+variables console_pprt and cdns_uart_console. These variables are not
+properly linked and can go out of sync. The cdns_uart_console.index is
+important for uart_add_one_port. We call that function for each port -
+one of which hopefully is the console. If it isn't, the CON_ENABLED flag
+is not set and console_port is cleared. The next cdns_uart_probe call
+then tries to register the next port using that same cdns_uart_console.
+
+It is important that console_port and cdns_uart_console (and its index
+in particular) stay in sync. The index assignment implemented by
+Shubhrajyoti Datta is correct in principle. It just may have to happen a
+second time if the first cdns_uart_probe call didn't encounter the
+console device. And we shouldn't change the index once the console uart
+is registered.
+
+Reported-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
+Reported-by: Jan Kiszka <jan.kiszka@web.de>
+Link: https://lore.kernel.org/linux-serial/f4092727-d8f5-5f91-2c9f-76643aace993@siemens.com/
+Fixes: 18cc7ac8a28e28 ("Revert "serial: uartps: Register own uart console and driver structures"")
+Fixes: 2ae11c46d5fdc4 ("tty: xilinx_uartps: Fix missing id assignment to the console")
+Fixes: 76ed2e10579671 ("Revert "tty: xilinx_uartps: Fix missing id assignment to the console"")
+Signed-off-by: Helmut Grohne <helmut.grohne@intenta.de>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200713073227.GA3805@laureti-dev
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/xilinx_uartps.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/xilinx_uartps.c
++++ b/drivers/tty/serial/xilinx_uartps.c
+@@ -1559,8 +1559,10 @@ static int cdns_uart_probe(struct platfo
+ * If register_console() don't assign value, then console_port pointer
+ * is cleanup.
+ */
+- if (!console_port)
++ if (!console_port) {
++ cdns_uart_console.index = id;
+ console_port = port;
++ }
+ #endif
+
+ rc = uart_add_one_port(&cdns_uart_uart_driver, port);
+@@ -1573,8 +1575,10 @@ static int cdns_uart_probe(struct platfo
+ #ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE
+ /* This is not port which is used for console that's why clean it up */
+ if (console_port == port &&
+- !(cdns_uart_uart_driver.cons->flags & CON_ENABLED))
++ !(cdns_uart_uart_driver.cons->flags & CON_ENABLED)) {
+ console_port = NULL;
++ cdns_uart_console.index = -1;
++ }
+ #endif
+
+ cdns_uart_data->cts_override = of_property_read_bool(pdev->dev.of_node,
--- /dev/null
+From dbb0897e805f2ab1b8bc358f6c3d878a376b8897 Mon Sep 17 00:00:00 2001
+From: Forest Crossman <cyrozap@gmail.com>
+Date: Fri, 17 Jul 2020 06:27:34 -0500
+Subject: usb: xhci: Fix ASM2142/ASM3142 DMA addressing
+
+From: Forest Crossman <cyrozap@gmail.com>
+
+commit dbb0897e805f2ab1b8bc358f6c3d878a376b8897 upstream.
+
+The ASM2142/ASM3142 (same PCI IDs) does not support full 64-bit DMA
+addresses, which can cause silent memory corruption or IOMMU errors on
+platforms that use the upper bits. Add the XHCI_NO_64BIT_SUPPORT quirk
+to fix this issue.
+
+Signed-off-by: Forest Crossman <cyrozap@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200717112734.328432-1-cyrozap@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-pci.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -250,6 +250,9 @@ static void xhci_pci_quirks(struct devic
+ if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
+ pdev->device == 0x1142)
+ xhci->quirks |= XHCI_TRUST_TX_LENGTH;
++ if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
++ pdev->device == 0x2142)
++ xhci->quirks |= XHCI_NO_64BIT_SUPPORT;
+
+ if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
+ pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI)
--- /dev/null
+From 5ce1a24dd98c00a57a8fa13660648abf7e08e3ef Mon Sep 17 00:00:00 2001
+From: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Date: Fri, 10 Jul 2020 13:57:52 +0800
+Subject: usb: xhci-mtk: fix the failure of bandwidth allocation
+
+From: Chunfeng Yun <chunfeng.yun@mediatek.com>
+
+commit 5ce1a24dd98c00a57a8fa13660648abf7e08e3ef upstream.
+
+The wMaxPacketSize field of endpoint descriptor may be zero
+as default value in alternate interface, and they are not
+actually selected when start stream, so skip them when try to
+allocate bandwidth.
+
+Cc: stable <stable@vger.kernel.org>
+Fixes: 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
+Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Link: https://lore.kernel.org/r/1594360672-2076-1-git-send-email-chunfeng.yun@mediatek.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-mtk-sch.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/usb/host/xhci-mtk-sch.c
++++ b/drivers/usb/host/xhci-mtk-sch.c
+@@ -557,6 +557,10 @@ static bool need_bw_sch(struct usb_host_
+ if (is_fs_or_ls(speed) && !has_tt)
+ return false;
+
++ /* skip endpoint with zero maxpkt */
++ if (usb_endpoint_maxp(&ep->desc) == 0)
++ return false;
++
+ return true;
+ }
+
--- /dev/null
+From ce684552a266cb1c7cc2f7e623f38567adec6653 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Sun, 12 Jul 2020 20:10:12 +0900
+Subject: vt: Reject zero-sized screen buffer size.
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit ce684552a266cb1c7cc2f7e623f38567adec6653 upstream.
+
+syzbot is reporting general protection fault in do_con_write() [1] caused
+by vc->vc_screenbuf == ZERO_SIZE_PTR caused by vc->vc_screenbuf_size == 0
+caused by vc->vc_cols == vc->vc_rows == vc->vc_size_row == 0 caused by
+fb_set_var() from ioctl(FBIOPUT_VSCREENINFO) on /dev/fb0 , for
+gotoxy(vc, 0, 0) from reset_terminal() from vc_init() from vc_allocate()
+ from con_install() from tty_init_dev() from tty_open() on such console
+causes vc->vc_pos == 0x10000000e due to
+((unsigned long) ZERO_SIZE_PTR) + -1U * 0 + (-1U << 1).
+
+I don't think that a console with 0 column or 0 row makes sense. And it
+seems that vc_do_resize() does not intend to allow resizing a console to
+0 column or 0 row due to
+
+ new_cols = (cols ? cols : vc->vc_cols);
+ new_rows = (lines ? lines : vc->vc_rows);
+
+exception.
+
+Theoretically, cols and rows can be any range as long as
+0 < cols * rows * 2 <= KMALLOC_MAX_SIZE is satisfied (e.g.
+cols == 1048576 && rows == 2 is possible) because of
+
+ vc->vc_size_row = vc->vc_cols << 1;
+ vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row;
+
+in visual_init() and kzalloc(vc->vc_screenbuf_size) in vc_allocate().
+
+Since we can detect cols == 0 or rows == 0 via screenbuf_size = 0 in
+visual_init(), we can reject kzalloc(0). Then, vc_allocate() will return
+an error, and con_write() will not be called on a console with 0 column
+or 0 row.
+
+We need to make sure that integer overflow in visual_init() won't happen.
+Since vc_do_resize() restricts cols <= 32767 and rows <= 32767, applying
+1 <= cols <= 32767 and 1 <= rows <= 32767 restrictions to vc_allocate()
+will be practically fine.
+
+This patch does not touch con_init(), for returning -EINVAL there
+does not help when we are not returning -ENOMEM.
+
+[1] https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8
+
+Reported-and-tested-by: syzbot <syzbot+017265e8553724e514e8@syzkaller.appspotmail.com>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200712111013.11881-1-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/vt.c | 29 ++++++++++++++++++-----------
+ 1 file changed, 18 insertions(+), 11 deletions(-)
+
+--- a/drivers/tty/vt/vt.c
++++ b/drivers/tty/vt/vt.c
+@@ -1092,10 +1092,19 @@ static const struct tty_port_operations
+ .destruct = vc_port_destruct,
+ };
+
++/*
++ * Change # of rows and columns (0 means unchanged/the size of fg_console)
++ * [this is to be used together with some user program
++ * like resize that changes the hardware videomode]
++ */
++#define VC_MAXCOL (32767)
++#define VC_MAXROW (32767)
++
+ int vc_allocate(unsigned int currcons) /* return 0 on success */
+ {
+ struct vt_notifier_param param;
+ struct vc_data *vc;
++ int err;
+
+ WARN_CONSOLE_UNLOCKED();
+
+@@ -1125,6 +1134,11 @@ int vc_allocate(unsigned int currcons) /
+ if (!*vc->vc_uni_pagedir_loc)
+ con_set_default_unimap(vc);
+
++ err = -EINVAL;
++ if (vc->vc_cols > VC_MAXCOL || vc->vc_rows > VC_MAXROW ||
++ vc->vc_screenbuf_size > KMALLOC_MAX_SIZE || !vc->vc_screenbuf_size)
++ goto err_free;
++ err = -ENOMEM;
+ vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL);
+ if (!vc->vc_screenbuf)
+ goto err_free;
+@@ -1143,7 +1157,7 @@ err_free:
+ visual_deinit(vc);
+ kfree(vc);
+ vc_cons[currcons].d = NULL;
+- return -ENOMEM;
++ return err;
+ }
+
+ static inline int resize_screen(struct vc_data *vc, int width, int height,
+@@ -1158,14 +1172,6 @@ static inline int resize_screen(struct v
+ return err;
+ }
+
+-/*
+- * Change # of rows and columns (0 means unchanged/the size of fg_console)
+- * [this is to be used together with some user program
+- * like resize that changes the hardware videomode]
+- */
+-#define VC_RESIZE_MAXCOL (32767)
+-#define VC_RESIZE_MAXROW (32767)
+-
+ /**
+ * vc_do_resize - resizing method for the tty
+ * @tty: tty being resized
+@@ -1201,7 +1207,7 @@ static int vc_do_resize(struct tty_struc
+ user = vc->vc_resize_user;
+ vc->vc_resize_user = 0;
+
+- if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW)
++ if (cols > VC_MAXCOL || lines > VC_MAXROW)
+ return -EINVAL;
+
+ new_cols = (cols ? cols : vc->vc_cols);
+@@ -1212,7 +1218,7 @@ static int vc_do_resize(struct tty_struc
+ if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
+ return 0;
+
+- if (new_screen_size > KMALLOC_MAX_SIZE)
++ if (new_screen_size > KMALLOC_MAX_SIZE || !new_screen_size)
+ return -EINVAL;
+ newscreen = kzalloc(new_screen_size, GFP_USER);
+ if (!newscreen)
+@@ -3396,6 +3402,7 @@ static int __init con_init(void)
+ INIT_WORK(&vc_cons[currcons].SAK_work, vc_SAK);
+ tty_port_init(&vc->port);
+ visual_init(vc, currcons, 1);
++ /* Assuming vc->vc_{cols,rows,screenbuf_size} are sane here. */
+ vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_NOWAIT);
+ vc_init(vc, vc->vc_rows, vc->vc_cols,
+ currcons || !vc->vc_sw->con_save_screen);
projects / thirdparty / kernel / stable-queue.git / commitdiff
