From: Greg Kroah-Hartman Date: Mon, 18 Apr 2022 08:12:57 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v4.9.311~31 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b1d44a5ed2cced3ed447ba1c2122f4b0cc524b23;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: gcc-plugins-latent_entropy-use-dev-urandom.patch kvm-don-t-create-vm-debugfs-files-outside-of-the-vm-directory.patch mm-kmemleak-take-a-full-lowmem-check-in-kmemleak_-_phys.patch mm-page_alloc-fix-build_zonerefs_node.patch --- diff --git a/queue-5.4/gcc-plugins-latent_entropy-use-dev-urandom.patch b/queue-5.4/gcc-plugins-latent_entropy-use-dev-urandom.patch new file mode 100644 index 00000000000..66769232bd2 --- /dev/null +++ b/queue-5.4/gcc-plugins-latent_entropy-use-dev-urandom.patch @@ -0,0 +1,121 @@ +From c40160f2998c897231f8454bf797558d30a20375 Mon Sep 17 00:00:00 2001 +From: "Jason A. Donenfeld" +Date: Wed, 6 Apr 2022 00:28:15 +0200 +Subject: gcc-plugins: latent_entropy: use /dev/urandom + +From: Jason A. Donenfeld + +commit c40160f2998c897231f8454bf797558d30a20375 upstream. + +While the latent entropy plugin mostly doesn't derive entropy from +get_random_const() for measuring the call graph, when __latent_entropy is +applied to a constant, then it's initialized statically to output from +get_random_const(). In that case, this data is derived from a 64-bit +seed, which means a buffer of 512 bits doesn't really have that amount +of compile-time entropy. + +This patch fixes that shortcoming by just buffering chunks of +/dev/urandom output and doling it out as requested. + +At the same time, it's important that we don't break the use of +-frandom-seed, for people who want the runtime benefits of the latent +entropy plugin, while still having compile-time determinism. In that +case, we detect whether gcc's set_random_seed() has been called by +making a call to get_random_seed(noinit=true) in the plugin init +function, which is called after set_random_seed() is called but before +anything that calls get_random_seed(noinit=false), and seeing if it's +zero or not. If it's not zero, we're in deterministic mode, and so we +just generate numbers with a basic xorshift prng. + +Note that we don't detect if -frandom-seed is being used using the +documented local_tick variable, because it's assigned via: + local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000; +which may well overflow and become -1 on its own, and so isn't +reliable: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 + +[kees: The 256 byte rnd_buf size was chosen based on average (250), + median (64), and std deviation (575) bytes of used entropy for a + defconfig x86_64 build] + +Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin") +Cc: stable@vger.kernel.org +Cc: PaX Team +Signed-off-by: Jason A. Donenfeld +Signed-off-by: Kees Cook +Link: https://lore.kernel.org/r/20220405222815.21155-1-Jason@zx2c4.com +Signed-off-by: Greg Kroah-Hartman +--- + scripts/gcc-plugins/latent_entropy_plugin.c | 44 +++++++++++++++++----------- + 1 file changed, 27 insertions(+), 17 deletions(-) + +--- a/scripts/gcc-plugins/latent_entropy_plugin.c ++++ b/scripts/gcc-plugins/latent_entropy_plugin.c +@@ -86,25 +86,31 @@ static struct plugin_info latent_entropy + .help = "disable\tturn off latent entropy instrumentation\n", + }; + +-static unsigned HOST_WIDE_INT seed; +-/* +- * get_random_seed() (this is a GCC function) generates the seed. +- * This is a simple random generator without any cryptographic security because +- * the entropy doesn't come from here. +- */ ++static unsigned HOST_WIDE_INT deterministic_seed; ++static unsigned HOST_WIDE_INT rnd_buf[32]; ++static size_t rnd_idx = ARRAY_SIZE(rnd_buf); ++static int urandom_fd = -1; ++ + static unsigned HOST_WIDE_INT get_random_const(void) + { +- unsigned int i; +- unsigned HOST_WIDE_INT ret = 0; +- +- for (i = 0; i < 8 * sizeof(ret); i++) { +- ret = (ret << 1) | (seed & 1); +- seed >>= 1; +- if (ret & 1) +- seed ^= 0xD800000000000000ULL; ++ if (deterministic_seed) { ++ unsigned HOST_WIDE_INT w = deterministic_seed; ++ w ^= w << 13; ++ w ^= w >> 7; ++ w ^= w << 17; ++ deterministic_seed = w; ++ return deterministic_seed; + } + +- return ret; ++ if (urandom_fd < 0) { ++ urandom_fd = open("/dev/urandom", O_RDONLY); ++ gcc_assert(urandom_fd >= 0); ++ } ++ if (rnd_idx >= ARRAY_SIZE(rnd_buf)) { ++ gcc_assert(read(urandom_fd, rnd_buf, sizeof(rnd_buf)) == sizeof(rnd_buf)); ++ rnd_idx = 0; ++ } ++ return rnd_buf[rnd_idx++]; + } + + static tree tree_get_random_const(tree type) +@@ -549,8 +555,6 @@ static void latent_entropy_start_unit(vo + tree type, id; + int quals; + +- seed = get_random_seed(false); +- + if (in_lto_p) + return; + +@@ -585,6 +589,12 @@ __visible int plugin_init(struct plugin_ + const struct plugin_argument * const argv = plugin_info->argv; + int i; + ++ /* ++ * Call get_random_seed() with noinit=true, so that this returns ++ * 0 in the case where no seed has been passed via -frandom-seed. ++ */ ++ deterministic_seed = get_random_seed(true); ++ + static const struct ggc_root_tab gt_ggc_r_gt_latent_entropy[] = { + { + .base = &latent_entropy_decl, diff --git a/queue-5.4/kvm-don-t-create-vm-debugfs-files-outside-of-the-vm-directory.patch b/queue-5.4/kvm-don-t-create-vm-debugfs-files-outside-of-the-vm-directory.patch new file mode 100644 index 00000000000..9c73a276a61 --- /dev/null +++ b/queue-5.4/kvm-don-t-create-vm-debugfs-files-outside-of-the-vm-directory.patch @@ -0,0 +1,68 @@ +From a44a4cc1c969afec97dbb2aedaf6f38eaa6253bb Mon Sep 17 00:00:00 2001 +From: Oliver Upton +Date: Wed, 6 Apr 2022 23:56:13 +0000 +Subject: KVM: Don't create VM debugfs files outside of the VM directory + +From: Oliver Upton + +commit a44a4cc1c969afec97dbb2aedaf6f38eaa6253bb upstream. + +Unfortunately, there is no guarantee that KVM was able to instantiate a +debugfs directory for a particular VM. To that end, KVM shouldn't even +attempt to create new debugfs files in this case. If the specified +parent dentry is NULL, debugfs_create_file() will instantiate files at +the root of debugfs. + +For arm64, it is possible to create the vgic-state file outside of a +VM directory, the file is not cleaned up when a VM is destroyed. +Nonetheless, the corresponding struct kvm is freed when the VM is +destroyed. + +Nip the problem in the bud for all possible errant debugfs file +creations by initializing kvm->debugfs_dentry to -ENOENT. In so doing, +debugfs_create_file() will fail instead of creating the file in the root +directory. + +Cc: stable@kernel.org +Fixes: 929f45e32499 ("kvm: no need to check return value of debugfs_create functions") +Signed-off-by: Oliver Upton +Signed-off-by: Marc Zyngier +Link: https://lore.kernel.org/r/20220406235615.1447180-2-oupton@google.com +Signed-off-by: Greg Kroah-Hartman +--- + virt/kvm/kvm_main.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -623,7 +623,7 @@ static void kvm_destroy_vm_debugfs(struc + { + int i; + +- if (!kvm->debugfs_dentry) ++ if (IS_ERR(kvm->debugfs_dentry)) + return; + + debugfs_remove_recursive(kvm->debugfs_dentry); +@@ -643,6 +643,12 @@ static int kvm_create_vm_debugfs(struct + struct kvm_stat_data *stat_data; + struct kvm_stats_debugfs_item *p; + ++ /* ++ * Force subsequent debugfs file creations to fail if the VM directory ++ * is not created. ++ */ ++ kvm->debugfs_dentry = ERR_PTR(-ENOENT); ++ + if (!debugfs_initialized()) + return 0; + +@@ -4399,7 +4405,7 @@ static void kvm_uevent_notify_change(uns + } + add_uevent_var(env, "PID=%d", kvm->userspace_pid); + +- if (kvm->debugfs_dentry) { ++ if (!IS_ERR(kvm->debugfs_dentry)) { + char *tmp, *p = kmalloc(PATH_MAX, GFP_KERNEL_ACCOUNT); + + if (p) { diff --git a/queue-5.4/mm-kmemleak-take-a-full-lowmem-check-in-kmemleak_-_phys.patch b/queue-5.4/mm-kmemleak-take-a-full-lowmem-check-in-kmemleak_-_phys.patch new file mode 100644 index 00000000000..aedc5a608c0 --- /dev/null +++ b/queue-5.4/mm-kmemleak-take-a-full-lowmem-check-in-kmemleak_-_phys.patch @@ -0,0 +1,96 @@ +From 23c2d497de21f25898fbea70aeb292ab8acc8c94 Mon Sep 17 00:00:00 2001 +From: Patrick Wang +Date: Thu, 14 Apr 2022 19:14:04 -0700 +Subject: mm: kmemleak: take a full lowmem check in kmemleak_*_phys() + +From: Patrick Wang + +commit 23c2d497de21f25898fbea70aeb292ab8acc8c94 upstream. + +The kmemleak_*_phys() apis do not check the address for lowmem's min +boundary, while the caller may pass an address below lowmem, which will +trigger an oops: + + # echo scan > /sys/kernel/debug/kmemleak + Unable to handle kernel paging request at virtual address ff5fffffffe00000 + Oops [#1] + Modules linked in: + CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33 + Hardware name: riscv-virtio,qemu (DT) + epc : scan_block+0x74/0x15c + ra : scan_block+0x72/0x15c + epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30 + gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200 + t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90 + s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000 + a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001 + a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005 + s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90 + s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0 + s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000 + s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f + t5 : 0000000000000001 t6 : 0000000000000000 + status: 0000000000000100 badaddr: ff5fffffffe00000 cause: 000000000000000d + scan_gray_list+0x12e/0x1a6 + kmemleak_scan+0x2aa/0x57e + kmemleak_write+0x32a/0x40c + full_proxy_write+0x56/0x82 + vfs_write+0xa6/0x2a6 + ksys_write+0x6c/0xe2 + sys_write+0x22/0x2a + ret_from_syscall+0x0/0x2 + +The callers may not quite know the actual address they pass(e.g. from +devicetree). So the kmemleak_*_phys() apis should guarantee the address +they finally use is in lowmem range, so check the address for lowmem's +min boundary. + +Link: https://lkml.kernel.org/r/20220413122925.33856-1-patrick.wang.shcn@gmail.com +Signed-off-by: Patrick Wang +Acked-by: Catalin Marinas +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/kmemleak.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/mm/kmemleak.c ++++ b/mm/kmemleak.c +@@ -1123,7 +1123,7 @@ EXPORT_SYMBOL(kmemleak_no_scan); + void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, int min_count, + gfp_t gfp) + { +- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) ++ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) + kmemleak_alloc(__va(phys), size, min_count, gfp); + } + EXPORT_SYMBOL(kmemleak_alloc_phys); +@@ -1137,7 +1137,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys); + */ + void __ref kmemleak_free_part_phys(phys_addr_t phys, size_t size) + { +- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) ++ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) + kmemleak_free_part(__va(phys), size); + } + EXPORT_SYMBOL(kmemleak_free_part_phys); +@@ -1149,7 +1149,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys); + */ + void __ref kmemleak_not_leak_phys(phys_addr_t phys) + { +- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) ++ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) + kmemleak_not_leak(__va(phys)); + } + EXPORT_SYMBOL(kmemleak_not_leak_phys); +@@ -1161,7 +1161,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys); + */ + void __ref kmemleak_ignore_phys(phys_addr_t phys) + { +- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn) ++ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) + kmemleak_ignore(__va(phys)); + } + EXPORT_SYMBOL(kmemleak_ignore_phys); diff --git a/queue-5.4/mm-page_alloc-fix-build_zonerefs_node.patch b/queue-5.4/mm-page_alloc-fix-build_zonerefs_node.patch new file mode 100644 index 00000000000..ef3db774ac3 --- /dev/null +++ b/queue-5.4/mm-page_alloc-fix-build_zonerefs_node.patch @@ -0,0 +1,69 @@ +From e553f62f10d93551eb883eca227ac54d1a4fad84 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Thu, 14 Apr 2022 19:13:43 -0700 +Subject: mm, page_alloc: fix build_zonerefs_node() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Juergen Gross + +commit e553f62f10d93551eb883eca227ac54d1a4fad84 upstream. + +Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from +zones with pages managed by the buddy allocator") only zones with free +memory are included in a built zonelist. This is problematic when e.g. +all memory of a zone has been ballooned out when zonelists are being +rebuilt. + +The decision whether to rebuild the zonelists when onlining new memory +is done based on populated_zone() returning 0 for the zone the memory +will be added to. The new zone is added to the zonelists only, if it +has free memory pages (managed_zone() returns a non-zero value) after +the memory has been onlined. This implies, that onlining memory will +always free the added pages to the allocator immediately, but this is +not true in all cases: when e.g. running as a Xen guest the onlined new +memory will be added only to the ballooned memory list, it will be freed +only when the guest is being ballooned up afterwards. + +Another problem with using managed_zone() for the decision whether a +zone is being added to the zonelists is, that a zone with all memory +used will in fact be removed from all zonelists in case the zonelists +happen to be rebuilt. + +Use populated_zone() when building a zonelist as it has been done before +that commit. + +There was a report that QubesOS (based on Xen) is hitting this problem. +Xen has switched to use the zone device functionality in kernel 5.9 and +QubesOS wants to use memory hotplugging for guests in order to be able +to start a guest with minimal memory and expand it as needed. This was +the report leading to the patch. + +Link: https://lkml.kernel.org/r/20220407120637.9035-1-jgross@suse.com +Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") +Signed-off-by: Juergen Gross +Reported-by: Marek Marczykowski-Górecki +Acked-by: Michal Hocko +Acked-by: David Hildenbrand +Cc: Marek Marczykowski-Górecki +Reviewed-by: Wei Yang +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/page_alloc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/page_alloc.c ++++ b/mm/page_alloc.c +@@ -5481,7 +5481,7 @@ static int build_zonerefs_node(pg_data_t + do { + zone_type--; + zone = pgdat->node_zones + zone_type; +- if (managed_zone(zone)) { ++ if (populated_zone(zone)) { + zoneref_set_zone(zone, &zonerefs[nr_zones++]); + check_highest_zone(zone_type); + } diff --git a/queue-5.4/series b/queue-5.4/series index b0f671cb869..e94e7a2e52d 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -34,3 +34,7 @@ scsi-mvsas-add-pci-id-of-rocketraid-2640.patch scsi-megaraid_sas-target-with-invalid-lun-id-is-dele.patch drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch perf-imx_ddr-fix-undefined-behavior-due-to-shift-ove.patch +mm-page_alloc-fix-build_zonerefs_node.patch +mm-kmemleak-take-a-full-lowmem-check-in-kmemleak_-_phys.patch +kvm-don-t-create-vm-debugfs-files-outside-of-the-vm-directory.patch +gcc-plugins-latent_entropy-use-dev-urandom.patch