From: Greg Kroah-Hartman Date: Fri, 17 Dec 2021 15:08:21 +0000 (+0100) Subject: 4.19-stable patches X-Git-Tag: v4.4.296~61 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0db473ae07a24a4163cd4b7b470ebd6eb04d18b9;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: audit-improve-robustness-of-the-audit-queue-handling.patch dm-btree-remove-fix-use-after-free-in-rebalance_children.patch nfsd-fix-use-after-free-due-to-delegation-race.patch recordmcount.pl-look-for-jgnop-instruction-as-well-as-bcrl-on-s390.patch x86-make-arch_use_memremap_prot-a-generic-kconfig-symbol.patch x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch --- diff --git a/queue-4.19/audit-improve-robustness-of-the-audit-queue-handling.patch b/queue-4.19/audit-improve-robustness-of-the-audit-queue-handling.patch new file mode 100644 index 00000000000..cb6dbee252e --- /dev/null +++ b/queue-4.19/audit-improve-robustness-of-the-audit-queue-handling.patch @@ -0,0 +1,109 @@ +From f4b3ee3c85551d2d343a3ba159304066523f730f Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Thu, 9 Dec 2021 11:46:07 -0500 +Subject: audit: improve robustness of the audit queue handling + +From: Paul Moore + +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 +Tested-by: Gaosheng Cui +Reviewed-by: Richard Guy Briggs +Signed-off-by: Paul Moore +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-4.19/dm-btree-remove-fix-use-after-free-in-rebalance_children.patch b/queue-4.19/dm-btree-remove-fix-use-after-free-in-rebalance_children.patch new file mode 100644 index 00000000000..f2a9f377284 --- /dev/null +++ b/queue-4.19/dm-btree-remove-fix-use-after-free-in-rebalance_children.patch @@ -0,0 +1,32 @@ +From 1b8d2789dad0005fd5e7d35dab26a8e1203fb6da Mon Sep 17 00:00:00 2001 +From: Joe Thornber +Date: Wed, 24 Nov 2021 12:07:39 -0500 +Subject: dm btree remove: fix use after free in rebalance_children() + +From: Joe Thornber + +commit 1b8d2789dad0005fd5e7d35dab26a8e1203fb6da upstream. + +Move dm_tm_unlock() after dm_tm_dec(). + +Cc: stable@vger.kernel.org +Signed-off-by: Joe Thornber +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-4.19/nfsd-fix-use-after-free-due-to-delegation-race.patch b/queue-4.19/nfsd-fix-use-after-free-due-to-delegation-race.patch new file mode 100644 index 00000000000..4213ebd6670 --- /dev/null +++ b/queue-4.19/nfsd-fix-use-after-free-due-to-delegation-race.patch @@ -0,0 +1,66 @@ +From 548ec0805c399c65ed66c6641be467f717833ab5 Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +Date: Mon, 29 Nov 2021 15:08:00 -0500 +Subject: nfsd: fix use-after-free due to delegation race + +From: J. Bruce Fields + +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 +[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 +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-4.19/recordmcount.pl-look-for-jgnop-instruction-as-well-as-bcrl-on-s390.patch b/queue-4.19/recordmcount.pl-look-for-jgnop-instruction-as-well-as-bcrl-on-s390.patch new file mode 100644 index 00000000000..425644c9e38 --- /dev/null +++ b/queue-4.19/recordmcount.pl-look-for-jgnop-instruction-as-well-as-bcrl-on-s390.patch @@ -0,0 +1,36 @@ +From 85bf17b28f97ca2749968d8786dc423db320d9c2 Mon Sep 17 00:00:00 2001 +From: Jerome Marchand +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 + +commit 85bf17b28f97ca2749968d8786dc423db320d9c2 upstream. + +On s390, recordmcount.pl is looking for "bcrl 0," instructions in +the objdump -d outpout. However since binutils 2.37, objdump -d +display "jgnop " for the same instruction. Update the +mcount_regex so that it accepts both. + +Signed-off-by: Jerome Marchand +Reviewed-by: Miroslav Benes +Acked-by: Steven Rostedt (VMware) +Cc: +Link: https://lore.kernel.org/r/20211210093827.1623286-1-jmarchan@redhat.com +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + 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\$"; diff --git a/queue-4.19/series b/queue-4.19/series index 066bd71eee5..9253ff79b04 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -8,3 +8,9 @@ net-netlink-af_netlink-prevent-empty-skb-by-adding-a.patch 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 diff --git a/queue-4.19/x86-make-arch_use_memremap_prot-a-generic-kconfig-symbol.patch b/queue-4.19/x86-make-arch_use_memremap_prot-a-generic-kconfig-symbol.patch new file mode 100644 index 00000000000..c5de32f111a --- /dev/null +++ b/queue-4.19/x86-make-arch_use_memremap_prot-a-generic-kconfig-symbol.patch @@ -0,0 +1,113 @@ +From ce9084ba0d1d8030adee7038ace32f8d9d423d0f Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Sat, 2 Feb 2019 10:41:17 +0100 +Subject: x86: Make ARCH_USE_MEMREMAP_PROT a generic Kconfig symbol + +From: Ard Biesheuvel + +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 +Cc: AKASHI Takahiro +Cc: Alexander Graf +Cc: Bjorn Andersson +Cc: Borislav Petkov +Cc: Heinrich Schuchardt +Cc: Jeffrey Hugo +Cc: Lee Jones +Cc: Leif Lindholm +Cc: Linus Torvalds +Cc: Matt Fleming +Cc: Peter Jones +Cc: Peter Zijlstra +Cc: Sai Praneeth Prakhya +Cc: Thomas Gleixner +Cc: linux-efi@vger.kernel.org +Link: http://lkml.kernel.org/r/20190202094119.13230-9-ard.biesheuvel@linaro.org +Signed-off-by: Ingo Molnar +Cc: Tom Lendacky +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-4.19/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch b/queue-4.19/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch new file mode 100644 index 00000000000..6b15059db00 --- /dev/null +++ b/queue-4.19/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch @@ -0,0 +1,60 @@ +From 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Wed, 20 Oct 2021 13:02:11 -0500 +Subject: x86/sme: Explicitly map new EFI memmap table as encrypted + +From: Tom Lendacky + +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: # 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 +[ardb: incorporate Kconfig fix by Arnd] +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + 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;