--- /dev/null
+From 9ebd796e24008f33f06ebea5a5e6aceb68b51794 Mon Sep 17 00:00:00 2001
+From: Jouni Hogander <jouni.hogander@unikie.com>
+Date: Wed, 27 Nov 2019 08:40:26 +0200
+Subject: can: slcan: Fix use-after-free Read in slcan_open
+
+From: Jouni Hogander <jouni.hogander@unikie.com>
+
+commit 9ebd796e24008f33f06ebea5a5e6aceb68b51794 upstream.
+
+Slcan_open doesn't clean-up device which registration failed from the
+slcan_devs device list. On next open this list is iterated and freed
+device is accessed. Fix this by calling slc_free_netdev in error path.
+
+Driver/net/can/slcan.c is derived from slip.c. Use-after-free error was
+identified in slip_open by syzboz. Same bug is in slcan.c. Here is the
+trace from the Syzbot slip report:
+
+__dump_stack lib/dump_stack.c:77 [inline]
+dump_stack+0x197/0x210 lib/dump_stack.c:118
+print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
+__kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
+kasan_report+0x12/0x20 mm/kasan/common.c:634
+__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
+sl_sync drivers/net/slip/slip.c:725 [inline]
+slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801
+tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469
+tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596
+tiocsetd drivers/tty/tty_io.c:2334 [inline]
+tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594
+vfs_ioctl fs/ioctl.c:46 [inline]
+file_ioctl fs/ioctl.c:509 [inline]
+do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696
+ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
+__do_sys_ioctl fs/ioctl.c:720 [inline]
+__se_sys_ioctl fs/ioctl.c:718 [inline]
+__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
+do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
+entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Fixes: ed50e1600b44 ("slcan: Fix memory leak in error path")
+Cc: Wolfgang Grandegger <wg@grandegger.com>
+Cc: Marc Kleine-Budde <mkl@pengutronix.de>
+Cc: David Miller <davem@davemloft.net>
+Cc: Oliver Hartkopp <socketcan@hartkopp.net>
+Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Signed-off-by: Jouni Hogander <jouni.hogander@unikie.com>
+Cc: linux-stable <stable@vger.kernel.org> # >= v5.4
+Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/slcan.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/can/slcan.c
++++ b/drivers/net/can/slcan.c
+@@ -617,6 +617,7 @@ err_free_chan:
+ sl->tty = NULL;
+ tty->disc_data = NULL;
+ clear_bit(SLF_INUSE, &sl->flags);
++ slc_free_netdev(sl->dev);
+ free_netdev(sl->dev);
+
+ err_exit:
--- /dev/null
+From 6f582b273ec23332074d970a7fb25bef835df71f Mon Sep 17 00:00:00 2001
+From: Pavel Shilovsky <pshilov@microsoft.com>
+Date: Wed, 27 Nov 2019 16:18:39 -0800
+Subject: CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks
+
+From: Pavel Shilovsky <pshilov@microsoft.com>
+
+commit 6f582b273ec23332074d970a7fb25bef835df71f upstream.
+
+Currently when the client creates a cifsFileInfo structure for
+a newly opened file, it allocates a list of byte-range locks
+with a pointer to the new cfile and attaches this list to the
+inode's lock list. The latter happens before initializing all
+other fields, e.g. cfile->tlink. Thus a partially initialized
+cifsFileInfo structure becomes available to other threads that
+walk through the inode's lock list. One example of such a thread
+may be an oplock break worker thread that tries to push all
+cached byte-range locks. This causes NULL-pointer dereference
+in smb2_push_mandatory_locks() when accessing cfile->tlink:
+
+[598428.945633] BUG: kernel NULL pointer dereference, address: 0000000000000038
+...
+[598428.945749] Workqueue: cifsoplockd cifs_oplock_break [cifs]
+[598428.945793] RIP: 0010:smb2_push_mandatory_locks+0xd6/0x5a0 [cifs]
+...
+[598428.945834] Call Trace:
+[598428.945870] ? cifs_revalidate_mapping+0x45/0x90 [cifs]
+[598428.945901] cifs_oplock_break+0x13d/0x450 [cifs]
+[598428.945909] process_one_work+0x1db/0x380
+[598428.945914] worker_thread+0x4d/0x400
+[598428.945921] kthread+0x104/0x140
+[598428.945925] ? process_one_work+0x380/0x380
+[598428.945931] ? kthread_park+0x80/0x80
+[598428.945937] ret_from_fork+0x35/0x40
+
+Fix this by reordering initialization steps of the cifsFileInfo
+structure: initialize all the fields first and then add the new
+byte-range lock list to the inode's lock list.
+
+Cc: Stable <stable@vger.kernel.org>
+Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/file.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/fs/cifs/file.c
++++ b/fs/cifs/file.c
+@@ -313,9 +313,6 @@ cifs_new_fileinfo(struct cifs_fid *fid,
+ INIT_LIST_HEAD(&fdlocks->locks);
+ fdlocks->cfile = cfile;
+ cfile->llist = fdlocks;
+- cifs_down_write(&cinode->lock_sem);
+- list_add(&fdlocks->llist, &cinode->llist);
+- up_write(&cinode->lock_sem);
+
+ cfile->count = 1;
+ cfile->pid = current->tgid;
+@@ -339,6 +336,10 @@ cifs_new_fileinfo(struct cifs_fid *fid,
+ oplock = 0;
+ }
+
++ cifs_down_write(&cinode->lock_sem);
++ list_add(&fdlocks->llist, &cinode->llist);
++ up_write(&cinode->lock_sem);
++
+ spin_lock(&tcon->open_file_lock);
+ if (fid->pending_open->oplock != CIFS_OPLOCK_NO_CHANGE && oplock)
+ oplock = fid->pending_open->oplock;
--- /dev/null
+From fa9c2362497fbd64788063288dc4e74daf977ebb Mon Sep 17 00:00:00 2001
+From: Pavel Shilovsky <pshilov@microsoft.com>
+Date: Thu, 31 Oct 2019 14:18:57 -0700
+Subject: CIFS: Fix SMB2 oplock break processing
+
+From: Pavel Shilovsky <pshilov@microsoft.com>
+
+commit fa9c2362497fbd64788063288dc4e74daf977ebb upstream.
+
+Even when mounting modern protocol version the server may be
+configured without supporting SMB2.1 leases and the client
+uses SMB2 oplock to optimize IO performance through local caching.
+
+However there is a problem in oplock break handling that leads
+to missing a break notification on the client who has a file
+opened. It latter causes big latencies to other clients that
+are trying to open the same file.
+
+The problem reproduces when there are multiple shares from the
+same server mounted on the client. The processing code tries to
+match persistent and volatile file ids from the break notification
+with an open file but it skips all share besides the first one.
+Fix this by looking up in all shares belonging to the server that
+issued the oplock break.
+
+Cc: Stable <stable@vger.kernel.org>
+Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb2misc.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/fs/cifs/smb2misc.c
++++ b/fs/cifs/smb2misc.c
+@@ -673,10 +673,10 @@ smb2_is_valid_oplock_break(char *buffer,
+ spin_lock(&cifs_tcp_ses_lock);
+ list_for_each(tmp, &server->smb_ses_list) {
+ ses = list_entry(tmp, struct cifs_ses, smb_ses_list);
++
+ list_for_each(tmp1, &ses->tcon_list) {
+ tcon = list_entry(tmp1, struct cifs_tcon, tcon_list);
+
+- cifs_stats_inc(&tcon->stats.cifs_stats.num_oplock_brks);
+ spin_lock(&tcon->open_file_lock);
+ list_for_each(tmp2, &tcon->openFileList) {
+ cfile = list_entry(tmp2, struct cifsFileInfo,
+@@ -688,6 +688,8 @@ smb2_is_valid_oplock_break(char *buffer,
+ continue;
+
+ cifs_dbg(FYI, "file id match, oplock break\n");
++ cifs_stats_inc(
++ &tcon->stats.cifs_stats.num_oplock_brks);
+ cinode = CIFS_I(d_inode(cfile->dentry));
+ spin_lock(&cfile->file_info_lock);
+ if (!CIFS_CACHE_WRITE(cinode) &&
+@@ -720,9 +722,6 @@ smb2_is_valid_oplock_break(char *buffer,
+ return true;
+ }
+ spin_unlock(&tcon->open_file_lock);
+- spin_unlock(&cifs_tcp_ses_lock);
+- cifs_dbg(FYI, "No matching file for oplock break\n");
+- return true;
+ }
+ }
+ spin_unlock(&cifs_tcp_ses_lock);
--- /dev/null
+From add3efdd78b8a0478ce423bb9d4df6bd95e8b335 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Tue, 5 Nov 2019 17:44:07 +0100
+Subject: jbd2: Fix possible overflow in jbd2_log_space_left()
+
+From: Jan Kara <jack@suse.cz>
+
+commit add3efdd78b8a0478ce423bb9d4df6bd95e8b335 upstream.
+
+When number of free space in the journal is very low, the arithmetic in
+jbd2_log_space_left() could underflow resulting in very high number of
+free blocks and thus triggering assertion failure in transaction commit
+code complaining there's not enough space in the journal:
+
+J_ASSERT(journal->j_free > 1);
+
+Properly check for the low number of free blocks.
+
+CC: stable@vger.kernel.org
+Reviewed-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20191105164437.32602-1-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/jbd2.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/linux/jbd2.h
++++ b/include/linux/jbd2.h
+@@ -1582,7 +1582,7 @@ static inline int jbd2_space_needed(jour
+ static inline unsigned long jbd2_log_space_left(journal_t *journal)
+ {
+ /* Allow for rounding errors */
+- unsigned long free = journal->j_free - 32;
++ long free = journal->j_free - 32;
+
+ if (journal->j_committing_transaction) {
+ unsigned long committing = atomic_read(&journal->
+@@ -1591,7 +1591,7 @@ static inline unsigned long jbd2_log_spa
+ /* Transaction + control blocks */
+ free -= committing + (committing >> JBD2_CONTROL_BLOCKS_SHIFT);
+ }
+- return free;
++ return max_t(long, free, 0);
+ }
+
+ /*
--- /dev/null
+From e23f568aa63f64cd6b355094224cc9356c0f696b Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Mon, 4 Nov 2019 15:54:29 -0800
+Subject: kernfs: fix ino wrap-around detection
+
+From: Tejun Heo <tj@kernel.org>
+
+commit e23f568aa63f64cd6b355094224cc9356c0f696b upstream.
+
+When the 32bit ino wraps around, kernfs increments the generation
+number to distinguish reused ino instances. The wrap-around detection
+tests whether the allocated ino is lower than what the cursor but the
+cursor is pointing to the next ino to allocate so the condition never
+triggers.
+
+Fix it by remembering the last ino and comparing against that.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Fixes: 4a3ef68acacf ("kernfs: implement i_generation")
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: stable@vger.kernel.org # v4.14+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/kernfs/dir.c | 5 ++---
+ include/linux/kernfs.h | 1 +
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/fs/kernfs/dir.c
++++ b/fs/kernfs/dir.c
+@@ -622,7 +622,6 @@ static struct kernfs_node *__kernfs_new_
+ {
+ struct kernfs_node *kn;
+ u32 gen;
+- int cursor;
+ int ret;
+
+ name = kstrdup_const(name, GFP_KERNEL);
+@@ -635,11 +634,11 @@ static struct kernfs_node *__kernfs_new_
+
+ idr_preload(GFP_KERNEL);
+ spin_lock(&kernfs_idr_lock);
+- cursor = idr_get_cursor(&root->ino_idr);
+ ret = idr_alloc_cyclic(&root->ino_idr, kn, 1, 0, GFP_ATOMIC);
+- if (ret >= 0 && ret < cursor)
++ if (ret >= 0 && ret < root->last_ino)
+ root->next_generation++;
+ gen = root->next_generation;
++ root->last_ino = ret;
+ spin_unlock(&kernfs_idr_lock);
+ idr_preload_end();
+ if (ret < 0)
+--- a/include/linux/kernfs.h
++++ b/include/linux/kernfs.h
+@@ -187,6 +187,7 @@ struct kernfs_root {
+
+ /* private fields, do not use outside kernfs proper */
+ struct idr ino_idr;
++ u32 last_ino;
+ u32 next_generation;
+ struct kernfs_syscall_ops *syscall_ops;
+
--- /dev/null
+From a25e3726b32c746c0098125d4c7463bb84df72bb Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trondmy@gmail.com>
+Date: Wed, 27 Nov 2019 17:05:51 -0500
+Subject: nfsd: Ensure CLONE persists data and metadata changes to the target file
+
+From: Trond Myklebust <trondmy@gmail.com>
+
+commit a25e3726b32c746c0098125d4c7463bb84df72bb upstream.
+
+The NFSv4.2 CLONE operation has implicit persistence requirements on the
+target file, since there is no protocol requirement that the client issue
+a separate operation to persist data.
+For that reason, we should call vfs_fsync_range() on the destination file
+after a successful call to vfs_clone_file_range().
+
+Fixes: ffa0160a1039 ("nfsd: implement the NFSv4.2 CLONE operation")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Cc: stable@vger.kernel.org # v4.5+
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfsd/nfs4proc.c | 3 ++-
+ fs/nfsd/vfs.c | 8 +++++++-
+ fs/nfsd/vfs.h | 2 +-
+ 3 files changed, 10 insertions(+), 3 deletions(-)
+
+--- a/fs/nfsd/nfs4proc.c
++++ b/fs/nfsd/nfs4proc.c
+@@ -1077,7 +1077,8 @@ nfsd4_clone(struct svc_rqst *rqstp, stru
+ goto out;
+
+ status = nfsd4_clone_file_range(src->nf_file, clone->cl_src_pos,
+- dst->nf_file, clone->cl_dst_pos, clone->cl_count);
++ dst->nf_file, clone->cl_dst_pos, clone->cl_count,
++ EX_ISSYNC(cstate->current_fh.fh_export));
+
+ nfsd_file_put(dst);
+ nfsd_file_put(src);
+--- a/fs/nfsd/vfs.c
++++ b/fs/nfsd/vfs.c
+@@ -525,7 +525,7 @@ __be32 nfsd4_set_nfs4_label(struct svc_r
+ #endif
+
+ __be32 nfsd4_clone_file_range(struct file *src, u64 src_pos, struct file *dst,
+- u64 dst_pos, u64 count)
++ u64 dst_pos, u64 count, bool sync)
+ {
+ loff_t cloned;
+
+@@ -534,6 +534,12 @@ __be32 nfsd4_clone_file_range(struct fil
+ return nfserrno(cloned);
+ if (count && cloned != count)
+ return nfserrno(-EINVAL);
++ if (sync) {
++ loff_t dst_end = count ? dst_pos + count - 1 : LLONG_MAX;
++ int status = vfs_fsync_range(dst, dst_pos, dst_end, 0);
++ if (status < 0)
++ return nfserrno(status);
++ }
+ return 0;
+ }
+
+--- a/fs/nfsd/vfs.h
++++ b/fs/nfsd/vfs.h
+@@ -56,7 +56,7 @@ __be32 nfsd4_set_nfs4_label(str
+ __be32 nfsd4_vfs_fallocate(struct svc_rqst *, struct svc_fh *,
+ struct file *, loff_t, loff_t, int);
+ __be32 nfsd4_clone_file_range(struct file *, u64, struct file *,
+- u64, u64);
++ u64, u64, bool);
+ #endif /* CONFIG_NFSD_V4 */
+ __be32 nfsd_create_locked(struct svc_rqst *, struct svc_fh *,
+ char *name, int len, struct iattr *attrs,
--- /dev/null
+From 7c149057d044c52ed1e1d4ee50cf412c8d0f7295 Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Tue, 19 Nov 2019 16:05:33 -0500
+Subject: nfsd: restore NFSv3 ACL support
+
+From: J. Bruce Fields <bfields@redhat.com>
+
+commit 7c149057d044c52ed1e1d4ee50cf412c8d0f7295 upstream.
+
+An error in e333f3bbefe3 left the nfsd_acl_program->pg_vers array empty,
+which effectively turned off the server's support for NFSv3 ACLs.
+
+Fixes: e333f3bbefe3 "nfsd: Allow containers to set supported nfs versions"
+Cc: stable@vger.kernel.org
+Cc: Trond Myklebust <trondmy@gmail.com>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/nfsd/nfssvc.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/fs/nfsd/nfssvc.c
++++ b/fs/nfsd/nfssvc.c
+@@ -95,12 +95,11 @@ static const struct svc_version *nfsd_ac
+
+ #define NFSD_ACL_MINVERS 2
+ #define NFSD_ACL_NRVERS ARRAY_SIZE(nfsd_acl_version)
+-static const struct svc_version *nfsd_acl_versions[NFSD_ACL_NRVERS];
+
+ static struct svc_program nfsd_acl_program = {
+ .pg_prog = NFS_ACL_PROGRAM,
+ .pg_nvers = NFSD_ACL_NRVERS,
+- .pg_vers = nfsd_acl_versions,
++ .pg_vers = nfsd_acl_version,
+ .pg_name = "nfsacl",
+ .pg_class = "nfsd",
+ .pg_stats = &nfsd_acl_svcstats,
coresight-etm4x-fix-input-validation-for-sysfs.patch
input-fix-memory-leak-in-psxpad_spi_probe.patch
media-rc-mark-input-device-as-pointing-stick.patch
+x86-mm-32-sync-only-to-vmalloc_end-in-vmalloc_sync_all.patch
+x86-pci-avoid-amd-fch-xhci-usb-pme-from-d0-defect.patch
+cifs-fix-null-pointer-dereference-in-smb2_push_mandatory_locks.patch
+cifs-fix-smb2-oplock-break-processing.patch
+tty-vt-keyboard-reject-invalid-keycodes.patch
+can-slcan-fix-use-after-free-read-in-slcan_open.patch
+nfsd-ensure-clone-persists-data-and-metadata-changes-to-the-target-file.patch
+nfsd-restore-nfsv3-acl-support.patch
+kernfs-fix-ino-wrap-around-detection.patch
+jbd2-fix-possible-overflow-in-jbd2_log_space_left.patch
--- /dev/null
+From b2b2dd71e0859436d4e05b2f61f86140250ed3f8 Mon Sep 17 00:00:00 2001
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Date: Fri, 22 Nov 2019 12:42:20 -0800
+Subject: tty: vt: keyboard: reject invalid keycodes
+
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+commit b2b2dd71e0859436d4e05b2f61f86140250ed3f8 upstream.
+
+Do not try to handle keycodes that are too big, otherwise we risk doing
+out-of-bounds writes:
+
+BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
+BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
+BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
+Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
+...
+ kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
+ kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
+ input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
+ input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
+ input_pass_values drivers/input/input.c:949 [inline]
+ input_set_keycode+0x290/0x320 drivers/input/input.c:954
+ evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
+ evdev_do_ioctl drivers/input/evdev.c:1150 [inline]
+
+In this case we were dealing with a fuzzed HID device that declared over
+12K buttons, and while HID layer should not be reporting to us such big
+keycodes, we should also be defensive and reject invalid data ourselves as
+well.
+
+Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191122204220.GA129459@dtor-ws
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/keyboard.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/vt/keyboard.c
++++ b/drivers/tty/vt/keyboard.c
+@@ -1491,7 +1491,7 @@ static void kbd_event(struct input_handl
+
+ if (event_type == EV_MSC && event_code == MSC_RAW && HW_RAW(handle->dev))
+ kbd_rawcode(value);
+- if (event_type == EV_KEY)
++ if (event_type == EV_KEY && event_code <= KEY_MAX)
+ kbd_keycode(event_code, value, HW_RAW(handle->dev));
+
+ spin_unlock(&kbd_event_lock);
--- /dev/null
+From 9a62d20027da3164a22244d9f022c0c987261687 Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Tue, 26 Nov 2019 11:09:42 +0100
+Subject: x86/mm/32: Sync only to VMALLOC_END in vmalloc_sync_all()
+
+From: Joerg Roedel <jroedel@suse.de>
+
+commit 9a62d20027da3164a22244d9f022c0c987261687 upstream.
+
+The job of vmalloc_sync_all() is to help the lazy freeing of vmalloc()
+ranges: before such vmap ranges are reused we make sure that they are
+unmapped from every task's page tables.
+
+This is really easy on pagetable setups where the kernel page tables
+are shared between all tasks - this is the case on 32-bit kernels
+with SHARED_KERNEL_PMD = 1.
+
+But on !SHARED_KERNEL_PMD 32-bit kernels this involves iterating
+over the pgd_list and clearing all pmd entries in the pgds that
+are cleared in the init_mm.pgd, which is the reference pagetable
+that the vmalloc() code uses.
+
+In that context the current practice of vmalloc_sync_all() iterating
+until FIX_ADDR_TOP is buggy:
+
+ for (address = VMALLOC_START & PMD_MASK;
+ address >= TASK_SIZE_MAX && address < FIXADDR_TOP;
+ address += PMD_SIZE) {
+ struct page *page;
+
+Because iterating up to FIXADDR_TOP will involve a lot of non-vmalloc
+address ranges:
+
+ VMALLOC -> PKMAP -> LDT -> CPU_ENTRY_AREA -> FIX_ADDR
+
+This is mostly harmless for the FIX_ADDR and CPU_ENTRY_AREA ranges
+that don't clear their pmds, but it's lethal for the LDT range,
+which relies on having different mappings in different processes,
+and 'synchronizing' them in the vmalloc sense corrupts those
+pagetable entries (clearing them).
+
+This got particularly prominent with PTI, which turns SHARED_KERNEL_PMD
+off and makes this the dominant mapping mode on 32-bit.
+
+To make LDT working again vmalloc_sync_all() must only iterate over
+the volatile parts of the kernel address range that are identical
+between all processes.
+
+So the correct check in vmalloc_sync_all() is "address < VMALLOC_END"
+to make sure the VMALLOC areas are synchronized and the LDT
+mapping is not falsely overwritten.
+
+The CPU_ENTRY_AREA and the FIXMAP area are no longer synced either,
+but this is not really a proplem since their PMDs get established
+during bootup and never change.
+
+This change fixes the ldt_gdt selftest in my setup.
+
+[ mingo: Fixed up the changelog to explain the logic and modified the
+ copying to only happen up until VMALLOC_END. ]
+
+Reported-by: Borislav Petkov <bp@suse.de>
+Tested-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Cc: <stable@vger.kernel.org>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: Joerg Roedel <joro@8bytes.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: hpa@zytor.com
+Fixes: 7757d607c6b3: ("x86/pti: Allow CONFIG_PAGE_TABLE_ISOLATION for x86_32")
+Link: https://lkml.kernel.org/r/20191126111119.GA110513@gmail.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/mm/fault.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/mm/fault.c
++++ b/arch/x86/mm/fault.c
+@@ -197,7 +197,7 @@ void vmalloc_sync_all(void)
+ return;
+
+ for (address = VMALLOC_START & PMD_MASK;
+- address >= TASK_SIZE_MAX && address < FIXADDR_TOP;
++ address >= TASK_SIZE_MAX && address < VMALLOC_END;
+ address += PMD_SIZE) {
+ struct page *page;
+
--- /dev/null
+From 7e8ce0e2b036dbc6617184317983aea4f2c52099 Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Mon, 2 Sep 2019 22:52:52 +0800
+Subject: x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit 7e8ce0e2b036dbc6617184317983aea4f2c52099 upstream.
+
+The AMD FCH USB XHCI Controller advertises support for generating PME#
+while in D0. When in D0, it does signal PME# for USB 3.0 connect events,
+but not for USB 2.0 or USB 1.1 connect events, which means the controller
+doesn't wake correctly for those events.
+
+ 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
+ Subsystem: Dell FCH USB XHCI Controller [1028:087e]
+ Capabilities: [50] Power Management version 3
+ Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
+
+Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not
+assert PME# from D0 so we don't rely on it.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673
+Link: https://lore.kernel.org/r/20190902145252.32111-1-kai.heng.feng@canonical.com
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/pci/fixup.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/arch/x86/pci/fixup.c
++++ b/arch/x86/pci/fixup.c
+@@ -589,6 +589,17 @@ static void pci_fixup_amd_ehci_pme(struc
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7808, pci_fixup_amd_ehci_pme);
+
+ /*
++ * Device [1022:7914]
++ * When in D0, PME# doesn't get asserted when plugging USB 2.0 device.
++ */
++static void pci_fixup_amd_fch_xhci_pme(struct pci_dev *dev)
++{
++ dev_info(&dev->dev, "PME# does not work under D0, disabling it\n");
++ dev->pme_support &= ~(PCI_PM_CAP_PME_D0 >> PCI_PM_CAP_PME_SHIFT);
++}
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7914, pci_fixup_amd_fch_xhci_pme);
++
++/*
+ * Apple MacBook Pro: Avoid [mem 0x7fa00000-0x7fbfffff]
+ *
+ * Using the [mem 0x7fa00000-0x7fbfffff] region, e.g., by assigning it to
projects / thirdparty / kernel / stable-queue.git / commitdiff
