--- /dev/null
+From 67addf29004c5be9fa0383c82a364bb59afc7f84 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Tue, 20 Apr 2021 10:55:12 +0100
+Subject: btrfs: fix metadata extent leak after failure to create subvolume
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 67addf29004c5be9fa0383c82a364bb59afc7f84 upstream.
+
+When creating a subvolume we allocate an extent buffer for its root node
+after starting a transaction. We setup a root item for the subvolume that
+points to that extent buffer and then attempt to insert the root item into
+the root tree - however if that fails, due to ENOMEM for example, we do
+not free the extent buffer previously allocated and we do not abort the
+transaction (as at that point we did nothing that can not be undone).
+
+This means that we effectively do not return the metadata extent back to
+the free space cache/tree and we leave a delayed reference for it which
+causes a metadata extent item to be added to the extent tree, in the next
+transaction commit, without having backreferences. When this happens
+'btrfs check' reports the following:
+
+ $ btrfs check /dev/sdi
+ Opening filesystem to check...
+ Checking filesystem on /dev/sdi
+ UUID: dce2cb9d-025f-4b05-a4bf-cee0ad3785eb
+ [1/7] checking root items
+ [2/7] checking extents
+ ref mismatch on [30425088 16384] extent item 1, found 0
+ backref 30425088 root 256 not referenced back 0x564a91c23d70
+ incorrect global backref count on 30425088 found 1 wanted 0
+ backpointer mismatch on [30425088 16384]
+ owner ref check failed [30425088 16384]
+ ERROR: errors found in extent allocation tree or chunk allocation
+ [3/7] checking free space cache
+ [4/7] checking fs roots
+ [5/7] checking only csums items (without verifying data)
+ [6/7] checking root refs
+ [7/7] checking quota groups skipped (not enabled on this FS)
+ found 212992 bytes used, error(s) found
+ total csum bytes: 0
+ total tree bytes: 131072
+ total fs tree bytes: 32768
+ total extent tree bytes: 16384
+ btree space waste bytes: 124669
+ file data blocks allocated: 65536
+ referenced 65536
+
+So fix this by freeing the metadata extent if btrfs_insert_root() returns
+an error.
+
+CC: stable@vger.kernel.org # 4.4+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/ioctl.c | 18 +++++++++++++++---
+ 1 file changed, 15 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/ioctl.c
++++ b/fs/btrfs/ioctl.c
+@@ -678,8 +678,6 @@ static noinline int create_subvol(struct
+ btrfs_set_root_otransid(root_item, trans->transid);
+
+ btrfs_tree_unlock(leaf);
+- free_extent_buffer(leaf);
+- leaf = NULL;
+
+ btrfs_set_root_dirid(root_item, new_dirid);
+
+@@ -688,8 +686,22 @@ static noinline int create_subvol(struct
+ key.type = BTRFS_ROOT_ITEM_KEY;
+ ret = btrfs_insert_root(trans, fs_info->tree_root, &key,
+ root_item);
+- if (ret)
++ if (ret) {
++ /*
++ * Since we don't abort the transaction in this case, free the
++ * tree block so that we don't leak space and leave the
++ * filesystem in an inconsistent state (an extent item in the
++ * extent tree without backreferences). Also no need to have
++ * the tree block locked since it is not in any tree at this
++ * point, so no other task can find it and use it.
++ */
++ btrfs_free_tree_block(trans, root, leaf, 0, 1);
++ free_extent_buffer(leaf);
+ goto fail;
++ }
++
++ free_extent_buffer(leaf);
++ leaf = NULL;
+
+ key.offset = (u64)-1;
+ new_root = btrfs_get_new_fs_root(fs_info, objectid, anon_dev);
--- /dev/null
+From 061dde8245356d8864d29e25207aa4daa0be4d3c Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Mon, 5 Apr 2021 12:32:16 +0100
+Subject: btrfs: fix race between transaction aborts and fsyncs leading to use-after-free
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 061dde8245356d8864d29e25207aa4daa0be4d3c upstream.
+
+There is a race between a task aborting a transaction during a commit,
+a task doing an fsync and the transaction kthread, which leads to an
+use-after-free of the log root tree. When this happens, it results in a
+stack trace like the following:
+
+ BTRFS info (device dm-0): forced readonly
+ BTRFS warning (device dm-0): Skipping commit of aborted transaction.
+ BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure
+ BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5)
+ BTRFS warning (device dm-0): Skipping commit of aborted transaction.
+ BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10
+ BTRFS error (device dm-0): error writing primary super block to device 1
+ BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10
+ BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10
+ BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10
+ BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers)
+ BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure
+ general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
+ CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
+ RIP: 0010:__mutex_lock+0x139/0xa40
+ Code: c0 74 19 (...)
+ RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202
+ RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002
+ RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000
+ RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000
+ R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040
+ R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358
+ FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+ Call Trace:
+ ? __btrfs_handle_fs_error+0xde/0x146 [btrfs]
+ ? btrfs_sync_log+0x7c1/0xf20 [btrfs]
+ ? btrfs_sync_log+0x7c1/0xf20 [btrfs]
+ btrfs_sync_log+0x7c1/0xf20 [btrfs]
+ btrfs_sync_file+0x40c/0x580 [btrfs]
+ do_fsync+0x38/0x70
+ __x64_sys_fsync+0x10/0x20
+ do_syscall_64+0x33/0x80
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+ RIP: 0033:0x7fa9142a55c3
+ Code: 8b 15 09 (...)
+ RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
+ RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3
+ RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005
+ RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c
+ R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340
+ R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0
+ Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...)
+ ---[ end trace ee2f1b19327d791d ]---
+
+The steps that lead to this crash are the following:
+
+1) We are at transaction N;
+
+2) We have two tasks with a transaction handle attached to transaction N.
+ Task A and Task B. Task B is doing an fsync;
+
+3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree
+ into a local variable named 'log_root_tree' at the top of
+ btrfs_sync_log(). Task B is about to call write_all_supers(), but
+ before that...
+
+4) Task A calls btrfs_commit_transaction(), and after it sets the
+ transaction state to TRANS_STATE_COMMIT_START, an error happens before
+ it waits for the transaction's 'num_writers' counter to reach a value
+ of 1 (no one else attached to the transaction), so it jumps to the
+ label "cleanup_transaction";
+
+5) Task A then calls cleanup_transaction(), where it aborts the
+ transaction, setting BTRFS_FS_STATE_TRANS_ABORTED on fs_info->fs_state,
+ setting the ->aborted field of the transaction and the handle to an
+ errno value and also setting BTRFS_FS_STATE_ERROR on fs_info->fs_state.
+
+ After that, at cleanup_transaction(), it deletes the transaction from
+ the list of transactions (fs_info->trans_list), sets the transaction
+ to the state TRANS_STATE_COMMIT_DOING and then waits for the number
+ of writers to go down to 1, as it's currently 2 (1 for task A and 1
+ for task B);
+
+6) The transaction kthread is running and sees that BTRFS_FS_STATE_ERROR
+ is set in fs_info->fs_state, so it calls btrfs_cleanup_transaction().
+
+ There it sees the list fs_info->trans_list is empty, and then proceeds
+ into calling btrfs_drop_all_logs(), which frees the log root tree with
+ a call to btrfs_free_log_root_tree();
+
+7) Task B calls write_all_supers() and, shortly after, under the label
+ 'out_wake_log_root', it deferences the pointer stored in
+ 'log_root_tree', which was already freed in the previous step by the
+ transaction kthread. This results in a use-after-free leading to a
+ crash.
+
+Fix this by deleting the transaction from the list of transactions at
+cleanup_transaction() only after setting the transaction state to
+TRANS_STATE_COMMIT_DOING and waiting for all existing tasks that are
+attached to the transaction to release their transaction handles.
+This makes the transaction kthread wait for all the tasks attached to
+the transaction to be done with the transaction before dropping the
+log roots and doing other cleanups.
+
+Fixes: ef67963dac255b ("btrfs: drop logs when we've aborted a transaction")
+CC: stable@vger.kernel.org # 5.10+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/transaction.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/transaction.c
++++ b/fs/btrfs/transaction.c
+@@ -1950,7 +1950,6 @@ static void cleanup_transaction(struct b
+ */
+ BUG_ON(list_empty(&cur_trans->list));
+
+- list_del_init(&cur_trans->list);
+ if (cur_trans == fs_info->running_transaction) {
+ cur_trans->state = TRANS_STATE_COMMIT_DOING;
+ spin_unlock(&fs_info->trans_lock);
+@@ -1959,6 +1958,17 @@ static void cleanup_transaction(struct b
+
+ spin_lock(&fs_info->trans_lock);
+ }
++
++ /*
++ * Now that we know no one else is still using the transaction we can
++ * remove the transaction from the list of transactions. This avoids
++ * the transaction kthread from cleaning up the transaction while some
++ * other task is still using it, which could result in a use-after-free
++ * on things like log trees, as it forces the transaction kthread to
++ * wait for this transaction to be cleaned up by us.
++ */
++ list_del_init(&cur_trans->list);
++
+ spin_unlock(&fs_info->trans_lock);
+
+ btrfs_cleanup_one_transaction(trans->transaction, fs_info);
--- /dev/null
+From 1d8ba9e7e785b6625f4d8e978e8a284b144a7077 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Tue, 4 Aug 2020 15:25:47 +0800
+Subject: btrfs: handle remount to no compress during compression
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 1d8ba9e7e785b6625f4d8e978e8a284b144a7077 upstream.
+
+[BUG]
+When running btrfs/071 with inode_need_compress() removed from
+compress_file_range(), we got the following crash:
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000018
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ Workqueue: btrfs-delalloc btrfs_work_helper [btrfs]
+ RIP: 0010:compress_file_range+0x476/0x7b0 [btrfs]
+ Call Trace:
+ ? submit_compressed_extents+0x450/0x450 [btrfs]
+ async_cow_start+0x16/0x40 [btrfs]
+ btrfs_work_helper+0xf2/0x3e0 [btrfs]
+ process_one_work+0x278/0x5e0
+ worker_thread+0x55/0x400
+ ? process_one_work+0x5e0/0x5e0
+ kthread+0x168/0x190
+ ? kthread_create_worker_on_cpu+0x70/0x70
+ ret_from_fork+0x22/0x30
+ ---[ end trace 65faf4eae941fa7d ]---
+
+This is already after the patch "btrfs: inode: fix NULL pointer
+dereference if inode doesn't need compression."
+
+[CAUSE]
+@pages is firstly created by kcalloc() in compress_file_extent():
+ pages = kcalloc(nr_pages, sizeof(struct page *), GFP_NOFS);
+
+Then passed to btrfs_compress_pages() to be utilized there:
+
+ ret = btrfs_compress_pages(...
+ pages,
+ &nr_pages,
+ ...);
+
+btrfs_compress_pages() will initialize each page as output, in
+zlib_compress_pages() we have:
+
+ pages[nr_pages] = out_page;
+ nr_pages++;
+
+Normally this is completely fine, but there is a special case which
+is in btrfs_compress_pages() itself:
+
+ switch (type) {
+ default:
+ return -E2BIG;
+ }
+
+In this case, we didn't modify @pages nor @out_pages, leaving them
+untouched, then when we cleanup pages, the we can hit NULL pointer
+dereference again:
+
+ if (pages) {
+ for (i = 0; i < nr_pages; i++) {
+ WARN_ON(pages[i]->mapping);
+ put_page(pages[i]);
+ }
+ ...
+ }
+
+Since pages[i] are all initialized to zero, and btrfs_compress_pages()
+doesn't change them at all, accessing pages[i]->mapping would lead to
+NULL pointer dereference.
+
+This is not possible for current kernel, as we check
+inode_need_compress() before doing pages allocation.
+But if we're going to remove that inode_need_compress() in
+compress_file_extent(), then it's going to be a problem.
+
+[FIX]
+When btrfs_compress_pages() hits its default case, modify @out_pages to
+0 to prevent such problem from happening.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212331
+CC: stable@vger.kernel.org # 5.10+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/compression.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/compression.c
++++ b/fs/btrfs/compression.c
+@@ -80,10 +80,15 @@ static int compression_compress_pages(in
+ case BTRFS_COMPRESS_NONE:
+ default:
+ /*
+- * This can't happen, the type is validated several times
+- * before we get here. As a sane fallback, return what the
+- * callers will understand as 'no compression happened'.
++ * This can happen when compression races with remount setting
++ * it to 'no compress', while caller doesn't call
++ * inode_need_compress() to check if we really need to
++ * compress.
++ *
++ * Not a big deal, just need to inform caller that we
++ * haven't allocated any pages yet.
+ */
++ *out_pages = 0;
+ return -E2BIG;
+ }
+ }
--- /dev/null
+From f4916649f98e2c7bdba38c6597a98c456c17317d Mon Sep 17 00:00:00 2001
+From: Shyam Prasad N <sprasad@microsoft.com>
+Date: Thu, 29 Apr 2021 07:53:18 +0000
+Subject: cifs: detect dead connections only when echoes are enabled.
+
+From: Shyam Prasad N <sprasad@microsoft.com>
+
+commit f4916649f98e2c7bdba38c6597a98c456c17317d upstream.
+
+We can detect server unresponsiveness only if echoes are enabled.
+Echoes can be disabled under two scenarios:
+1. The connection is low on credits, so we've disabled echoes/oplocks.
+2. The connection has not seen any request till now (other than
+negotiate/sess-setup), which is when we enable these two, based on
+the credits available.
+
+So this fix will check for dead connection, only when echo is enabled.
+
+Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
+CC: <stable@vger.kernel.org> # v5.8+
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/connect.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -663,6 +663,7 @@ server_unresponsive(struct TCP_Server_In
+ */
+ if ((server->tcpStatus == CifsGood ||
+ server->tcpStatus == CifsNeedNegotiate) &&
++ (!server->ops->can_echo || server->ops->can_echo(server)) &&
+ time_after(jiffies, server->lstrp + 3 * server->echo_interval)) {
+ cifs_server_dbg(VFS, "has not responded in %lu seconds. Reconnecting...\n",
+ (3 * server->echo_interval) / HZ);
--- /dev/null
+From a637f4ae037e1e0604ac008564934d63261a8fd1 Mon Sep 17 00:00:00 2001
+From: Eugene Korenevsky <ekorenevsky@astralinux.ru>
+Date: Fri, 16 Apr 2021 10:35:30 +0300
+Subject: cifs: fix out-of-bound memory access when calling smb3_notify() at mount point
+
+From: Eugene Korenevsky <ekorenevsky@astralinux.ru>
+
+commit a637f4ae037e1e0604ac008564934d63261a8fd1 upstream.
+
+If smb3_notify() is called at mount point of CIFS, build_path_from_dentry()
+returns the pointer to kmalloc-ed memory with terminating zero (this is
+empty FileName to be passed to SMB2 CREATE request). This pointer is assigned
+to the `path` variable.
+Then `path + 1` (to skip first backslash symbol) is passed to
+cifs_convert_path_to_utf16(). This is incorrect for empty path and causes
+out-of-bound memory access.
+
+Get rid of this "increase by one". cifs_convert_path_to_utf16() already
+contains the check for leading backslash in the path.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212693
+CC: <stable@vger.kernel.org> # v5.6+
+Signed-off-by: Eugene Korenevsky <ekorenevsky@astralinux.ru>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/smb2ops.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/cifs/smb2ops.c
++++ b/fs/cifs/smb2ops.c
+@@ -2174,7 +2174,7 @@ smb3_notify(const unsigned int xid, stru
+
+ cifs_sb = CIFS_SB(inode->i_sb);
+
+- utf16_path = cifs_convert_path_to_utf16(path + 1, cifs_sb);
++ utf16_path = cifs_convert_path_to_utf16(path, cifs_sb);
+ if (utf16_path == NULL) {
+ rc = -ENOMEM;
+ goto notify_exit;
--- /dev/null
+From 83728cbf366e334301091d5b808add468ab46b27 Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Tue, 13 Apr 2021 14:25:27 -0700
+Subject: cifs: Return correct error code from smb2_get_enc_key
+
+From: Paul Aurich <paul@darkrain42.org>
+
+commit 83728cbf366e334301091d5b808add468ab46b27 upstream.
+
+Avoid a warning if the error percolates back up:
+
+[440700.376476] CIFS VFS: \\otters.example.com crypt_message: Could not get encryption key
+[440700.386947] ------------[ cut here ]------------
+[440700.386948] err = 1
+[440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70
+...
+[440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu
+...
+[440700.397334] Call Trace:
+[440700.397346] __filemap_set_wb_err+0x1a/0x70
+[440700.397419] cifs_writepages+0x9c7/0xb30 [cifs]
+[440700.397426] do_writepages+0x4b/0xe0
+[440700.397444] __filemap_fdatawrite_range+0xcb/0x100
+[440700.397455] filemap_write_and_wait+0x42/0xa0
+[440700.397486] cifs_setattr+0x68b/0xf30 [cifs]
+[440700.397493] notify_change+0x358/0x4a0
+[440700.397500] utimes_common+0xe9/0x1c0
+[440700.397510] do_utimes+0xc5/0x150
+[440700.397520] __x64_sys_utimensat+0x88/0xd0
+
+Fixes: 61cfac6f267d ("CIFS: Fix possible use after free in demultiplex thread")
+Signed-off-by: Paul Aurich <paul@darkrain42.org>
+CC: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/smb2ops.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/cifs/smb2ops.c
++++ b/fs/cifs/smb2ops.c
+@@ -4076,7 +4076,7 @@ smb2_get_enc_key(struct TCP_Server_Info
+ }
+ spin_unlock(&cifs_tcp_ses_lock);
+
+- return 1;
++ return -EAGAIN;
+ }
+ /*
+ * Encrypt or decrypt @rqst message. @rqst[0] has the following format:
--- /dev/null
+From 9f7f2a5e01ab4ee56b6d9c0572536fe5fd56e376 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Wed, 14 Apr 2021 20:12:50 +0300
+Subject: intel_th: pci: Add Rocket Lake CPU support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 9f7f2a5e01ab4ee56b6d9c0572536fe5fd56e376 upstream.
+
+This adds support for the Trace Hub in Rocket Lake CPUs.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable <stable@vger.kernel.org> # v4.14+
+Link: https://lore.kernel.org/r/20210414171251.14672-7-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -278,6 +278,11 @@ static const struct pci_device_id intel_
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x466f),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
++ {
++ /* Rocket Lake CPU */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4c19),
++ .driver_data = (kernel_ulong_t)&intel_th_2x,
++ },
+ { 0 },
+ };
+
--- /dev/null
+From a97709f563a078e259bf0861cd259aa60332890a Mon Sep 17 00:00:00 2001
+From: He Ying <heying24@huawei.com>
+Date: Fri, 23 Apr 2021 04:35:16 -0400
+Subject: irqchip/gic-v3: Do not enable irqs when handling spurious interrups
+
+From: He Ying <heying24@huawei.com>
+
+commit a97709f563a078e259bf0861cd259aa60332890a upstream.
+
+We triggered the following error while running our 4.19 kernel
+with the pseudo-NMI patches backported to it:
+
+[ 14.816231] ------------[ cut here ]------------
+[ 14.816231] kernel BUG at irq.c:99!
+[ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP
+[ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))
+[ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14
+[ 14.816233] Hardware name: evb (DT)
+[ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
+[ 14.816234] pc : asm_nmi_enter+0x94/0x98
+[ 14.816235] lr : asm_nmi_enter+0x18/0x98
+[ 14.816235] sp : ffff000008003c50
+[ 14.816235] pmr_save: 00000070
+[ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
+[ 14.816238] x27: 0000000000000000 x26: ffff000008004000
+[ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
+[ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc
+[ 14.816241] x21: ffff000008003da0 x20: 0000000000000060
+[ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff
+[ 14.816243] x17: 0000000000000008 x16: 003d090000000000
+[ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
+[ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
+[ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
+[ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
+[ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
+[ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000
+[ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000
+[ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
+[ 14.816251] Call trace:
+[ 14.816251] asm_nmi_enter+0x94/0x98
+[ 14.816251] el1_irq+0x8c/0x180 (IRQ C)
+[ 14.816252] gic_handle_irq+0xbc/0x2e4
+[ 14.816252] el1_irq+0xcc/0x180 (IRQ B)
+[ 14.816253] arch_timer_handler_virt+0x38/0x58
+[ 14.816253] handle_percpu_devid_irq+0x90/0x240
+[ 14.816253] generic_handle_irq+0x34/0x50
+[ 14.816254] __handle_domain_irq+0x68/0xc0
+[ 14.816254] gic_handle_irq+0xf8/0x2e4
+[ 14.816255] el1_irq+0xcc/0x180 (IRQ A)
+[ 14.816255] arch_cpu_idle+0x34/0x1c8
+[ 14.816255] default_idle_call+0x24/0x44
+[ 14.816256] do_idle+0x1d0/0x2c8
+[ 14.816256] cpu_startup_entry+0x28/0x30
+[ 14.816256] rest_init+0xb8/0xc8
+[ 14.816257] start_kernel+0x4c8/0x4f4
+[ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
+[ 14.816258] Modules linked in: start_dp(O) smeth(O)
+[ 15.103092] ---[ end trace 701753956cb14aa8 ]---
+[ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt
+[ 15.103099] SMP: stopping secondary CPUs
+[ 15.103100] Kernel Offset: disabled
+[ 15.103100] CPU features: 0x36,a2400218
+[ 15.103100] Memory Limit: none
+
+which is cause by a 'BUG_ON(in_nmi())' in nmi_enter().
+
+From the call trace, we can find three interrupts (noted A, B, C above):
+interrupt (A) is preempted by (B), which is further interrupted by (C).
+
+Subsequent investigations show that (B) results in nmi_enter() being
+called, but that it actually is a spurious interrupt. Furthermore,
+interrupts are reenabled in the context of (B), and (C) fires with
+NMI priority. We end-up with a nested NMI situation, something
+we definitely do not want to (and cannot) handle.
+
+The bug here is that spurious interrupts should never result in any
+state change, and we should just return to the interrupted context.
+Moving the handling of spurious interrupts as early as possible in
+the GICv3 handler fixes this issue.
+
+Fixes: 3f1f3234bc2d ("irqchip/gic-v3: Switch to PMR masking before calling IRQ handler")
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: He Ying <heying24@huawei.com>
+[maz: rewrote commit message, corrected Fixes: tag]
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20210423083516.170111-1-heying24@huawei.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v3.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/irqchip/irq-gic-v3.c
++++ b/drivers/irqchip/irq-gic-v3.c
+@@ -648,6 +648,10 @@ static asmlinkage void __exception_irq_e
+
+ irqnr = gic_read_iar();
+
++ /* Check for special IDs first */
++ if ((irqnr >= 1020 && irqnr <= 1023))
++ return;
++
+ if (gic_supports_nmi() &&
+ unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
+ gic_handle_nmi(irqnr, regs);
+@@ -659,10 +663,6 @@ static asmlinkage void __exception_irq_e
+ gic_arch_enable_irqs();
+ }
+
+- /* Check for special IDs first */
+- if ((irqnr >= 1020 && irqnr <= 1023))
+- return;
+-
+ if (static_branch_likely(&supports_deactivate_key))
+ gic_write_eoir(irqnr);
+ else
mmc-core-do-a-power-cycle-when-the-cmd11-fails.patch
mmc-core-set-read-only-for-sd-cards-with-permanent-write-protect-bit.patch
mmc-core-fix-hanging-on-i-o-during-system-suspend-for-removable-cards.patch
+irqchip-gic-v3-do-not-enable-irqs-when-handling-spurious-interrups.patch
+cifs-return-correct-error-code-from-smb2_get_enc_key.patch
+cifs-fix-out-of-bound-memory-access-when-calling-smb3_notify-at-mount-point.patch
+cifs-detect-dead-connections-only-when-echoes-are-enabled.patch
+smb2-fix-use-after-free-in-smb2_ioctl_query_info.patch
+btrfs-handle-remount-to-no-compress-during-compression.patch
+x86-build-disable-highmem64g-selection-for-m486sx.patch
+btrfs-fix-metadata-extent-leak-after-failure-to-create-subvolume.patch
+intel_th-pci-add-rocket-lake-cpu-support.patch
+btrfs-fix-race-between-transaction-aborts-and-fsyncs-leading-to-use-after-free.patch
--- /dev/null
+From ccd48ec3d4a6cc595b2d9c5146e63b6c23546701 Mon Sep 17 00:00:00 2001
+From: Aurelien Aptel <aaptel@suse.com>
+Date: Fri, 9 Apr 2021 15:47:01 +0200
+Subject: smb2: fix use-after-free in smb2_ioctl_query_info()
+
+From: Aurelien Aptel <aaptel@suse.com>
+
+commit ccd48ec3d4a6cc595b2d9c5146e63b6c23546701 upstream.
+
+* rqst[1,2,3] is allocated in vars
+* each rqst->rq_iov is also allocated in vars or using pooled memory
+
+SMB2_open_free, SMB2_ioctl_free, SMB2_query_info_free are iterating on
+each rqst after vars has been freed (use-after-free), and they are
+freeing the kvec a second time (double-free).
+
+How to trigger:
+
+* compile with KASAN
+* mount a share
+
+$ smbinfo quota /mnt/foo
+Segmentation fault
+$ dmesg
+
+ ==================================================================
+ BUG: KASAN: use-after-free in SMB2_open_free+0x1c/0xa0
+ Read of size 8 at addr ffff888007b10c00 by task python3/1200
+
+ CPU: 2 PID: 1200 Comm: python3 Not tainted 5.12.0-rc6+ #107
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
+ Call Trace:
+ dump_stack+0x93/0xc2
+ print_address_description.constprop.0+0x18/0x130
+ ? SMB2_open_free+0x1c/0xa0
+ ? SMB2_open_free+0x1c/0xa0
+ kasan_report.cold+0x7f/0x111
+ ? smb2_ioctl_query_info+0x240/0x990
+ ? SMB2_open_free+0x1c/0xa0
+ SMB2_open_free+0x1c/0xa0
+ smb2_ioctl_query_info+0x2bf/0x990
+ ? smb2_query_reparse_tag+0x600/0x600
+ ? cifs_mapchar+0x250/0x250
+ ? rcu_read_lock_sched_held+0x3f/0x70
+ ? cifs_strndup_to_utf16+0x12c/0x1c0
+ ? rwlock_bug.part.0+0x60/0x60
+ ? rcu_read_lock_sched_held+0x3f/0x70
+ ? cifs_convert_path_to_utf16+0xf8/0x140
+ ? smb2_check_message+0x6f0/0x6f0
+ cifs_ioctl+0xf18/0x16b0
+ ? smb2_query_reparse_tag+0x600/0x600
+ ? cifs_readdir+0x1800/0x1800
+ ? selinux_bprm_creds_for_exec+0x4d0/0x4d0
+ ? do_user_addr_fault+0x30b/0x950
+ ? __x64_sys_openat+0xce/0x140
+ __x64_sys_ioctl+0xb9/0xf0
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+ RIP: 0033:0x7fdcf1f4ba87
+ Code: b3 66 90 48 8b 05 11 14 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e1 13 2c 00 f7 d8 64 89 01 48
+ RSP: 002b:00007ffef1ce7748 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+ RAX: ffffffffffffffda RBX: 00000000c018cf07 RCX: 00007fdcf1f4ba87
+ RDX: 0000564c467c5590 RSI: 00000000c018cf07 RDI: 0000000000000003
+ RBP: 00007ffef1ce7770 R08: 00007ffef1ce7420 R09: 00007fdcf0e0562b
+ R10: 0000000000000100 R11: 0000000000000246 R12: 0000000000004018
+ R13: 0000000000000001 R14: 0000000000000003 R15: 0000564c467c5590
+
+ Allocated by task 1200:
+ kasan_save_stack+0x1b/0x40
+ __kasan_kmalloc+0x7a/0x90
+ smb2_ioctl_query_info+0x10e/0x990
+ cifs_ioctl+0xf18/0x16b0
+ __x64_sys_ioctl+0xb9/0xf0
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+ Freed by task 1200:
+ kasan_save_stack+0x1b/0x40
+ kasan_set_track+0x1c/0x30
+ kasan_set_free_info+0x20/0x30
+ __kasan_slab_free+0xe5/0x110
+ slab_free_freelist_hook+0x53/0x130
+ kfree+0xcc/0x320
+ smb2_ioctl_query_info+0x2ad/0x990
+ cifs_ioctl+0xf18/0x16b0
+ __x64_sys_ioctl+0xb9/0xf0
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+ The buggy address belongs to the object at ffff888007b10c00
+ which belongs to the cache kmalloc-512 of size 512
+ The buggy address is located 0 bytes inside of
+ 512-byte region [ffff888007b10c00, ffff888007b10e00)
+ The buggy address belongs to the page:
+ page:0000000044e14b75 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7b10
+ head:0000000044e14b75 order:2 compound_mapcount:0 compound_pincount:0
+ flags: 0x100000000010200(slab|head)
+ raw: 0100000000010200 ffffea000015f500 0000000400000004 ffff888001042c80
+ raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
+ page dumped because: kasan: bad access detected
+
+ Memory state around the buggy address:
+ ffff888007b10b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff888007b10b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ >ffff888007b10c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+ ^
+ ffff888007b10c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+ ffff888007b10d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+ ==================================================================
+
+Signed-off-by: Aurelien Aptel <aaptel@suse.com>
+CC: <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/smb2ops.c | 14 +++++---------
+ 1 file changed, 5 insertions(+), 9 deletions(-)
+
+--- a/fs/cifs/smb2ops.c
++++ b/fs/cifs/smb2ops.c
+@@ -1705,18 +1705,14 @@ smb2_ioctl_query_info(const unsigned int
+ }
+
+ iqinf_exit:
+- kfree(vars);
+- kfree(buffer);
+- SMB2_open_free(&rqst[0]);
+- if (qi.flags & PASSTHRU_FSCTL)
+- SMB2_ioctl_free(&rqst[1]);
+- else
+- SMB2_query_info_free(&rqst[1]);
+-
+- SMB2_close_free(&rqst[2]);
++ cifs_small_buf_release(rqst[0].rq_iov[0].iov_base);
++ cifs_small_buf_release(rqst[1].rq_iov[0].iov_base);
++ cifs_small_buf_release(rqst[2].rq_iov[0].iov_base);
+ free_rsp_buf(resp_buftype[0], rsp_iov[0].iov_base);
+ free_rsp_buf(resp_buftype[1], rsp_iov[1].iov_base);
+ free_rsp_buf(resp_buftype[2], rsp_iov[2].iov_base);
++ kfree(vars);
++ kfree(buffer);
+ return rc;
+
+ e_fault:
--- /dev/null
+From 0ef3439cd80ba7770723edb0470d15815914bb62 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Wed, 14 Apr 2021 12:38:28 +0200
+Subject: x86/build: Disable HIGHMEM64G selection for M486SX
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 0ef3439cd80ba7770723edb0470d15815914bb62 upstream.
+
+Fix a regression caused by making the 486SX separately selectable in
+Kconfig, for which the HIGHMEM64G setting has not been updated and
+therefore has become exposed as a user-selectable option for the M486SX
+configuration setting unlike with original M486 and all the other
+settings that choose non-PAE-enabled processors:
+
+ High Memory Support
+ > 1. off (NOHIGHMEM)
+ 2. 4GB (HIGHMEM4G)
+ 3. 64GB (HIGHMEM64G)
+ choice[1-3?]:
+
+With the fix in place the setting is now correctly removed:
+
+ High Memory Support
+ > 1. off (NOHIGHMEM)
+ 2. 4GB (HIGHMEM4G)
+ choice[1-2?]:
+
+ [ bp: Massage commit message. ]
+
+Fixes: 87d6021b8143 ("x86/math-emu: Limit MATH_EMULATION to 486SX compatibles")
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org # v5.5+
+Link: https://lkml.kernel.org/r/alpine.DEB.2.21.2104141221340.44318@angie.orcam.me.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -1414,7 +1414,7 @@ config HIGHMEM4G
+
+ config HIGHMEM64G
+ bool "64GB"
+- depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
++ depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
+ select X86_PAE
+ help
+ Select this if you have a 32-bit processor and more than 4
projects / thirdparty / kernel / stable-queue.git / commitdiff
