--- /dev/null
+From c3481b6b75b4797657838f44028fd28226ab48e0 Mon Sep 17 00:00:00 2001
+From: Tony Luck <tony.luck@intel.com>
+Date: Wed, 22 Jun 2022 10:09:06 -0700
+Subject: ACPI: APEI: Better fix to avoid spamming the console with old error logs
+
+From: Tony Luck <tony.luck@intel.com>
+
+commit c3481b6b75b4797657838f44028fd28226ab48e0 upstream.
+
+The fix in commit 3f8dec116210 ("ACPI/APEI: Limit printable size of BERT
+table data") does not work as intended on systems where the BIOS has a
+fixed size block of memory for the BERT table, relying on s/w to quit
+when it finds a record with estatus->block_status == 0. On these systems
+all errors are suppressed because the check:
+
+ if (region_len < ACPI_BERT_PRINT_MAX_LEN)
+
+always fails.
+
+New scheme skips individual CPER records that are too large, and also
+limits the total number of records that will be printed to 5.
+
+Fixes: 3f8dec116210 ("ACPI/APEI: Limit printable size of BERT table data")
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Tony Luck <tony.luck@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/apei/bert.c | 31 +++++++++++++++++++++++--------
+ 1 file changed, 23 insertions(+), 8 deletions(-)
+
+--- a/drivers/acpi/apei/bert.c
++++ b/drivers/acpi/apei/bert.c
+@@ -29,16 +29,26 @@
+
+ #undef pr_fmt
+ #define pr_fmt(fmt) "BERT: " fmt
++
++#define ACPI_BERT_PRINT_MAX_RECORDS 5
+ #define ACPI_BERT_PRINT_MAX_LEN 1024
+
+ static int bert_disable;
+
++/*
++ * Print "all" the error records in the BERT table, but avoid huge spam to
++ * the console if the BIOS included oversize records, or too many records.
++ * Skipping some records here does not lose anything because the full
++ * data is available to user tools in:
++ * /sys/firmware/acpi/tables/data/BERT
++ */
+ static void __init bert_print_all(struct acpi_bert_region *region,
+ unsigned int region_len)
+ {
+ struct acpi_hest_generic_status *estatus =
+ (struct acpi_hest_generic_status *)region;
+ int remain = region_len;
++ int printed = 0, skipped = 0;
+ u32 estatus_len;
+
+ while (remain >= sizeof(struct acpi_bert_region)) {
+@@ -46,24 +56,26 @@ static void __init bert_print_all(struct
+ if (remain < estatus_len) {
+ pr_err(FW_BUG "Truncated status block (length: %u).\n",
+ estatus_len);
+- return;
++ break;
+ }
+
+ /* No more error records. */
+ if (!estatus->block_status)
+- return;
++ break;
+
+ if (cper_estatus_check(estatus)) {
+ pr_err(FW_BUG "Invalid error record.\n");
+- return;
++ break;
+ }
+
+- pr_info_once("Error records from previous boot:\n");
+- if (region_len < ACPI_BERT_PRINT_MAX_LEN)
++ if (estatus_len < ACPI_BERT_PRINT_MAX_LEN &&
++ printed < ACPI_BERT_PRINT_MAX_RECORDS) {
++ pr_info_once("Error records from previous boot:\n");
+ cper_estatus_print(KERN_INFO HW_ERR, estatus);
+- else
+- pr_info_once("Max print length exceeded, table data is available at:\n"
+- "/sys/firmware/acpi/tables/data/BERT");
++ printed++;
++ } else {
++ skipped++;
++ }
+
+ /*
+ * Because the boot error source is "one-time polled" type,
+@@ -75,6 +87,9 @@ static void __init bert_print_all(struct
+ estatus = (void *)estatus + estatus_len;
+ remain -= estatus_len;
+ }
++
++ if (skipped)
++ pr_info(HW_ERR "Skipped %d error records\n", skipped);
+ }
+
+ static int __init setup_bert_disable(char *str)
--- /dev/null
+From c752089f7cf5b5800c6ace4cdd1a8351ee78a598 Mon Sep 17 00:00:00 2001
+From: Werner Sembach <wse@tuxedocomputers.com>
+Date: Thu, 7 Jul 2022 20:09:52 +0200
+Subject: ACPI: video: Force backlight native for some TongFang devices
+
+From: Werner Sembach <wse@tuxedocomputers.com>
+
+commit c752089f7cf5b5800c6ace4cdd1a8351ee78a598 upstream.
+
+The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 Gen10,
+Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the Clevo
+NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2:
+They have a working native and video interface. However the default
+detection mechanism first registers the video interface before
+unregistering it again and switching to the native interface during boot.
+This results in a dangling SBIOS request for backlight change for some
+reason, causing the backlight to switch to ~2% once per boot on the first
+power cord connect or disconnect event. Setting the native interface
+explicitly circumvents this buggy behaviour by avoiding the unregistering
+process.
+
+Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
+Cc: All applicable <stable@vger.kernel.org>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/video_detect.c | 51 +++++++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 50 insertions(+), 1 deletion(-)
+
+--- a/drivers/acpi/video_detect.c
++++ b/drivers/acpi/video_detect.c
+@@ -484,7 +484,56 @@ static const struct dmi_system_id video_
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
+ },
+ },
+-
++ /*
++ * The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 Gen10,
++ * Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the Clevo
++ * NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description
++ * above.
++ */
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang PF5PU1G",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "PF5PU1G"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang PF4NU1F",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "PF4NU1F"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang PF4NU1F",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
++ DMI_MATCH(DMI_BOARD_NAME, "PULSE1401"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang PF5NU1G",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "PF5NU1G"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang PF5NU1G",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
++ DMI_MATCH(DMI_BOARD_NAME, "PULSE1501"),
++ },
++ },
++ {
++ .callback = video_detect_force_native,
++ .ident = "TongFang PF5LUXG",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"),
++ },
++ },
+ /*
+ * Desktops which falsely report a backlight and which our heuristics
+ * for this do not catch.
--- /dev/null
+From f0341e67b3782603737f7788e71bd3530012a4f4 Mon Sep 17 00:00:00 2001
+From: Werner Sembach <wse@tuxedocomputers.com>
+Date: Thu, 7 Jul 2022 20:09:53 +0200
+Subject: ACPI: video: Shortening quirk list by identifying Clevo by board_name only
+
+From: Werner Sembach <wse@tuxedocomputers.com>
+
+commit f0341e67b3782603737f7788e71bd3530012a4f4 upstream.
+
+Taking a recent change in the i8042 quirklist to this one: Clevo
+board_names are somewhat unique, and if not: The generic Board_-/Sys_Vendor
+string "Notebook" doesn't help much anyway. So identifying the devices just
+by the board_name helps keeping the list significantly shorter and might
+even hit more devices requiring the fix.
+
+Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
+Fixes: c844d22fe0c0 ("ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU")
+Cc: All applicable <stable@vger.kernel.org>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/video_detect.c | 34 ----------------------------------
+ 1 file changed, 34 deletions(-)
+
+--- a/drivers/acpi/video_detect.c
++++ b/drivers/acpi/video_detect.c
+@@ -424,23 +424,6 @@ static const struct dmi_system_id video_
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xRU",
+ .matches = {
+- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
+- DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+- },
+- },
+- {
+- .callback = video_detect_force_native,
+- .ident = "Clevo NL5xRU",
+- .matches = {
+- DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
+- DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+- },
+- },
+- {
+- .callback = video_detect_force_native,
+- .ident = "Clevo NL5xRU",
+- .matches = {
+- DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+ },
+ },
+@@ -464,23 +447,6 @@ static const struct dmi_system_id video_
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xNU",
+ .matches = {
+- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
+- DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
+- },
+- },
+- {
+- .callback = video_detect_force_native,
+- .ident = "Clevo NL5xNU",
+- .matches = {
+- DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
+- DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
+- },
+- },
+- {
+- .callback = video_detect_force_native,
+- .ident = "Clevo NL5xNU",
+- .matches = {
+- DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
+ },
+ },
--- /dev/null
+From 7ae19d422c7da84b5f13bc08b98bd737a08d3a53 Mon Sep 17 00:00:00 2001
+From: GUO Zihua <guozihua@huawei.com>
+Date: Fri, 22 Jul 2022 14:31:57 +0800
+Subject: crypto: arm64/poly1305 - fix a read out-of-bound
+
+From: GUO Zihua <guozihua@huawei.com>
+
+commit 7ae19d422c7da84b5f13bc08b98bd737a08d3a53 upstream.
+
+A kasan error was reported during fuzzing:
+
+BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
+Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715
+CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1
+Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019
+Call trace:
+ dump_backtrace+0x0/0x394
+ show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0x158/0x1e4 lib/dump_stack.c:118
+ print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387
+ __kasan_report+0xe0/0x140 mm/kasan/report.c:547
+ kasan_report+0x44/0xe0 mm/kasan/report.c:564
+ check_memory_region_inline mm/kasan/generic.c:187 [inline]
+ __asan_load4+0x94/0xd0 mm/kasan/generic.c:252
+ neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
+ neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]
+ neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]
+ crypto_shash_update crypto/shash.c:131 [inline]
+ shash_finup_unaligned+0x84/0x15c crypto/shash.c:179
+ crypto_shash_finup+0x8c/0x140 crypto/shash.c:193
+ shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201
+ crypto_shash_digest+0xa4/0xfc crypto/shash.c:217
+ crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229
+ essiv_skcipher_setkey+0x164/0x200 [essiv]
+ crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612
+ skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305
+ alg_setkey+0x114/0x2a0 crypto/af_alg.c:220
+ alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253
+ __sys_setsockopt+0x190/0x2e0 net/socket.c:2123
+ __do_sys_setsockopt net/socket.c:2134 [inline]
+ __se_sys_setsockopt net/socket.c:2131 [inline]
+ __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
+ __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
+ invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48
+ el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155
+ do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217
+ el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353
+ el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369
+ el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683
+
+This error can be reproduced by the following code compiled as ko on a
+system with kasan enabled:
+
+#include <linux/module.h>
+#include <linux/crypto.h>
+#include <crypto/hash.h>
+#include <crypto/poly1305.h>
+
+char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07"
+ "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
+ "\x10\x11\x12\x13\x14\x15\x16\x17"
+ "\x18\x19\x1a\x1b\x1c\x1d\x1e";
+
+int init(void)
+{
+ struct crypto_shash *tfm = NULL;
+ char *data = NULL, *out = NULL;
+
+ tfm = crypto_alloc_shash("poly1305", 0, 0);
+ data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL);
+ out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL);
+ memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
+ crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out);
+
+ kfree(data);
+ kfree(out);
+ return 0;
+}
+
+void deinit(void)
+{
+}
+
+module_init(init)
+module_exit(deinit)
+MODULE_LICENSE("GPL");
+
+The root cause of the bug sits in neon_poly1305_blocks. The logic
+neon_poly1305_blocks() performed is that if it was called with both s[]
+and r[] uninitialized, it will first try to initialize them with the
+data from the first "block" that it believed to be 32 bytes in length.
+First 16 bytes are used as the key and the next 16 bytes for s[]. This
+would lead to the aforementioned read out-of-bound. However, after
+calling poly1305_init_arch(), only 16 bytes were deducted from the input
+and s[] is initialized yet again with the following 16 bytes. The second
+initialization of s[] is certainly redundent which indicates that the
+first initialization should be for r[] only.
+
+This patch fixes the issue by calling poly1305_init_arm64() instead of
+poly1305_init_arch(). This is also the implementation for the same
+algorithm on arm platform.
+
+Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation")
+Cc: stable@vger.kernel.org
+Signed-off-by: GUO Zihua <guozihua@huawei.com>
+Reviewed-by: Eric Biggers <ebiggers@google.com>
+Acked-by: Will Deacon <will@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/crypto/poly1305-glue.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/crypto/poly1305-glue.c
++++ b/arch/arm64/crypto/poly1305-glue.c
+@@ -52,7 +52,7 @@ static void neon_poly1305_blocks(struct
+ {
+ if (unlikely(!dctx->sset)) {
+ if (!dctx->rset) {
+- poly1305_init_arch(dctx, src);
++ poly1305_init_arm64(&dctx->h, src);
+ src += POLY1305_BLOCK_SIZE;
+ len -= POLY1305_BLOCK_SIZE;
+ dctx->rset = 1;
selftests-bpf-extend-verifier-and-bpf_sock-tests-for-dst_port-loads.patch
selftests-bpf-check-dst_port-only-on-the-client-socket.patch
block-fix-default-io-priority-handling-again.patch
+tools-vm-slabinfo-handle-files-in-debugfs.patch
+acpi-video-force-backlight-native-for-some-tongfang-devices.patch
+acpi-video-shortening-quirk-list-by-identifying-clevo-by-board_name-only.patch
+acpi-apei-better-fix-to-avoid-spamming-the-console-with-old-error-logs.patch
+crypto-arm64-poly1305-fix-a-read-out-of-bound.patch
--- /dev/null
+From 0c7e0d699ef1430d7f4cf12b4b1d097af58b5515 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?St=C3=A9phane=20Graber?= <stgraber@ubuntu.com>
+Date: Thu, 23 Jun 2022 16:45:52 -0500
+Subject: tools/vm/slabinfo: Handle files in debugfs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stéphane Graber <stgraber@ubuntu.com>
+
+commit 0c7e0d699ef1430d7f4cf12b4b1d097af58b5515 upstream.
+
+Commit 64dd68497be76 relocated and renamed the alloc_calls and
+free_calls files from /sys/kernel/slab/NAME/*_calls over to
+/sys/kernel/debug/slab/NAME/*_calls but didn't update the slabinfo tool
+with the new location.
+
+This change will now have slabinfo look at the new location (and filenames)
+with a fallback to the prior files.
+
+Fixes: 64dd68497be76 ("mm: slub: move sysfs slab alloc/free interfaces to debugfs")
+Cc: stable@vger.kernel.org
+Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
+Tested-by: Stéphane Graber <stgraber@ubuntu.com>
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/vm/slabinfo.c | 26 ++++++++++++++++++++++++--
+ 1 file changed, 24 insertions(+), 2 deletions(-)
+
+--- a/tools/vm/slabinfo.c
++++ b/tools/vm/slabinfo.c
+@@ -233,6 +233,24 @@ static unsigned long read_slab_obj(struc
+ return l;
+ }
+
++static unsigned long read_debug_slab_obj(struct slabinfo *s, const char *name)
++{
++ char x[128];
++ FILE *f;
++ size_t l;
++
++ snprintf(x, 128, "/sys/kernel/debug/slab/%s/%s", s->name, name);
++ f = fopen(x, "r");
++ if (!f) {
++ buffer[0] = 0;
++ l = 0;
++ } else {
++ l = fread(buffer, 1, sizeof(buffer), f);
++ buffer[l] = 0;
++ fclose(f);
++ }
++ return l;
++}
+
+ /*
+ * Put a size string together
+@@ -409,14 +427,18 @@ static void show_tracking(struct slabinf
+ {
+ printf("\n%s: Kernel object allocation\n", s->name);
+ printf("-----------------------------------------------------------------------\n");
+- if (read_slab_obj(s, "alloc_calls"))
++ if (read_debug_slab_obj(s, "alloc_traces"))
++ printf("%s", buffer);
++ else if (read_slab_obj(s, "alloc_calls"))
+ printf("%s", buffer);
+ else
+ printf("No Data\n");
+
+ printf("\n%s: Kernel object freeing\n", s->name);
+ printf("------------------------------------------------------------------------\n");
+- if (read_slab_obj(s, "free_calls"))
++ if (read_debug_slab_obj(s, "free_traces"))
++ printf("%s", buffer);
++ else if (read_slab_obj(s, "free_calls"))
+ printf("%s", buffer);
+ else
+ printf("No Data\n");