--- /dev/null
+From f4b3ee3c85551d2d343a3ba159304066523f730f Mon Sep 17 00:00:00 2001
+From: Paul Moore <paul@paul-moore.com>
+Date: Thu, 9 Dec 2021 11:46:07 -0500
+Subject: audit: improve robustness of the audit queue handling
+
+From: Paul Moore <paul@paul-moore.com>
+
+commit f4b3ee3c85551d2d343a3ba159304066523f730f upstream.
+
+If the audit daemon were ever to get stuck in a stopped state the
+kernel's kauditd_thread() could get blocked attempting to send audit
+records to the userspace audit daemon. With the kernel thread
+blocked it is possible that the audit queue could grow unbounded as
+certain audit record generating events must be exempt from the queue
+limits else the system enter a deadlock state.
+
+This patch resolves this problem by lowering the kernel thread's
+socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks
+the kauditd_send_queue() function to better manage the various audit
+queues when connection problems occur between the kernel and the
+audit daemon. With this patch, the backlog may temporarily grow
+beyond the defined limits when the audit daemon is stopped and the
+system is under heavy audit pressure, but kauditd_thread() will
+continue to make progress and drain the queues as it would for other
+connection problems. For example, with the audit daemon put into a
+stopped state and the system configured to audit every syscall it
+was still possible to shutdown the system without a kernel panic,
+deadlock, etc.; granted, the system was slow to shutdown but that is
+to be expected given the extreme pressure of recording every syscall.
+
+The timeout value of HZ/10 was chosen primarily through
+experimentation and this developer's "gut feeling". There is likely
+no one perfect value, but as this scenario is limited in scope (root
+privileges would be needed to send SIGSTOP to the audit daemon), it
+is likely not worth exposing this as a tunable at present. This can
+always be done at a later date if it proves necessary.
+
+Cc: stable@vger.kernel.org
+Fixes: 5b52330bbfe63 ("audit: fix auditd/kernel connection state tracking")
+Reported-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Tested-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/audit.c | 21 ++++++++++-----------
+ 1 file changed, 10 insertions(+), 11 deletions(-)
+
+--- a/kernel/audit.c
++++ b/kernel/audit.c
+@@ -726,7 +726,7 @@ static int kauditd_send_queue(struct soc
+ {
+ int rc = 0;
+ struct sk_buff *skb;
+- static unsigned int failed = 0;
++ unsigned int failed = 0;
+
+ /* NOTE: kauditd_thread takes care of all our locking, we just use
+ * the netlink info passed to us (e.g. sk and portid) */
+@@ -743,32 +743,30 @@ static int kauditd_send_queue(struct soc
+ continue;
+ }
+
++retry:
+ /* grab an extra skb reference in case of error */
+ skb_get(skb);
+ rc = netlink_unicast(sk, skb, portid, 0);
+ if (rc < 0) {
+- /* fatal failure for our queue flush attempt? */
++ /* send failed - try a few times unless fatal error */
+ if (++failed >= retry_limit ||
+ rc == -ECONNREFUSED || rc == -EPERM) {
+- /* yes - error processing for the queue */
+ sk = NULL;
+ if (err_hook)
+ (*err_hook)(skb);
+- if (!skb_hook)
+- goto out;
+- /* keep processing with the skb_hook */
++ if (rc == -EAGAIN)
++ rc = 0;
++ /* continue to drain the queue */
+ continue;
+ } else
+- /* no - requeue to preserve ordering */
+- skb_queue_head(queue, skb);
++ goto retry;
+ } else {
+- /* it worked - drop the extra reference and continue */
++ /* skb sent - drop the extra reference and continue */
+ consume_skb(skb);
+ failed = 0;
+ }
+ }
+
+-out:
+ return (rc >= 0 ? 0 : rc);
+ }
+
+@@ -1557,7 +1555,8 @@ static int __net_init audit_net_init(str
+ audit_panic("cannot initialize netlink socket in namespace");
+ return -ENOMEM;
+ }
+- aunet->sk->sk_sndtimeo = MAX_SCHEDULE_TIMEOUT;
++ /* limit the timeout in case auditd is blocked/stopped */
++ aunet->sk->sk_sndtimeo = HZ / 10;
+
+ return 0;
+ }
--- /dev/null
+From 1b8d2789dad0005fd5e7d35dab26a8e1203fb6da Mon Sep 17 00:00:00 2001
+From: Joe Thornber <ejt@redhat.com>
+Date: Wed, 24 Nov 2021 12:07:39 -0500
+Subject: dm btree remove: fix use after free in rebalance_children()
+
+From: Joe Thornber <ejt@redhat.com>
+
+commit 1b8d2789dad0005fd5e7d35dab26a8e1203fb6da upstream.
+
+Move dm_tm_unlock() after dm_tm_dec().
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Joe Thornber <ejt@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/persistent-data/dm-btree-remove.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/persistent-data/dm-btree-remove.c
++++ b/drivers/md/persistent-data/dm-btree-remove.c
+@@ -423,9 +423,9 @@ static int rebalance_children(struct sha
+
+ memcpy(n, dm_block_data(child),
+ dm_bm_block_size(dm_tm_get_bm(info->tm)));
+- dm_tm_unlock(info->tm, child);
+
+ dm_tm_dec(info->tm, dm_block_location(child));
++ dm_tm_unlock(info->tm, child);
+ return 0;
+ }
+
--- /dev/null
+From 548ec0805c399c65ed66c6641be467f717833ab5 Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Mon, 29 Nov 2021 15:08:00 -0500
+Subject: nfsd: fix use-after-free due to delegation race
+
+From: J. Bruce Fields <bfields@redhat.com>
+
+commit 548ec0805c399c65ed66c6641be467f717833ab5 upstream.
+
+A delegation break could arrive as soon as we've called vfs_setlease. A
+delegation break runs a callback which immediately (in
+nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If we
+then exit nfs4_set_delegation without hashing the delegation, it will be
+freed as soon as the callback is done with it, without ever being
+removed from del_recall_lru.
+
+Symptoms show up later as use-after-free or list corruption warnings,
+usually in the laundromat thread.
+
+I suspect aba2072f4523 "nfsd: grant read delegations to clients holding
+writes" made this bug easier to hit, but I looked as far back as v3.0
+and it looks to me it already had the same problem. So I'm not sure
+where the bug was introduced; it may have been there from the beginning.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+[Salvatore Bonaccorso: Backport for context changes to versions which do
+not have 20b7d86f29d3 ("nfsd: use boottime for lease expiry calculation")]
+Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/nfs4state.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/fs/nfsd/nfs4state.c
++++ b/fs/nfsd/nfs4state.c
+@@ -975,6 +975,11 @@ hash_delegation_locked(struct nfs4_deleg
+ return 0;
+ }
+
++static bool delegation_hashed(struct nfs4_delegation *dp)
++{
++ return !(list_empty(&dp->dl_perfile));
++}
++
+ static bool
+ unhash_delegation_locked(struct nfs4_delegation *dp)
+ {
+@@ -982,7 +987,7 @@ unhash_delegation_locked(struct nfs4_del
+
+ lockdep_assert_held(&state_lock);
+
+- if (list_empty(&dp->dl_perfile))
++ if (!delegation_hashed(dp))
+ return false;
+
+ dp->dl_stid.sc_type = NFS4_CLOSED_DELEG_STID;
+@@ -3912,7 +3917,7 @@ static void nfsd4_cb_recall_prepare(stru
+ * queued for a lease break. Don't queue it again.
+ */
+ spin_lock(&state_lock);
+- if (dp->dl_time == 0) {
++ if (delegation_hashed(dp) && dp->dl_time == 0) {
+ dp->dl_time = get_seconds();
+ list_add_tail(&dp->dl_recall_lru, &nn->del_recall_lru);
+ }
--- /dev/null
+From 85bf17b28f97ca2749968d8786dc423db320d9c2 Mon Sep 17 00:00:00 2001
+From: Jerome Marchand <jmarchan@redhat.com>
+Date: Fri, 10 Dec 2021 10:38:27 +0100
+Subject: recordmcount.pl: look for jgnop instruction as well as bcrl on s390
+
+From: Jerome Marchand <jmarchan@redhat.com>
+
+commit 85bf17b28f97ca2749968d8786dc423db320d9c2 upstream.
+
+On s390, recordmcount.pl is looking for "bcrl 0,<xxx>" instructions in
+the objdump -d outpout. However since binutils 2.37, objdump -d
+display "jgnop <xxx>" for the same instruction. Update the
+mcount_regex so that it accepts both.
+
+Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
+Reviewed-by: Miroslav Benes <mbenes@suse.cz>
+Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20211210093827.1623286-1-jmarchan@redhat.com
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/recordmcount.pl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/scripts/recordmcount.pl
++++ b/scripts/recordmcount.pl
+@@ -252,7 +252,7 @@ if ($arch eq "x86_64") {
+
+ } elsif ($arch eq "s390" && $bits == 64) {
+ if ($cc =~ /-DCC_USING_HOTPATCH/) {
+- $mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*c0 04 00 00 00 00\\s*brcl\\s*0,[0-9a-f]+ <([^\+]*)>\$";
++ $mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*c0 04 00 00 00 00\\s*(bcrl\\s*0,|jgnop\\s*)[0-9a-f]+ <([^\+]*)>\$";
+ $mcount_adjust = 0;
+ } else {
+ $mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*R_390_(PC|PLT)32DBL\\s+_mcount\\+0x2\$";
tracing-fix-a-kmemleak-false-positive-in-tracing_map.patch
hwmon-dell-smm-fix-warning-on-proc-i8k-creation-error.patch
mac80211-send-addba-requests-using-the-tid-queue-of-the-aggregation-session.patch
+recordmcount.pl-look-for-jgnop-instruction-as-well-as-bcrl-on-s390.patch
+dm-btree-remove-fix-use-after-free-in-rebalance_children.patch
+audit-improve-robustness-of-the-audit-queue-handling.patch
+nfsd-fix-use-after-free-due-to-delegation-race.patch
+x86-make-arch_use_memremap_prot-a-generic-kconfig-symbol.patch
+x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch
--- /dev/null
+From ce9084ba0d1d8030adee7038ace32f8d9d423d0f Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Date: Sat, 2 Feb 2019 10:41:17 +0100
+Subject: x86: Make ARCH_USE_MEMREMAP_PROT a generic Kconfig symbol
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+commit ce9084ba0d1d8030adee7038ace32f8d9d423d0f upstream.
+
+Turn ARCH_USE_MEMREMAP_PROT into a generic Kconfig symbol, and fix the
+dependency expression to reflect that AMD_MEM_ENCRYPT depends on it,
+instead of the other way around. This will permit ARCH_USE_MEMREMAP_PROT
+to be selected by other architectures.
+
+Note that the encryption related early memremap routines in
+arch/x86/mm/ioremap.c cannot be built for 32-bit x86 without triggering
+the following warning:
+
+ arch/x86//mm/ioremap.c: In function 'early_memremap_encrypted':
+ >> arch/x86/include/asm/pgtable_types.h:193:27: warning: conversion from
+ 'long long unsigned int' to 'long unsigned int' changes
+ value from '9223372036854776163' to '355' [-Woverflow]
+ #define __PAGE_KERNEL_ENC (__PAGE_KERNEL | _PAGE_ENC)
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~
+ arch/x86//mm/ioremap.c:713:46: note: in expansion of macro '__PAGE_KERNEL_ENC'
+ return early_memremap_prot(phys_addr, size, __PAGE_KERNEL_ENC);
+
+which essentially means they are 64-bit only anyway. However, we cannot
+make them dependent on CONFIG_ARCH_HAS_MEM_ENCRYPT, since that is always
+defined, even for i386 (and changing that results in a slew of build errors)
+
+So instead, build those routines only if CONFIG_AMD_MEM_ENCRYPT is
+defined.
+
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
+Cc: Alexander Graf <agraf@suse.de>
+Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
+Cc: Jeffrey Hugo <jhugo@codeaurora.org>
+Cc: Lee Jones <lee.jones@linaro.org>
+Cc: Leif Lindholm <leif.lindholm@linaro.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Matt Fleming <matt@codeblueprint.co.uk>
+Cc: Peter Jones <pjones@redhat.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: linux-efi@vger.kernel.org
+Link: http://lkml.kernel.org/r/20190202094119.13230-9-ard.biesheuvel@linaro.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Cc: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/Kconfig | 3 +++
+ arch/x86/Kconfig | 5 +----
+ arch/x86/mm/ioremap.c | 4 ++--
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/arch/Kconfig
++++ b/arch/Kconfig
+@@ -870,6 +870,9 @@ config HAVE_ARCH_PREL32_RELOCATIONS
+ architectures, and don't require runtime relocation on relocatable
+ kernels.
+
++config ARCH_USE_MEMREMAP_PROT
++ bool
++
+ source "kernel/gcov/Kconfig"
+
+ source "scripts/gcc-plugins/Kconfig"
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -1489,6 +1489,7 @@ config AMD_MEM_ENCRYPT
+ bool "AMD Secure Memory Encryption (SME) support"
+ depends on X86_64 && CPU_SUP_AMD
+ select DYNAMIC_PHYSICAL_MASK
++ select ARCH_USE_MEMREMAP_PROT
+ ---help---
+ Say yes to enable support for the encryption of system memory.
+ This requires an AMD processor that supports Secure Memory
+@@ -1507,10 +1508,6 @@ config AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
+ If set to N, then the encryption of system memory can be
+ activated with the mem_encrypt=on command line option.
+
+-config ARCH_USE_MEMREMAP_PROT
+- def_bool y
+- depends on AMD_MEM_ENCRYPT
+-
+ # Common NUMA Features
+ config NUMA
+ bool "Numa Memory Allocation and Scheduler Support"
+--- a/arch/x86/mm/ioremap.c
++++ b/arch/x86/mm/ioremap.c
+@@ -697,7 +697,7 @@ bool phys_mem_access_encrypted(unsigned
+ return arch_memremap_can_ram_remap(phys_addr, size, 0);
+ }
+
+-#ifdef CONFIG_ARCH_USE_MEMREMAP_PROT
++#ifdef CONFIG_AMD_MEM_ENCRYPT
+ /* Remap memory with encryption */
+ void __init *early_memremap_encrypted(resource_size_t phys_addr,
+ unsigned long size)
+@@ -739,7 +739,7 @@ void __init *early_memremap_decrypted_wp
+
+ return early_memremap_prot(phys_addr, size, __PAGE_KERNEL_NOENC_WP);
+ }
+-#endif /* CONFIG_ARCH_USE_MEMREMAP_PROT */
++#endif /* CONFIG_AMD_MEM_ENCRYPT */
+
+ static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __page_aligned_bss;
+
--- /dev/null
+From 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+Date: Wed, 20 Oct 2021 13:02:11 -0500
+Subject: x86/sme: Explicitly map new EFI memmap table as encrypted
+
+From: Tom Lendacky <thomas.lendacky@amd.com>
+
+commit 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 upstream.
+
+Reserving memory using efi_mem_reserve() calls into the x86
+efi_arch_mem_reserve() function. This function will insert a new EFI
+memory descriptor into the EFI memory map representing the area of
+memory to be reserved and marking it as EFI runtime memory. As part
+of adding this new entry, a new EFI memory map is allocated and mapped.
+The mapping is where a problem can occur. This new memory map is mapped
+using early_memremap() and generally mapped encrypted, unless the new
+memory for the mapping happens to come from an area of memory that is
+marked as EFI_BOOT_SERVICES_DATA memory. In this case, the new memory will
+be mapped unencrypted. However, during replacement of the old memory map,
+efi_mem_type() is disabled, so the new memory map will now be long-term
+mapped encrypted (in efi.memmap), resulting in the map containing invalid
+data and causing the kernel boot to crash.
+
+Since it is known that the area will be mapped encrypted going forward,
+explicitly map the new memory map as encrypted using early_memremap_prot().
+
+Cc: <stable@vger.kernel.org> # 4.14.x
+Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear")
+Link: https://lore.kernel.org/all/ebf1eb2940405438a09d51d121ec0d02c8755558.1634752931.git.thomas.lendacky@amd.com/
+Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
+[ardb: incorporate Kconfig fix by Arnd]
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/Kconfig | 1 +
+ arch/x86/platform/efi/quirks.c | 3 ++-
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -1950,6 +1950,7 @@ config EFI
+ depends on ACPI
+ select UCS2_STRING
+ select EFI_RUNTIME_WRAPPERS
++ select ARCH_USE_MEMREMAP_PROT
+ ---help---
+ This enables the kernel to use EFI runtime services that are
+ available (such as the EFI variable services).
+--- a/arch/x86/platform/efi/quirks.c
++++ b/arch/x86/platform/efi/quirks.c
+@@ -278,7 +278,8 @@ void __init efi_arch_mem_reserve(phys_ad
+ return;
+ }
+
+- new = early_memremap(new_phys, new_size);
++ new = early_memremap_prot(new_phys, new_size,
++ pgprot_val(pgprot_encrypted(FIXMAP_PAGE_NORMAL)));
+ if (!new) {
+ pr_err("Failed to map new boot services memmap\n");
+ return;
projects / thirdparty / kernel / stable-queue.git / commitdiff
