]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
5.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 15 Aug 2022 11:53:04 +0000 (13:53 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 15 Aug 2022 11:53:04 +0000 (13:53 +0200)
added patches:
acpi-cppc-do-not-prevent-cppc-from-working-in-the-future.patch
dm-raid-fix-address-sanitizer-warning-in-raid_resume.patch
dm-raid-fix-address-sanitizer-warning-in-raid_status.patch
dm-thin-fix-use-after-free-crash-in-dm_sm_register_threshold_callback.patch
dm-writecache-set-a-default-max_writeback_jobs.patch
firmware-arm_scpi-ensure-scpi_info-is-not-assigned-if-the-probe-fails.patch
intel_th-pci-add-meteor-lake-p-support.patch
intel_th-pci-add-raptor-lake-s-cpu-support.patch
intel_th-pci-add-raptor-lake-s-pch-support.patch
iommu-vt-d-avoid-invalid-memory-access-via-node_online-numa_no_node.patch
net_sched-cls_route-remove-from-list-when-handle-is-0.patch
timekeeping-contribute-wall-clock-to-rng-on-time-change.patch

13 files changed:
queue-5.4/acpi-cppc-do-not-prevent-cppc-from-working-in-the-future.patch [new file with mode: 0644]
queue-5.4/dm-raid-fix-address-sanitizer-warning-in-raid_resume.patch [new file with mode: 0644]
queue-5.4/dm-raid-fix-address-sanitizer-warning-in-raid_status.patch [new file with mode: 0644]
queue-5.4/dm-thin-fix-use-after-free-crash-in-dm_sm_register_threshold_callback.patch [new file with mode: 0644]
queue-5.4/dm-writecache-set-a-default-max_writeback_jobs.patch [new file with mode: 0644]
queue-5.4/firmware-arm_scpi-ensure-scpi_info-is-not-assigned-if-the-probe-fails.patch [new file with mode: 0644]
queue-5.4/intel_th-pci-add-meteor-lake-p-support.patch [new file with mode: 0644]
queue-5.4/intel_th-pci-add-raptor-lake-s-cpu-support.patch [new file with mode: 0644]
queue-5.4/intel_th-pci-add-raptor-lake-s-pch-support.patch [new file with mode: 0644]
queue-5.4/iommu-vt-d-avoid-invalid-memory-access-via-node_online-numa_no_node.patch [new file with mode: 0644]
queue-5.4/net_sched-cls_route-remove-from-list-when-handle-is-0.patch [new file with mode: 0644]
queue-5.4/series
queue-5.4/timekeeping-contribute-wall-clock-to-rng-on-time-change.patch [new file with mode: 0644]

diff --git a/queue-5.4/acpi-cppc-do-not-prevent-cppc-from-working-in-the-future.patch b/queue-5.4/acpi-cppc-do-not-prevent-cppc-from-working-in-the-future.patch
new file mode 100644 (file)
index 0000000..143d530
--- /dev/null
@@ -0,0 +1,124 @@
+From 4f4179fcf420873002035cf1941d844c9e0e7cb3 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Thu, 21 Jul 2022 19:41:10 +0200
+Subject: ACPI: CPPC: Do not prevent CPPC from working in the future
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 4f4179fcf420873002035cf1941d844c9e0e7cb3 upstream.
+
+There is a problem with the current revision checks in
+is_cppc_supported() that they essentially prevent the CPPC support
+from working if a new _CPC package format revision being a proper
+superset of the v3 and only causing _CPC to return a package with more
+entries (while retaining the types and meaning of the entries defined by
+the v3) is introduced in the future and used by the platform firmware.
+
+In that case, as long as the number of entries in the _CPC return
+package is at least CPPC_V3_NUM_ENT, it should be perfectly fine to
+use the v3 support code and disregard the additional package entries
+added by the new package format revision.
+
+For this reason, drop is_cppc_supported() altogether, put the revision
+checks directly into acpi_cppc_processor_probe() so they are easier to
+follow and rework them to take the case mentioned above into account.
+
+Fixes: 4773e77cdc9b ("ACPI / CPPC: Add support for CPPC v3")
+Cc: 4.18+ <stable@vger.kernel.org> # 4.18+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/cppc_acpi.c |   54 ++++++++++++++++++++---------------------------
+ include/acpi/cppc_acpi.h |    2 -
+ 2 files changed, 25 insertions(+), 31 deletions(-)
+
+--- a/drivers/acpi/cppc_acpi.c
++++ b/drivers/acpi/cppc_acpi.c
+@@ -626,33 +626,6 @@ int pcc_data_alloc(int pcc_ss_id)
+       return 0;
+ }
+-/* Check if CPPC revision + num_ent combination is supported */
+-static bool is_cppc_supported(int revision, int num_ent)
+-{
+-      int expected_num_ent;
+-
+-      switch (revision) {
+-      case CPPC_V2_REV:
+-              expected_num_ent = CPPC_V2_NUM_ENT;
+-              break;
+-      case CPPC_V3_REV:
+-              expected_num_ent = CPPC_V3_NUM_ENT;
+-              break;
+-      default:
+-              pr_debug("Firmware exports unsupported CPPC revision: %d\n",
+-                      revision);
+-              return false;
+-      }
+-
+-      if (expected_num_ent != num_ent) {
+-              pr_debug("Firmware exports %d entries. Expected: %d for CPPC rev:%d\n",
+-                      num_ent, expected_num_ent, revision);
+-              return false;
+-      }
+-
+-      return true;
+-}
+-
+ /*
+  * An example CPC table looks like the following.
+  *
+@@ -748,7 +721,6 @@ int acpi_cppc_processor_probe(struct acp
+                               cpc_obj->type);
+               goto out_free;
+       }
+-      cpc_ptr->num_entries = num_ent;
+       /* Second entry should be revision. */
+       cpc_obj = &out_obj->package.elements[1];
+@@ -759,10 +731,32 @@ int acpi_cppc_processor_probe(struct acp
+                               cpc_obj->type);
+               goto out_free;
+       }
+-      cpc_ptr->version = cpc_rev;
+-      if (!is_cppc_supported(cpc_rev, num_ent))
++      if (cpc_rev < CPPC_V2_REV) {
++              pr_debug("Unsupported _CPC Revision (%d) for CPU:%d\n", cpc_rev,
++                       pr->id);
+               goto out_free;
++      }
++
++      /*
++       * Disregard _CPC if the number of entries in the return pachage is not
++       * as expected, but support future revisions being proper supersets of
++       * the v3 and only causing more entries to be returned by _CPC.
++       */
++      if ((cpc_rev == CPPC_V2_REV && num_ent != CPPC_V2_NUM_ENT) ||
++          (cpc_rev == CPPC_V3_REV && num_ent != CPPC_V3_NUM_ENT) ||
++          (cpc_rev > CPPC_V3_REV && num_ent <= CPPC_V3_NUM_ENT)) {
++              pr_debug("Unexpected number of _CPC return package entries (%d) for CPU:%d\n",
++                       num_ent, pr->id);
++              goto out_free;
++      }
++      if (cpc_rev > CPPC_V3_REV) {
++              num_ent = CPPC_V3_NUM_ENT;
++              cpc_rev = CPPC_V3_REV;
++      }
++
++      cpc_ptr->num_entries = num_ent;
++      cpc_ptr->version = cpc_rev;
+       /* Iterate through remaining entries in _CPC */
+       for (i = 2; i < num_ent; i++) {
+--- a/include/acpi/cppc_acpi.h
++++ b/include/acpi/cppc_acpi.h
+@@ -16,7 +16,7 @@
+ #include <acpi/pcc.h>
+ #include <acpi/processor.h>
+-/* Support CPPCv2 and CPPCv3  */
++/* CPPCv2 and CPPCv3 support */
+ #define CPPC_V2_REV   2
+ #define CPPC_V3_REV   3
+ #define CPPC_V2_NUM_ENT       21
diff --git a/queue-5.4/dm-raid-fix-address-sanitizer-warning-in-raid_resume.patch b/queue-5.4/dm-raid-fix-address-sanitizer-warning-in-raid_resume.patch
new file mode 100644 (file)
index 0000000..8f4748e
--- /dev/null
@@ -0,0 +1,33 @@
+From 7dad24db59d2d2803576f2e3645728866a056dab Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Sun, 24 Jul 2022 14:33:52 -0400
+Subject: dm raid: fix address sanitizer warning in raid_resume
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 7dad24db59d2d2803576f2e3645728866a056dab upstream.
+
+There is a KASAN warning in raid_resume when running the lvm test
+lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks
+is greater than rs->raid_disks, so the loop touches one entry beyond
+the allocated length.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-raid.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/dm-raid.c
++++ b/drivers/md/dm-raid.c
+@@ -3808,7 +3808,7 @@ static void attempt_restore_of_faulty_de
+       memset(cleared_failed_devices, 0, sizeof(cleared_failed_devices));
+-      for (i = 0; i < mddev->raid_disks; i++) {
++      for (i = 0; i < rs->raid_disks; i++) {
+               r = &rs->dev[i].rdev;
+               /* HM FIXME: enhance journal device recovery processing */
+               if (test_bit(Journal, &r->flags))
diff --git a/queue-5.4/dm-raid-fix-address-sanitizer-warning-in-raid_status.patch b/queue-5.4/dm-raid-fix-address-sanitizer-warning-in-raid_status.patch
new file mode 100644 (file)
index 0000000..453ff8f
--- /dev/null
@@ -0,0 +1,63 @@
+From 1fbeea217d8f297fe0e0956a1516d14ba97d0396 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Sun, 24 Jul 2022 14:31:35 -0400
+Subject: dm raid: fix address sanitizer warning in raid_status
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 1fbeea217d8f297fe0e0956a1516d14ba97d0396 upstream.
+
+There is this warning when using a kernel with the address sanitizer
+and running this testsuite:
+https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid
+
+==================================================================
+BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]
+Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319
+CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1
+Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x6a/0x9c
+ print_address_description.constprop.0+0x1f/0x1e0
+ print_report.cold+0x55/0x244
+ kasan_report+0xc9/0x100
+ raid_status+0x1747/0x2820 [dm_raid]
+ dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod]
+ table_load+0x35c/0x630 [dm_mod]
+ ctl_ioctl+0x411/0x630 [dm_mod]
+ dm_ctl_ioctl+0xa/0x10 [dm_mod]
+ __x64_sys_ioctl+0x12a/0x1a0
+ do_syscall_64+0x5b/0x80
+
+The warning is caused by reading conf->max_nr_stripes in raid_status. The
+code in raid_status reads mddev->private, casts it to struct r5conf and
+reads the entry max_nr_stripes.
+
+However, if we have different raid type than 4/5/6, mddev->private
+doesn't point to struct r5conf; it may point to struct r0conf, struct
+r1conf, struct r10conf or struct mpconf. If we cast a pointer to one
+of these structs to struct r5conf, we will be reading invalid memory
+and KASAN warns about it.
+
+Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-raid.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/dm-raid.c
++++ b/drivers/md/dm-raid.c
+@@ -3528,7 +3528,7 @@ static void raid_status(struct dm_target
+ {
+       struct raid_set *rs = ti->private;
+       struct mddev *mddev = &rs->md;
+-      struct r5conf *conf = mddev->private;
++      struct r5conf *conf = rs_is_raid456(rs) ? mddev->private : NULL;
+       int i, max_nr_stripes = conf ? conf->max_nr_stripes : 0;
+       unsigned long recovery;
+       unsigned int raid_param_cnt = 1; /* at least 1 for chunksize */
diff --git a/queue-5.4/dm-thin-fix-use-after-free-crash-in-dm_sm_register_threshold_callback.patch b/queue-5.4/dm-thin-fix-use-after-free-crash-in-dm_sm_register_threshold_callback.patch
new file mode 100644 (file)
index 0000000..552116f
--- /dev/null
@@ -0,0 +1,88 @@
+From 3534e5a5ed2997ca1b00f44a0378a075bd05e8a3 Mon Sep 17 00:00:00 2001
+From: Luo Meng <luomeng12@huawei.com>
+Date: Thu, 14 Jul 2022 19:28:25 +0800
+Subject: dm thin: fix use-after-free crash in dm_sm_register_threshold_callback
+
+From: Luo Meng <luomeng12@huawei.com>
+
+commit 3534e5a5ed2997ca1b00f44a0378a075bd05e8a3 upstream.
+
+Fault inject on pool metadata device reports:
+  BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80
+  Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950
+
+  CPU: 7 PID: 950 Comm: dmsetup Tainted: G        W         5.19.0-rc6 #1
+  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
+  Call Trace:
+   <TASK>
+   dump_stack_lvl+0x34/0x44
+   print_address_description.constprop.0.cold+0xeb/0x3f4
+   kasan_report.cold+0xe6/0x147
+   dm_pool_register_metadata_threshold+0x40/0x80
+   pool_ctr+0xa0a/0x1150
+   dm_table_add_target+0x2c8/0x640
+   table_load+0x1fd/0x430
+   ctl_ioctl+0x2c4/0x5a0
+   dm_ctl_ioctl+0xa/0x10
+   __x64_sys_ioctl+0xb3/0xd0
+   do_syscall_64+0x35/0x80
+   entry_SYSCALL_64_after_hwframe+0x46/0xb0
+
+This can be easily reproduced using:
+  echo offline > /sys/block/sda/device/state
+  dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10
+  dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0"
+
+If a metadata commit fails, the transaction will be aborted and the
+metadata space maps will be destroyed. If a DM table reload then
+happens for this failed thin-pool, a use-after-free will occur in
+dm_sm_register_threshold_callback (called from
+dm_pool_register_metadata_threshold).
+
+Fix this by in dm_pool_register_metadata_threshold() by returning the
+-EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr()
+with a new error message: "Error registering metadata threshold".
+
+Fixes: ac8c3f3df65e4 ("dm thin: generate event when metadata threshold passed")
+Cc: stable@vger.kernel.org
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Luo Meng <luomeng12@huawei.com>
+Signed-off-by: Mike Snitzer <snitzer@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-thin-metadata.c |    7 +++++--
+ drivers/md/dm-thin.c          |    4 +++-
+ 2 files changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/dm-thin-metadata.c
++++ b/drivers/md/dm-thin-metadata.c
+@@ -2060,10 +2060,13 @@ int dm_pool_register_metadata_threshold(
+                                       dm_sm_threshold_fn fn,
+                                       void *context)
+ {
+-      int r;
++      int r = -EINVAL;
+       pmd_write_lock_in_core(pmd);
+-      r = dm_sm_register_threshold_callback(pmd->metadata_sm, threshold, fn, context);
++      if (!pmd->fail_io) {
++              r = dm_sm_register_threshold_callback(pmd->metadata_sm,
++                                                    threshold, fn, context);
++      }
+       pmd_write_unlock(pmd);
+       return r;
+--- a/drivers/md/dm-thin.c
++++ b/drivers/md/dm-thin.c
+@@ -3425,8 +3425,10 @@ static int pool_ctr(struct dm_target *ti
+                                               calc_metadata_threshold(pt),
+                                               metadata_low_callback,
+                                               pool);
+-      if (r)
++      if (r) {
++              ti->error = "Error registering metadata threshold";
+               goto out_flags_changed;
++      }
+       pt->callbacks.congested_fn = pool_is_congested;
+       dm_table_add_target_callbacks(ti->table, &pt->callbacks);
diff --git a/queue-5.4/dm-writecache-set-a-default-max_writeback_jobs.patch b/queue-5.4/dm-writecache-set-a-default-max_writeback_jobs.patch
new file mode 100644 (file)
index 0000000..e7d7fab
--- /dev/null
@@ -0,0 +1,36 @@
+From ca7dc242e358e46d963b32f9d9dd829785a9e957 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Wed, 13 Jul 2022 07:09:04 -0400
+Subject: dm writecache: set a default MAX_WRITEBACK_JOBS
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit ca7dc242e358e46d963b32f9d9dd829785a9e957 upstream.
+
+dm-writecache has the capability to limit the number of writeback jobs
+in progress. However, this feature was off by default. As such there
+were some out-of-memory crashes observed when lowering the low
+watermark while the cache is full.
+
+This commit enables writeback limit by default. It is set to 256MiB or
+1/16 of total system memory, whichever is smaller.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-writecache.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/dm-writecache.c
++++ b/drivers/md/dm-writecache.c
+@@ -20,7 +20,7 @@
+ #define HIGH_WATERMARK                        50
+ #define LOW_WATERMARK                 45
+-#define MAX_WRITEBACK_JOBS            0
++#define MAX_WRITEBACK_JOBS            min(0x10000000 / PAGE_SIZE, totalram_pages() / 16)
+ #define ENDIO_LATENCY                 16
+ #define WRITEBACK_LATENCY             64
+ #define AUTOCOMMIT_BLOCKS_SSD         65536
diff --git a/queue-5.4/firmware-arm_scpi-ensure-scpi_info-is-not-assigned-if-the-probe-fails.patch b/queue-5.4/firmware-arm_scpi-ensure-scpi_info-is-not-assigned-if-the-probe-fails.patch
new file mode 100644 (file)
index 0000000..bc14c2e
--- /dev/null
@@ -0,0 +1,150 @@
+From 689640efc0a2c4e07e6f88affe6d42cd40cc3f85 Mon Sep 17 00:00:00 2001
+From: Sudeep Holla <sudeep.holla@arm.com>
+Date: Fri, 1 Jul 2022 17:03:10 +0100
+Subject: firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails
+
+From: Sudeep Holla <sudeep.holla@arm.com>
+
+commit 689640efc0a2c4e07e6f88affe6d42cd40cc3f85 upstream.
+
+When scpi probe fails, at any point, we need to ensure that the scpi_info
+is not set and will remain NULL until the probe succeeds. If it is not
+taken care, then it could result use-after-free as the value is exported
+via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()
+but freed when the probe fails.
+
+Link: https://lore.kernel.org/r/20220701160310.148344-1-sudeep.holla@arm.com
+Cc: stable@vger.kernel.org # 4.19+
+Reported-by: huhai <huhai@kylinos.cn>
+Reviewed-by: Jackie Liu <liuyun01@kylinos.cn>
+Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/arm_scpi.c |   61 +++++++++++++++++++++++++-------------------
+ 1 file changed, 35 insertions(+), 26 deletions(-)
+
+--- a/drivers/firmware/arm_scpi.c
++++ b/drivers/firmware/arm_scpi.c
+@@ -815,7 +815,7 @@ static int scpi_init_versions(struct scp
+               info->firmware_version = le32_to_cpu(caps.platform_version);
+       }
+       /* Ignore error if not implemented */
+-      if (scpi_info->is_legacy && ret == -EOPNOTSUPP)
++      if (info->is_legacy && ret == -EOPNOTSUPP)
+               return 0;
+       return ret;
+@@ -905,13 +905,14 @@ static int scpi_probe(struct platform_de
+       struct resource res;
+       struct device *dev = &pdev->dev;
+       struct device_node *np = dev->of_node;
++      struct scpi_drvinfo *scpi_drvinfo;
+-      scpi_info = devm_kzalloc(dev, sizeof(*scpi_info), GFP_KERNEL);
+-      if (!scpi_info)
++      scpi_drvinfo = devm_kzalloc(dev, sizeof(*scpi_drvinfo), GFP_KERNEL);
++      if (!scpi_drvinfo)
+               return -ENOMEM;
+       if (of_match_device(legacy_scpi_of_match, &pdev->dev))
+-              scpi_info->is_legacy = true;
++              scpi_drvinfo->is_legacy = true;
+       count = of_count_phandle_with_args(np, "mboxes", "#mbox-cells");
+       if (count < 0) {
+@@ -919,19 +920,19 @@ static int scpi_probe(struct platform_de
+               return -ENODEV;
+       }
+-      scpi_info->channels = devm_kcalloc(dev, count, sizeof(struct scpi_chan),
+-                                         GFP_KERNEL);
+-      if (!scpi_info->channels)
++      scpi_drvinfo->channels =
++              devm_kcalloc(dev, count, sizeof(struct scpi_chan), GFP_KERNEL);
++      if (!scpi_drvinfo->channels)
+               return -ENOMEM;
+-      ret = devm_add_action(dev, scpi_free_channels, scpi_info);
++      ret = devm_add_action(dev, scpi_free_channels, scpi_drvinfo);
+       if (ret)
+               return ret;
+-      for (; scpi_info->num_chans < count; scpi_info->num_chans++) {
++      for (; scpi_drvinfo->num_chans < count; scpi_drvinfo->num_chans++) {
+               resource_size_t size;
+-              int idx = scpi_info->num_chans;
+-              struct scpi_chan *pchan = scpi_info->channels + idx;
++              int idx = scpi_drvinfo->num_chans;
++              struct scpi_chan *pchan = scpi_drvinfo->channels + idx;
+               struct mbox_client *cl = &pchan->cl;
+               struct device_node *shmem = of_parse_phandle(np, "shmem", idx);
+@@ -975,45 +976,53 @@ static int scpi_probe(struct platform_de
+               return ret;
+       }
+-      scpi_info->commands = scpi_std_commands;
++      scpi_drvinfo->commands = scpi_std_commands;
+-      platform_set_drvdata(pdev, scpi_info);
++      platform_set_drvdata(pdev, scpi_drvinfo);
+-      if (scpi_info->is_legacy) {
++      if (scpi_drvinfo->is_legacy) {
+               /* Replace with legacy variants */
+               scpi_ops.clk_set_val = legacy_scpi_clk_set_val;
+-              scpi_info->commands = scpi_legacy_commands;
++              scpi_drvinfo->commands = scpi_legacy_commands;
+               /* Fill priority bitmap */
+               for (idx = 0; idx < ARRAY_SIZE(legacy_hpriority_cmds); idx++)
+                       set_bit(legacy_hpriority_cmds[idx],
+-                              scpi_info->cmd_priority);
++                              scpi_drvinfo->cmd_priority);
+       }
+-      ret = scpi_init_versions(scpi_info);
++      scpi_info = scpi_drvinfo;
++
++      ret = scpi_init_versions(scpi_drvinfo);
+       if (ret) {
+               dev_err(dev, "incorrect or no SCP firmware found\n");
++              scpi_info = NULL;
+               return ret;
+       }
+-      if (scpi_info->is_legacy && !scpi_info->protocol_version &&
+-          !scpi_info->firmware_version)
++      if (scpi_drvinfo->is_legacy && !scpi_drvinfo->protocol_version &&
++          !scpi_drvinfo->firmware_version)
+               dev_info(dev, "SCP Protocol legacy pre-1.0 firmware\n");
+       else
+               dev_info(dev, "SCP Protocol %lu.%lu Firmware %lu.%lu.%lu version\n",
+                        FIELD_GET(PROTO_REV_MAJOR_MASK,
+-                                 scpi_info->protocol_version),
++                                 scpi_drvinfo->protocol_version),
+                        FIELD_GET(PROTO_REV_MINOR_MASK,
+-                                 scpi_info->protocol_version),
++                                 scpi_drvinfo->protocol_version),
+                        FIELD_GET(FW_REV_MAJOR_MASK,
+-                                 scpi_info->firmware_version),
++                                 scpi_drvinfo->firmware_version),
+                        FIELD_GET(FW_REV_MINOR_MASK,
+-                                 scpi_info->firmware_version),
++                                 scpi_drvinfo->firmware_version),
+                        FIELD_GET(FW_REV_PATCH_MASK,
+-                                 scpi_info->firmware_version));
+-      scpi_info->scpi_ops = &scpi_ops;
++                                 scpi_drvinfo->firmware_version));
++
++      scpi_drvinfo->scpi_ops = &scpi_ops;
+-      return devm_of_platform_populate(dev);
++      ret = devm_of_platform_populate(dev);
++      if (ret)
++              scpi_info = NULL;
++
++      return ret;
+ }
+ static const struct of_device_id scpi_of_match[] = {
diff --git a/queue-5.4/intel_th-pci-add-meteor-lake-p-support.patch b/queue-5.4/intel_th-pci-add-meteor-lake-p-support.patch
new file mode 100644 (file)
index 0000000..b582ade
--- /dev/null
@@ -0,0 +1,34 @@
+From 802a9a0b1d91274ef10d9fe429b4cc1e8c200aef Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 5 Jul 2022 11:26:35 +0300
+Subject: intel_th: pci: Add Meteor Lake-P support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 802a9a0b1d91274ef10d9fe429b4cc1e8c200aef upstream.
+
+Add support for the Trace Hub in Meteor Lake-P.
+
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable <stable@kernel.org>
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Link: https://lore.kernel.org/r/20220705082637.59979-5-alexander.shishkin@linux.intel.com
+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
+@@ -285,6 +285,11 @@ static const struct pci_device_id intel_
+               .driver_data = (kernel_ulong_t)&intel_th_2x,
+       },
+       {
++              /* Meteor Lake-P */
++              PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x7e24),
++              .driver_data = (kernel_ulong_t)&intel_th_2x,
++      },
++      {
+               /* Raptor Lake-S */
+               PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x7a26),
+               .driver_data = (kernel_ulong_t)&intel_th_2x,
diff --git a/queue-5.4/intel_th-pci-add-raptor-lake-s-cpu-support.patch b/queue-5.4/intel_th-pci-add-raptor-lake-s-cpu-support.patch
new file mode 100644 (file)
index 0000000..ef04694
--- /dev/null
@@ -0,0 +1,34 @@
+From ff46a601afc5a66a81c3945b83d0a2caeb88e8bc Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 5 Jul 2022 11:26:37 +0300
+Subject: intel_th: pci: Add Raptor Lake-S CPU support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit ff46a601afc5a66a81c3945b83d0a2caeb88e8bc upstream.
+
+Add support for the Trace Hub in Raptor Lake-S CPU.
+
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable <stable@kernel.org>
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Link: https://lore.kernel.org/r/20220705082637.59979-7-alexander.shishkin@linux.intel.com
+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
+@@ -280,6 +280,11 @@ static const struct pci_device_id intel_
+               .driver_data = (kernel_ulong_t)&intel_th_2x,
+       },
+       {
++              /* Raptor Lake-S CPU */
++              PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa76f),
++              .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,
diff --git a/queue-5.4/intel_th-pci-add-raptor-lake-s-pch-support.patch b/queue-5.4/intel_th-pci-add-raptor-lake-s-pch-support.patch
new file mode 100644 (file)
index 0000000..fdeb878
--- /dev/null
@@ -0,0 +1,34 @@
+From 23e2de5826e2fc4dd43e08bab3a2ea1a5338b063 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 5 Jul 2022 11:26:36 +0300
+Subject: intel_th: pci: Add Raptor Lake-S PCH support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 23e2de5826e2fc4dd43e08bab3a2ea1a5338b063 upstream.
+
+Add support for the Trace Hub in Raptor Lake-S PCH.
+
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable <stable@kernel.org>
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Link: https://lore.kernel.org/r/20220705082637.59979-6-alexander.shishkin@linux.intel.com
+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
+@@ -285,6 +285,11 @@ static const struct pci_device_id intel_
+               .driver_data = (kernel_ulong_t)&intel_th_2x,
+       },
+       {
++              /* Raptor Lake-S */
++              PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x7a26),
++              .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,
diff --git a/queue-5.4/iommu-vt-d-avoid-invalid-memory-access-via-node_online-numa_no_node.patch b/queue-5.4/iommu-vt-d-avoid-invalid-memory-access-via-node_online-numa_no_node.patch
new file mode 100644 (file)
index 0000000..b8cfae7
--- /dev/null
@@ -0,0 +1,61 @@
+From b0b0b77ea611e3088e9523e60860f4f41b62b235 Mon Sep 17 00:00:00 2001
+From: Alexander Lobakin <alexandr.lobakin@intel.com>
+Date: Tue, 12 Jul 2022 17:38:36 +0200
+Subject: iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)
+
+From: Alexander Lobakin <alexandr.lobakin@intel.com>
+
+commit b0b0b77ea611e3088e9523e60860f4f41b62b235 upstream.
+
+KASAN reports:
+
+[ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
+[    4.676149][    T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0
+[    4.683454][    T0]
+[    4.685638][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1
+[    4.694331][    T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016
+[    4.703196][    T0] Call Trace:
+[    4.706334][    T0]  <TASK>
+[ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
+
+after converting the type of the first argument (@nr, bit number)
+of arch_test_bit() from `long` to `unsigned long`[0].
+
+Under certain conditions (for example, when ACPI NUMA is disabled
+via command line), pxm_to_node() can return %NUMA_NO_NODE (-1).
+It is valid 'magic' number of NUMA node, but not valid bit number
+to use in bitops.
+node_online() eventually descends to test_bit() without checking
+for the input, assuming it's on caller side (which might be good
+for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads
+to an insane array index when calculating bit position in memory.
+
+For now, add an explicit check for @node being not %NUMA_NO_NODE
+before calling test_bit(). The actual logics didn't change here
+at all.
+
+[0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d
+
+Fixes: ee34b32d8c29 ("dmar: support for parsing Remapping Hardware Static Affinity structure")
+Cc: stable@vger.kernel.org # 2.6.33+
+Reported-by: kernel test robot <oliver.sang@intel.com>
+Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Yury Norov <yury.norov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/dmar.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iommu/dmar.c
++++ b/drivers/iommu/dmar.c
+@@ -475,7 +475,7 @@ static int dmar_parse_one_rhsa(struct ac
+               if (drhd->reg_base_addr == rhsa->base_address) {
+                       int node = acpi_map_pxm_to_node(rhsa->proximity_domain);
+-                      if (!node_online(node))
++                      if (node != NUMA_NO_NODE && !node_online(node))
+                               node = NUMA_NO_NODE;
+                       drhd->iommu->node = node;
+                       return 0;
diff --git a/queue-5.4/net_sched-cls_route-remove-from-list-when-handle-is-0.patch b/queue-5.4/net_sched-cls_route-remove-from-list-when-handle-is-0.patch
new file mode 100644 (file)
index 0000000..e4c2708
--- /dev/null
@@ -0,0 +1,45 @@
+From 9ad36309e2719a884f946678e0296be10f0bb4c1 Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+Date: Tue, 9 Aug 2022 14:05:18 -0300
+Subject: net_sched: cls_route: remove from list when handle is 0
+
+From: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+
+commit 9ad36309e2719a884f946678e0296be10f0bb4c1 upstream.
+
+When a route filter is replaced and the old filter has a 0 handle, the old
+one won't be removed from the hashtable, while it will still be freed.
+
+The test was there since before commit 1109c00547fc ("net: sched: RCU
+cls_route"), when a new filter was not allocated when there was an old one.
+The old filter was reused and the reinserting would only be necessary if an
+old filter was replaced. That was still wrong for the same case where the
+old handle was 0.
+
+Remove the old filter from the list independently from its handle value.
+
+This fixes CVE-2022-2588, also reported as ZDI-CAN-17440.
+
+Reported-by: Zhenpeng Lin <zplin@u.northwestern.edu>
+Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
+Reviewed-by: Kamal Mostafa <kamal@canonical.com>
+Cc: <stable@vger.kernel.org>
+Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
+Link: https://lore.kernel.org/r/20220809170518.164662-1-cascardo@canonical.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/cls_route.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/sched/cls_route.c
++++ b/net/sched/cls_route.c
+@@ -526,7 +526,7 @@ static int route4_change(struct net *net
+       rcu_assign_pointer(f->next, f1);
+       rcu_assign_pointer(*fp, f);
+-      if (fold && fold->handle && f->handle != fold->handle) {
++      if (fold) {
+               th = to_hash(fold->handle);
+               h = from_hash(fold->handle >> 16);
+               b = rtnl_dereference(head->table[th]);
index b6bbf7510ddf67cc8524aaa029544d6654106377..fbdba6a7d51507fc8b2324ead5febb7354a7e59c 100644 (file)
@@ -266,3 +266,15 @@ ext4-update-s_overhead_clusters-in-the-superblock-during-an-on-line-resize.patch
 ext4-fix-extent-status-tree-race-in-writeback-error-recovery-path.patch
 ext4-correct-max_inline_xattr_value_size-computing.patch
 ext4-correct-the-misjudgment-in-ext4_iget_extra_inode.patch
+intel_th-pci-add-raptor-lake-s-cpu-support.patch
+intel_th-pci-add-raptor-lake-s-pch-support.patch
+intel_th-pci-add-meteor-lake-p-support.patch
+dm-raid-fix-address-sanitizer-warning-in-raid_resume.patch
+dm-raid-fix-address-sanitizer-warning-in-raid_status.patch
+dm-thin-fix-use-after-free-crash-in-dm_sm_register_threshold_callback.patch
+dm-writecache-set-a-default-max_writeback_jobs.patch
+acpi-cppc-do-not-prevent-cppc-from-working-in-the-future.patch
+timekeeping-contribute-wall-clock-to-rng-on-time-change.patch
+firmware-arm_scpi-ensure-scpi_info-is-not-assigned-if-the-probe-fails.patch
+iommu-vt-d-avoid-invalid-memory-access-via-node_online-numa_no_node.patch
+net_sched-cls_route-remove-from-list-when-handle-is-0.patch
diff --git a/queue-5.4/timekeeping-contribute-wall-clock-to-rng-on-time-change.patch b/queue-5.4/timekeeping-contribute-wall-clock-to-rng-on-time-change.patch
new file mode 100644 (file)
index 0000000..7efcf30
--- /dev/null
@@ -0,0 +1,69 @@
+From b8ac29b40183a6038919768b5d189c9bd91ce9b4 Mon Sep 17 00:00:00 2001
+From: "Jason A. Donenfeld" <Jason@zx2c4.com>
+Date: Sun, 17 Jul 2022 23:53:34 +0200
+Subject: timekeeping: contribute wall clock to rng on time change
+
+From: Jason A. Donenfeld <Jason@zx2c4.com>
+
+commit b8ac29b40183a6038919768b5d189c9bd91ce9b4 upstream.
+
+The rng's random_init() function contributes the real time to the rng at
+boot time, so that events can at least start in relation to something
+particular in the real world. But this clock might not yet be set that
+point in boot, so nothing is contributed. In addition, the relation
+between minor clock changes from, say, NTP, and the cycle counter is
+potentially useful entropic data.
+
+This commit addresses this by mixing in a time stamp on calls to
+settimeofday and adjtimex. No entropy is credited in doing so, so it
+doesn't make initialization faster, but it is still useful input to
+have.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/time/timekeeping.c |    7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/kernel/time/timekeeping.c
++++ b/kernel/time/timekeeping.c
+@@ -23,6 +23,7 @@
+ #include <linux/pvclock_gtod.h>
+ #include <linux/compiler.h>
+ #include <linux/audit.h>
++#include <linux/random.h>
+ #include "tick-internal.h"
+ #include "ntp_internal.h"
+@@ -1256,8 +1257,10 @@ out:
+       /* signal hrtimers about time change */
+       clock_was_set();
+-      if (!ret)
++      if (!ret) {
+               audit_tk_injoffset(ts_delta);
++              add_device_randomness(ts, sizeof(*ts));
++      }
+       return ret;
+ }
+@@ -2336,6 +2339,7 @@ int do_adjtimex(struct __kernel_timex *t
+       ret = timekeeping_validate_timex(txc);
+       if (ret)
+               return ret;
++      add_device_randomness(txc, sizeof(*txc));
+       if (txc->modes & ADJ_SETOFFSET) {
+               struct timespec64 delta;
+@@ -2353,6 +2357,7 @@ int do_adjtimex(struct __kernel_timex *t
+       audit_ntp_init(&ad);
+       ktime_get_real_ts64(&ts);
++      add_device_randomness(&ts, sizeof(ts));
+       raw_spin_lock_irqsave(&timekeeper_lock, flags);
+       write_seqcount_begin(&tk_core.seq);