From: Greg Kroah-Hartman Date: Sat, 4 Dec 2021 10:48:16 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v4.4.294~45 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=149c2f6ccda8f2243c45e2f2969831d6e0e25d19;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: alsa-hda-cs8409-set-pmsg_on-earlier-inside-cs8409-driver.patch cpufreq-fix-get_cpu_device-failure-in-add_cpu_dev_symlink.patch dma-buf-system_heap-use-for_each_sgtable_sg-in-pages-free-flow.patch fget-check-that-the-fd-still-exists-after-getting-a-ref-to-it.patch ipmi-move-remove_work-to-dedicated-workqueue.patch iwlwifi-mvm-retry-init-flow-if-failed.patch kprobes-limit-max-data_size-of-the-kretprobe-instances.patch net-tls-fix-authentication-failure-in-ccm-mode.patch rt2x00-do-not-mark-device-gone-on-eproto-errors-during-start.patch s390-pci-move-pseudo-mmio-to-prevent-mio-overlap.patch sata_fsl-fix-uaf-in-sata_fsl_port_stop-when-rmmod-sata_fsl.patch sata_fsl-fix-warning-in-remove_proc_entry-when-rmmod-sata_fsl.patch vrf-reset-ipcb-ip6cb-when-processing-outbound-pkts-in-vrf-dev-xmit.patch --- diff --git a/queue-5.15/alsa-hda-cs8409-set-pmsg_on-earlier-inside-cs8409-driver.patch b/queue-5.15/alsa-hda-cs8409-set-pmsg_on-earlier-inside-cs8409-driver.patch new file mode 100644 index 00000000000..c4a2149c2a3 --- /dev/null +++ b/queue-5.15/alsa-hda-cs8409-set-pmsg_on-earlier-inside-cs8409-driver.patch @@ -0,0 +1,66 @@ +From 65cc4ad62a9ed47c0b4fcd7af667d97d7c29f19d Mon Sep 17 00:00:00 2001 +From: Stefan Binding +Date: Sun, 28 Nov 2021 11:55:58 +0000 +Subject: ALSA: hda/cs8409: Set PMSG_ON earlier inside cs8409 driver + +From: Stefan Binding + +commit 65cc4ad62a9ed47c0b4fcd7af667d97d7c29f19d upstream. + +For cs8409, it is required to run Jack Detect on resume. +Jack Detect on cs8409+cs42l42 requires an interrupt from +cs42l42 to be sent to cs8409 which is propogated to the driver +via an unsolicited event. +However, the hda_codec drops unsolicited events if the power_state +is not set to PMSG_ON. Which is set at the end of the resume call. +This means there is a race condition between setting power_state +to PMSG_ON and receiving the interrupt. +To solve this, we can add an API to set the power_state earlier +and call that before we start Jack Detect. +This does not cause issues, since we know inside our driver that +we are already initialized, and ready to handle the unsolicited +events. + +Signed-off-by: Stefan Binding +Signed-off-by: Vitaly Rodionov +Cc: # v5.15+ +Link: https://lore.kernel.org/r/20211128115558.71683-1-vitalyr@opensource.cirrus.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/hda_local.h | 9 +++++++++ + sound/pci/hda/patch_cs8409.c | 5 +++++ + 2 files changed, 14 insertions(+) + +--- a/sound/pci/hda/hda_local.h ++++ b/sound/pci/hda/hda_local.h +@@ -438,6 +438,15 @@ int snd_hda_codec_set_pin_target(struct + #define for_each_hda_codec_node(nid, codec) \ + for ((nid) = (codec)->core.start_nid; (nid) < (codec)->core.end_nid; (nid)++) + ++/* Set the codec power_state flag to indicate to allow unsol event handling; ++ * see hda_codec_unsol_event() in hda_bind.c. Calling this might confuse the ++ * state tracking, so use with care. ++ */ ++static inline void snd_hda_codec_allow_unsol_events(struct hda_codec *codec) ++{ ++ codec->core.dev.power.power_state = PMSG_ON; ++} ++ + /* + * get widget capabilities + */ +--- a/sound/pci/hda/patch_cs8409.c ++++ b/sound/pci/hda/patch_cs8409.c +@@ -750,6 +750,11 @@ static void cs42l42_resume(struct sub_co + if (cs42l42->full_scale_vol) + cs8409_i2c_write(cs42l42, 0x2001, 0x01); + ++ /* we have to explicitly allow unsol event handling even during the ++ * resume phase so that the jack event is processed properly ++ */ ++ snd_hda_codec_allow_unsol_events(cs42l42->codec); ++ + cs42l42_enable_jack_detect(cs42l42); + } + diff --git a/queue-5.15/cpufreq-fix-get_cpu_device-failure-in-add_cpu_dev_symlink.patch b/queue-5.15/cpufreq-fix-get_cpu_device-failure-in-add_cpu_dev_symlink.patch new file mode 100644 index 00000000000..c2fffedbf48 --- /dev/null +++ b/queue-5.15/cpufreq-fix-get_cpu_device-failure-in-add_cpu_dev_symlink.patch @@ -0,0 +1,76 @@ +From 2c1b5a84669d2477d8fffe9136e86a2cff591729 Mon Sep 17 00:00:00 2001 +From: Xiongfeng Wang +Date: Mon, 29 Nov 2021 16:02:48 +0800 +Subject: cpufreq: Fix get_cpu_device() failure in add_cpu_dev_symlink() + +From: Xiongfeng Wang + +commit 2c1b5a84669d2477d8fffe9136e86a2cff591729 upstream. + +When I hot added a CPU, I found 'cpufreq' directory was not created +below /sys/devices/system/cpu/cpuX/. + +It is because get_cpu_device() failed in add_cpu_dev_symlink(). + +cpufreq_add_dev() is the .add_dev callback of a CPU subsys interface. +It will be called when the CPU device registered into the system. +The call chain is as follows: + + register_cpu() + ->device_register() + ->device_add() + ->bus_probe_device() + ->cpufreq_add_dev() + +But only after the CPU device has been registered, we can get the +CPU device by get_cpu_device(), otherwise it will return NULL. + +Since we already have the CPU device in cpufreq_add_dev(), pass +it to add_cpu_dev_symlink(). + +I noticed that the 'kobj' of the CPU device has been added into +the system before cpufreq_add_dev(). + +Fixes: 2f0ba790df51 ("cpufreq: Fix creation of symbolic links to policy directories") +Signed-off-by: Xiongfeng Wang +Acked-by: Viresh Kumar +Cc: All applicable +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/cpufreq.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +--- a/drivers/cpufreq/cpufreq.c ++++ b/drivers/cpufreq/cpufreq.c +@@ -1004,10 +1004,9 @@ static struct kobj_type ktype_cpufreq = + .release = cpufreq_sysfs_release, + }; + +-static void add_cpu_dev_symlink(struct cpufreq_policy *policy, unsigned int cpu) ++static void add_cpu_dev_symlink(struct cpufreq_policy *policy, unsigned int cpu, ++ struct device *dev) + { +- struct device *dev = get_cpu_device(cpu); +- + if (unlikely(!dev)) + return; + +@@ -1391,7 +1390,7 @@ static int cpufreq_online(unsigned int c + if (new_policy) { + for_each_cpu(j, policy->related_cpus) { + per_cpu(cpufreq_cpu_data, j) = policy; +- add_cpu_dev_symlink(policy, j); ++ add_cpu_dev_symlink(policy, j, get_cpu_device(j)); + } + + policy->min_freq_req = kzalloc(2 * sizeof(*policy->min_freq_req), +@@ -1565,7 +1564,7 @@ static int cpufreq_add_dev(struct device + /* Create sysfs link on CPU registration */ + policy = per_cpu(cpufreq_cpu_data, cpu); + if (policy) +- add_cpu_dev_symlink(policy, cpu); ++ add_cpu_dev_symlink(policy, cpu, dev); + + return 0; + } diff --git a/queue-5.15/dma-buf-system_heap-use-for_each_sgtable_sg-in-pages-free-flow.patch b/queue-5.15/dma-buf-system_heap-use-for_each_sgtable_sg-in-pages-free-flow.patch new file mode 100644 index 00000000000..988cef4352b --- /dev/null +++ b/queue-5.15/dma-buf-system_heap-use-for_each_sgtable_sg-in-pages-free-flow.patch @@ -0,0 +1,46 @@ +From 679d94cd7d900871e5bc9cf780bd5b73af35ab42 Mon Sep 17 00:00:00 2001 +From: Guangming +Date: Fri, 26 Nov 2021 15:49:04 +0800 +Subject: dma-buf: system_heap: Use 'for_each_sgtable_sg' in pages free flow +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Guangming + +commit 679d94cd7d900871e5bc9cf780bd5b73af35ab42 upstream. + +For previous version, it uses 'sg_table.nent's to traverse sg_table in pages +free flow. +However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the number of +created entries in the DMA adderess space. +So, use 'sg_table.nents' in pages free flow will case some pages can't be freed. + +Here we should use sg_table.orig_nents to free pages memory, but use the +sgtable helper 'for each_sgtable_sg'(, instead of the previous rather common +helper 'for_each_sg' which maybe cause memory leak) is much better. + +Fixes: d963ab0f15fb0 ("dma-buf: system_heap: Allocate higher order pages if available") +Signed-off-by: Guangming +Reviewed-by: Robin Murphy +Cc: # 5.11.* +Reviewed-by: Christian König +Reviewed-by: John Stultz +Signed-off-by: Sumit Semwal +Link: https://patchwork.freedesktop.org/patch/msgid/20211126074904.88388-1-guangming.cao@mediatek.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma-buf/heaps/system_heap.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/dma-buf/heaps/system_heap.c ++++ b/drivers/dma-buf/heaps/system_heap.c +@@ -289,7 +289,7 @@ static void system_heap_dma_buf_release( + int i; + + table = &buffer->sg_table; +- for_each_sg(table->sgl, sg, table->nents, i) { ++ for_each_sgtable_sg(table, sg, i) { + struct page *page = sg_page(sg); + + __free_pages(page, compound_order(page)); diff --git a/queue-5.15/fget-check-that-the-fd-still-exists-after-getting-a-ref-to-it.patch b/queue-5.15/fget-check-that-the-fd-still-exists-after-getting-a-ref-to-it.patch new file mode 100644 index 00000000000..4229dc50af2 --- /dev/null +++ b/queue-5.15/fget-check-that-the-fd-still-exists-after-getting-a-ref-to-it.patch @@ -0,0 +1,63 @@ +From 054aa8d439b9185d4f5eb9a90282d1ce74772969 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Wed, 1 Dec 2021 10:06:14 -0800 +Subject: fget: check that the fd still exists after getting a ref to it + +From: Linus Torvalds + +commit 054aa8d439b9185d4f5eb9a90282d1ce74772969 upstream. + +Jann Horn points out that there is another possible race wrt Unix domain +socket garbage collection, somewhat reminiscent of the one fixed in +commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"). + +See the extended comment about the garbage collection requirements added +to unix_peek_fds() by that commit for details. + +The race comes from how we can locklessly look up a file descriptor just +as it is in the process of being closed, and with the right artificial +timing (Jann added a few strategic 'mdelay(500)' calls to do that), the +Unix domain socket garbage collector could see the reference count +decrement of the close() happen before fget() took its reference to the +file and the file was attached onto a new file descriptor. + +This is all (intentionally) correct on the 'struct file *' side, with +RCU lookups and lockless reference counting very much part of the +design. Getting that reference count out of order isn't a problem per +se. + +But the garbage collector can get confused by seeing this situation of +having seen a file not having any remaining external references and then +seeing it being attached to an fd. + +In commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK") the +fix was to serialize the file descriptor install with the garbage +collector by taking and releasing the unix_gc_lock. + +That's not really an option here, but since this all happens when we are +in the process of looking up a file descriptor, we can instead simply +just re-check that the file hasn't been closed in the meantime, and just +re-do the lookup if we raced with a concurrent close() of the same file +descriptor. + +Reported-and-tested-by: Jann Horn +Acked-by: Miklos Szeredi +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + fs/file.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/fs/file.c ++++ b/fs/file.c +@@ -858,6 +858,10 @@ loop: + file = NULL; + else if (!get_file_rcu_many(file, refs)) + goto loop; ++ else if (files_lookup_fd_raw(files, fd) != file) { ++ fput_many(file, refs); ++ goto loop; ++ } + } + rcu_read_unlock(); + diff --git a/queue-5.15/ipmi-move-remove_work-to-dedicated-workqueue.patch b/queue-5.15/ipmi-move-remove_work-to-dedicated-workqueue.patch new file mode 100644 index 00000000000..7cdb15edc57 --- /dev/null +++ b/queue-5.15/ipmi-move-remove_work-to-dedicated-workqueue.patch @@ -0,0 +1,80 @@ +From 1d49eb91e86e8c1c1614c72e3e958b6b7e2472a9 Mon Sep 17 00:00:00 2001 +From: Ioanna Alifieraki +Date: Mon, 15 Nov 2021 15:16:45 +0200 +Subject: ipmi: Move remove_work to dedicated workqueue + +From: Ioanna Alifieraki + +commit 1d49eb91e86e8c1c1614c72e3e958b6b7e2472a9 upstream. + +Currently when removing an ipmi_user the removal is deferred as a work on +the system's workqueue. Although this guarantees the free operation will +occur in non atomic context, it can race with the ipmi_msghandler module +removal (see [1]) . In case a remove_user work is scheduled for removal +and shortly after ipmi_msghandler module is removed we can end up in a +situation where the module is removed fist and when the work is executed +the system crashes with : +BUG: unable to handle page fault for address: ffffffffc05c3450 +PF: supervisor instruction fetch in kernel mode +PF: error_code(0x0010) - not-present page +because the pages of the module are gone. In cleanup_ipmi() there is no +easy way to detect if there are any pending works to flush them before +removing the module. This patch creates a separate workqueue and schedules +the remove_work works on it. When removing the module the workqueue is +drained when destroyed to avoid the race. + +[1] https://bugs.launchpad.net/bugs/1950666 + +Cc: stable@vger.kernel.org # 5.1 +Fixes: 3b9a907223d7 (ipmi: fix sleep-in-atomic in free_user at cleanup SRCU user->release_barrier) +Signed-off-by: Ioanna Alifieraki +Message-Id: <20211115131645.25116-1-ioanna-maria.alifieraki@canonical.com> +Signed-off-by: Corey Minyard +Signed-off-by: Greg Kroah-Hartman +--- + drivers/char/ipmi/ipmi_msghandler.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +--- a/drivers/char/ipmi/ipmi_msghandler.c ++++ b/drivers/char/ipmi/ipmi_msghandler.c +@@ -191,6 +191,8 @@ struct ipmi_user { + struct work_struct remove_work; + }; + ++struct workqueue_struct *remove_work_wq; ++ + static struct ipmi_user *acquire_ipmi_user(struct ipmi_user *user, int *index) + __acquires(user->release_barrier) + { +@@ -1261,7 +1263,7 @@ static void free_user(struct kref *ref) + struct ipmi_user *user = container_of(ref, struct ipmi_user, refcount); + + /* SRCU cleanup must happen in task context. */ +- schedule_work(&user->remove_work); ++ queue_work(remove_work_wq, &user->remove_work); + } + + static void _ipmi_destroy_user(struct ipmi_user *user) +@@ -5153,6 +5155,13 @@ static int ipmi_init_msghandler(void) + + atomic_notifier_chain_register(&panic_notifier_list, &panic_block); + ++ remove_work_wq = create_singlethread_workqueue("ipmi-msghandler-remove-wq"); ++ if (!remove_work_wq) { ++ pr_err("unable to create ipmi-msghandler-remove-wq workqueue"); ++ rv = -ENOMEM; ++ goto out; ++ } ++ + initialized = true; + + out: +@@ -5178,6 +5187,8 @@ static void __exit cleanup_ipmi(void) + int count; + + if (initialized) { ++ destroy_workqueue(remove_work_wq); ++ + atomic_notifier_chain_unregister(&panic_notifier_list, + &panic_block); + diff --git a/queue-5.15/iwlwifi-mvm-retry-init-flow-if-failed.patch b/queue-5.15/iwlwifi-mvm-retry-init-flow-if-failed.patch new file mode 100644 index 00000000000..0891845e1e4 --- /dev/null +++ b/queue-5.15/iwlwifi-mvm-retry-init-flow-if-failed.patch @@ -0,0 +1,156 @@ +From 5283dd677e52af9db6fe6ad11b2f12220d519d0c Mon Sep 17 00:00:00 2001 +From: Mordechay Goodstein +Date: Wed, 10 Nov 2021 15:01:59 +0200 +Subject: iwlwifi: mvm: retry init flow if failed + +From: Mordechay Goodstein + +commit 5283dd677e52af9db6fe6ad11b2f12220d519d0c upstream. + +In some very rare cases the init flow may fail. In many cases, this is +recoverable, so we can retry. Implement a loop to retry two more times +after the first attempt failed. + +This can happen in two different situations, namely during probe and +during mac80211 start. For the first case, a simple loop is enough. +For the second case, we need to add a flag to prevent mac80211 from +trying to restart it as well, leaving full control with the driver. + +Cc: +Signed-off-by: Mordechay Goodstein +Signed-off-by: Luca Coelho +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 22 +++++++++++++------- + drivers/net/wireless/intel/iwlwifi/iwl-drv.h | 3 ++ + drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 24 +++++++++++++++++++++- + drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 ++ + drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 ++ + 5 files changed, 47 insertions(+), 8 deletions(-) + +--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c ++++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c +@@ -1271,23 +1271,31 @@ _iwl_op_mode_start(struct iwl_drv *drv, + const struct iwl_op_mode_ops *ops = op->ops; + struct dentry *dbgfs_dir = NULL; + struct iwl_op_mode *op_mode = NULL; ++ int retry, max_retry = !!iwlwifi_mod_params.fw_restart * IWL_MAX_INIT_RETRY; ++ ++ for (retry = 0; retry <= max_retry; retry++) { + + #ifdef CONFIG_IWLWIFI_DEBUGFS +- drv->dbgfs_op_mode = debugfs_create_dir(op->name, +- drv->dbgfs_drv); +- dbgfs_dir = drv->dbgfs_op_mode; ++ drv->dbgfs_op_mode = debugfs_create_dir(op->name, ++ drv->dbgfs_drv); ++ dbgfs_dir = drv->dbgfs_op_mode; + #endif + +- op_mode = ops->start(drv->trans, drv->trans->cfg, &drv->fw, dbgfs_dir); ++ op_mode = ops->start(drv->trans, drv->trans->cfg, ++ &drv->fw, dbgfs_dir); ++ ++ if (op_mode) ++ return op_mode; ++ ++ IWL_ERR(drv, "retry init count %d\n", retry); + + #ifdef CONFIG_IWLWIFI_DEBUGFS +- if (!op_mode) { + debugfs_remove_recursive(drv->dbgfs_op_mode); + drv->dbgfs_op_mode = NULL; +- } + #endif ++ } + +- return op_mode; ++ return NULL; + } + + static void _iwl_op_mode_stop(struct iwl_drv *drv) +--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.h ++++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.h +@@ -90,4 +90,7 @@ void iwl_drv_stop(struct iwl_drv *drv); + #define IWL_EXPORT_SYMBOL(sym) + #endif + ++/* max retry for init flow */ ++#define IWL_MAX_INIT_RETRY 2 ++ + #endif /* __iwl_drv_h__ */ +--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +@@ -16,6 +16,7 @@ + #include + #include + ++#include "iwl-drv.h" + #include "iwl-op-mode.h" + #include "iwl-io.h" + #include "mvm.h" +@@ -1116,9 +1117,30 @@ static int iwl_mvm_mac_start(struct ieee + { + struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw); + int ret; ++ int retry, max_retry = 0; + + mutex_lock(&mvm->mutex); +- ret = __iwl_mvm_mac_start(mvm); ++ ++ /* we are starting the mac not in error flow, and restart is enabled */ ++ if (!test_bit(IWL_MVM_STATUS_HW_RESTART_REQUESTED, &mvm->status) && ++ iwlwifi_mod_params.fw_restart) { ++ max_retry = IWL_MAX_INIT_RETRY; ++ /* ++ * This will prevent mac80211 recovery flows to trigger during ++ * init failures ++ */ ++ set_bit(IWL_MVM_STATUS_STARTING, &mvm->status); ++ } ++ ++ for (retry = 0; retry <= max_retry; retry++) { ++ ret = __iwl_mvm_mac_start(mvm); ++ if (!ret) ++ break; ++ ++ IWL_ERR(mvm, "mac start retry %d\n", retry); ++ } ++ clear_bit(IWL_MVM_STATUS_STARTING, &mvm->status); ++ + mutex_unlock(&mvm->mutex); + + return ret; +--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h +@@ -1121,6 +1121,8 @@ struct iwl_mvm { + * @IWL_MVM_STATUS_FIRMWARE_RUNNING: firmware is running + * @IWL_MVM_STATUS_NEED_FLUSH_P2P: need to flush P2P bcast STA + * @IWL_MVM_STATUS_IN_D3: in D3 (or at least about to go into it) ++ * @IWL_MVM_STATUS_STARTING: starting mac, ++ * used to disable restart flow while in STARTING state + */ + enum iwl_mvm_status { + IWL_MVM_STATUS_HW_RFKILL, +@@ -1132,6 +1134,7 @@ enum iwl_mvm_status { + IWL_MVM_STATUS_FIRMWARE_RUNNING, + IWL_MVM_STATUS_NEED_FLUSH_P2P, + IWL_MVM_STATUS_IN_D3, ++ IWL_MVM_STATUS_STARTING, + }; + + /* Keep track of completed init configuration */ +--- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c +@@ -1424,6 +1424,9 @@ void iwl_mvm_nic_restart(struct iwl_mvm + */ + if (!mvm->fw_restart && fw_error) { + iwl_fw_error_collect(&mvm->fwrt, false); ++ } else if (test_bit(IWL_MVM_STATUS_STARTING, ++ &mvm->status)) { ++ IWL_ERR(mvm, "Starting mac, retry will be triggered anyway\n"); + } else if (test_bit(IWL_MVM_STATUS_IN_HW_RESTART, &mvm->status)) { + struct iwl_mvm_reprobe *reprobe; + diff --git a/queue-5.15/kprobes-limit-max-data_size-of-the-kretprobe-instances.patch b/queue-5.15/kprobes-limit-max-data_size-of-the-kretprobe-instances.patch new file mode 100644 index 00000000000..cf8a9102a9a --- /dev/null +++ b/queue-5.15/kprobes-limit-max-data_size-of-the-kretprobe-instances.patch @@ -0,0 +1,55 @@ +From 6bbfa44116689469267f1a6e3d233b52114139d2 Mon Sep 17 00:00:00 2001 +From: Masami Hiramatsu +Date: Wed, 1 Dec 2021 23:45:50 +0900 +Subject: kprobes: Limit max data_size of the kretprobe instances + +From: Masami Hiramatsu + +commit 6bbfa44116689469267f1a6e3d233b52114139d2 upstream. + +The 'kprobe::data_size' is unsigned, thus it can not be negative. But if +user sets it enough big number (e.g. (size_t)-8), the result of 'data_size ++ sizeof(struct kretprobe_instance)' becomes smaller than sizeof(struct +kretprobe_instance) or zero. In result, the kretprobe_instance are +allocated without enough memory, and kretprobe accesses outside of +allocated memory. + +To avoid this issue, introduce a max limitation of the +kretprobe::data_size. 4KB per instance should be OK. + +Link: https://lkml.kernel.org/r/163836995040.432120.10322772773821182925.stgit@devnote2 + +Cc: stable@vger.kernel.org +Fixes: f47cd9b553aa ("kprobes: kretprobe user entry-handler") +Reported-by: zhangyue +Signed-off-by: Masami Hiramatsu +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/kprobes.h | 2 ++ + kernel/kprobes.c | 3 +++ + 2 files changed, 5 insertions(+) + +--- a/include/linux/kprobes.h ++++ b/include/linux/kprobes.h +@@ -154,6 +154,8 @@ struct kretprobe { + struct kretprobe_holder *rph; + }; + ++#define KRETPROBE_MAX_DATA_SIZE 4096 ++ + struct kretprobe_instance { + union { + struct freelist_node freelist; +--- a/kernel/kprobes.c ++++ b/kernel/kprobes.c +@@ -2006,6 +2006,9 @@ int register_kretprobe(struct kretprobe + } + } + ++ if (rp->data_size > KRETPROBE_MAX_DATA_SIZE) ++ return -E2BIG; ++ + rp->kp.pre_handler = pre_handler_kretprobe; + rp->kp.post_handler = NULL; + diff --git a/queue-5.15/net-tls-fix-authentication-failure-in-ccm-mode.patch b/queue-5.15/net-tls-fix-authentication-failure-in-ccm-mode.patch new file mode 100644 index 00000000000..51c3072e703 --- /dev/null +++ b/queue-5.15/net-tls-fix-authentication-failure-in-ccm-mode.patch @@ -0,0 +1,44 @@ +From 5961060692f8b17cd2080620a3d27b95d2ae05ca Mon Sep 17 00:00:00 2001 +From: Tianjia Zhang +Date: Mon, 29 Nov 2021 17:32:12 +0800 +Subject: net/tls: Fix authentication failure in CCM mode + +From: Tianjia Zhang + +commit 5961060692f8b17cd2080620a3d27b95d2ae05ca upstream. + +When the TLS cipher suite uses CCM mode, including AES CCM and +SM4 CCM, the first byte of the B0 block is flags, and the real +IV starts from the second byte. The XOR operation of the IV and +rec_seq should be skip this byte, that is, add the iv_offset. + +Fixes: f295b3ae9f59 ("net/tls: Add support of AES128-CCM based ciphers") +Signed-off-by: Tianjia Zhang +Cc: Vakul Garg +Cc: stable@vger.kernel.org # v5.2+ +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/tls/tls_sw.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/tls/tls_sw.c ++++ b/net/tls/tls_sw.c +@@ -515,7 +515,7 @@ static int tls_do_encryption(struct sock + memcpy(&rec->iv_data[iv_offset], tls_ctx->tx.iv, + prot->iv_size + prot->salt_size); + +- xor_iv_with_seq(prot, rec->iv_data, tls_ctx->tx.rec_seq); ++ xor_iv_with_seq(prot, rec->iv_data + iv_offset, tls_ctx->tx.rec_seq); + + sge->offset += prot->prepend_size; + sge->length -= prot->prepend_size; +@@ -1487,7 +1487,7 @@ static int decrypt_internal(struct sock + else + memcpy(iv + iv_offset, tls_ctx->rx.iv, prot->salt_size); + +- xor_iv_with_seq(prot, iv, tls_ctx->rx.rec_seq); ++ xor_iv_with_seq(prot, iv + iv_offset, tls_ctx->rx.rec_seq); + + /* Prepare AAD */ + tls_make_aad(aad, rxm->full_len - prot->overhead_size + diff --git a/queue-5.15/rt2x00-do-not-mark-device-gone-on-eproto-errors-during-start.patch b/queue-5.15/rt2x00-do-not-mark-device-gone-on-eproto-errors-during-start.patch new file mode 100644 index 00000000000..bef0227ce6a --- /dev/null +++ b/queue-5.15/rt2x00-do-not-mark-device-gone-on-eproto-errors-during-start.patch @@ -0,0 +1,40 @@ +From ed53ae75693096f1c10b4561edd31a07b631bd72 Mon Sep 17 00:00:00 2001 +From: Stanislaw Gruszka +Date: Thu, 11 Nov 2021 15:10:03 +0100 +Subject: rt2x00: do not mark device gone on EPROTO errors during start + +From: Stanislaw Gruszka + +commit ed53ae75693096f1c10b4561edd31a07b631bd72 upstream. + +As reported by Exuvo is possible that we have lot's of EPROTO errors +during device start i.e. firmware load. But after that device works +correctly. Hence marking device gone by few EPROTO errors done by +commit e383c70474db ("rt2x00: check number of EPROTO errors") caused +regression - Exuvo device stop working after kernel update. To fix +disable the check during device start. + +Link: https://lore.kernel.org/linux-wireless/bff7d309-a816-6a75-51b6-5928ef4f7a8c@exuvo.se/ +Reported-and-tested-by: Exuvo +Fixes: e383c70474db ("rt2x00: check number of EPROTO errors") +Cc: stable@vger.kernel.org +Signed-off-by: Stanislaw Gruszka +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20211111141003.GA134627@wp.pl +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c ++++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c +@@ -25,6 +25,9 @@ static bool rt2x00usb_check_usb_error(st + if (status == -ENODEV || status == -ENOENT) + return true; + ++ if (!test_bit(DEVICE_STATE_STARTED, &rt2x00dev->flags)) ++ return false; ++ + if (status == -EPROTO || status == -ETIMEDOUT) + rt2x00dev->num_proto_errs++; + else diff --git a/queue-5.15/s390-pci-move-pseudo-mmio-to-prevent-mio-overlap.patch b/queue-5.15/s390-pci-move-pseudo-mmio-to-prevent-mio-overlap.patch new file mode 100644 index 00000000000..9c69d465622 --- /dev/null +++ b/queue-5.15/s390-pci-move-pseudo-mmio-to-prevent-mio-overlap.patch @@ -0,0 +1,65 @@ +From 52d04d408185b7aa47628d2339c28ec70074e0ae Mon Sep 17 00:00:00 2001 +From: Niklas Schnelle +Date: Thu, 4 Nov 2021 15:04:10 +0100 +Subject: s390/pci: move pseudo-MMIO to prevent MIO overlap + +From: Niklas Schnelle + +commit 52d04d408185b7aa47628d2339c28ec70074e0ae upstream. + +When running without MIO support, with pci=nomio or for devices which +are not MIO-capable the zPCI subsystem generates pseudo-MMIO addresses +to allow access to PCI BARs via MMIO based Linux APIs even though the +platform uses function handles and BAR numbers. + +This is done by stashing an index into our global IOMAP array which +contains the function handle in the 16 most significant bits of the +addresses returned by ioremap() always setting the most significant bit. + +On the other hand the MIO addresses assigned by the platform for use, +while requiring special instructions, allow PCI access with virtually +mapped physical addresses. Now the problem is that these MIO addresses +and our own pseudo-MMIO addresses may overlap, while functionally this +would not be a problem by itself this overlap is detected by common code +as both address types are added as resources in the iomem_resource tree. +This leads to the overlapping resource claim of either the MIO capable +or non-MIO capable devices with being rejected. + +Since PCI is tightly coupled to the use of the iomem_resource tree, see +for example the code for request_mem_region(), we can't reasonably get +rid of the overlap being detected by keeping our pseudo-MMIO addresses +out of the iomem_resource tree. + +Instead let's move the range used by our own pseudo-MMIO addresses by +starting at (1UL << 62) and only using addresses below (1UL << 63) thus +avoiding the range currently used for MIO addresses. + +Fixes: c7ff0e918a7c ("s390/pci: deal with devices that have no support for MIO instructions") +Cc: stable@vger.kernel.org # 5.3+ +Reviewed-by: Pierre Morel +Signed-off-by: Niklas Schnelle +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/include/asm/pci_io.h | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/arch/s390/include/asm/pci_io.h ++++ b/arch/s390/include/asm/pci_io.h +@@ -14,12 +14,13 @@ + + /* I/O Map */ + #define ZPCI_IOMAP_SHIFT 48 +-#define ZPCI_IOMAP_ADDR_BASE 0x8000000000000000UL ++#define ZPCI_IOMAP_ADDR_SHIFT 62 ++#define ZPCI_IOMAP_ADDR_BASE (1UL << ZPCI_IOMAP_ADDR_SHIFT) + #define ZPCI_IOMAP_ADDR_OFF_MASK ((1UL << ZPCI_IOMAP_SHIFT) - 1) + #define ZPCI_IOMAP_MAX_ENTRIES \ +- ((ULONG_MAX - ZPCI_IOMAP_ADDR_BASE + 1) / (1UL << ZPCI_IOMAP_SHIFT)) ++ (1UL << (ZPCI_IOMAP_ADDR_SHIFT - ZPCI_IOMAP_SHIFT)) + #define ZPCI_IOMAP_ADDR_IDX_MASK \ +- (~ZPCI_IOMAP_ADDR_OFF_MASK - ZPCI_IOMAP_ADDR_BASE) ++ ((ZPCI_IOMAP_ADDR_BASE - 1) & ~ZPCI_IOMAP_ADDR_OFF_MASK) + + struct zpci_iomap_entry { + u32 fh; diff --git a/queue-5.15/sata_fsl-fix-uaf-in-sata_fsl_port_stop-when-rmmod-sata_fsl.patch b/queue-5.15/sata_fsl-fix-uaf-in-sata_fsl_port_stop-when-rmmod-sata_fsl.patch new file mode 100644 index 00000000000..3029ffead02 --- /dev/null +++ b/queue-5.15/sata_fsl-fix-uaf-in-sata_fsl_port_stop-when-rmmod-sata_fsl.patch @@ -0,0 +1,98 @@ +From 6c8ad7e8cf29eb55836e7a0215f967746ab2b504 Mon Sep 17 00:00:00 2001 +From: Baokun Li +Date: Fri, 26 Nov 2021 10:03:06 +0800 +Subject: sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl + +From: Baokun Li + +commit 6c8ad7e8cf29eb55836e7a0215f967746ab2b504 upstream. + +When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux, +a bug is reported: + ================================================================== + BUG: Unable to handle kernel data access on read at 0x80000800805b502c + Oops: Kernel access of bad area, sig: 11 [#1] + NIP [c0000000000388a4] .ioread32+0x4/0x20 + LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] + Call Trace: + .free_irq+0x1c/0x4e0 (unreliable) + .ata_host_stop+0x74/0xd0 [libata] + .release_nodes+0x330/0x3f0 + .device_release_driver_internal+0x178/0x2c0 + .driver_detach+0x64/0xd0 + .bus_remove_driver+0x70/0xf0 + .driver_unregister+0x38/0x80 + .platform_driver_unregister+0x14/0x30 + .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] + .__se_sys_delete_module+0x1ec/0x2d0 + .system_call_exception+0xfc/0x1f0 + system_call_common+0xf8/0x200 + ================================================================== + +The triggering of the BUG is shown in the following stack: + +driver_detach + device_release_driver_internal + __device_release_driver + drv->remove(dev) --> platform_drv_remove/platform_remove + drv->remove(dev) --> sata_fsl_remove + iounmap(host_priv->hcr_base); <---- unmap + kfree(host_priv); <---- free + devres_release_all + release_nodes + dr->node.release(dev, dr->data) --> ata_host_stop + ap->ops->port_stop(ap) --> sata_fsl_port_stop + ioread32(hcr_base + HCONTROL) <---- UAF + host->ops->host_stop(host) + +The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should +not be executed in drv->remove. These functions should be executed in +host_stop after port_stop. Therefore, we move these functions to the +new function sata_fsl_host_stop and bind the new function to host_stop. + +Fixes: faf0b2e5afe7 ("drivers/ata: add support to Freescale 3.0Gbps SATA Controller") +Cc: stable@vger.kernel.org +Reported-by: Hulk Robot +Signed-off-by: Baokun Li +Reviewed-by: Sergei Shtylyov +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/sata_fsl.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +--- a/drivers/ata/sata_fsl.c ++++ b/drivers/ata/sata_fsl.c +@@ -1394,6 +1394,14 @@ static int sata_fsl_init_controller(stru + return 0; + } + ++static void sata_fsl_host_stop(struct ata_host *host) ++{ ++ struct sata_fsl_host_priv *host_priv = host->private_data; ++ ++ iounmap(host_priv->hcr_base); ++ kfree(host_priv); ++} ++ + /* + * scsi mid-layer and libata interface structures + */ +@@ -1426,6 +1434,8 @@ static struct ata_port_operations sata_f + .port_start = sata_fsl_port_start, + .port_stop = sata_fsl_port_stop, + ++ .host_stop = sata_fsl_host_stop, ++ + .pmp_attach = sata_fsl_pmp_attach, + .pmp_detach = sata_fsl_pmp_detach, + }; +@@ -1558,8 +1568,6 @@ static int sata_fsl_remove(struct platfo + ata_host_detach(host); + + irq_dispose_mapping(host_priv->irq); +- iounmap(host_priv->hcr_base); +- kfree(host_priv); + + return 0; + } diff --git a/queue-5.15/sata_fsl-fix-warning-in-remove_proc_entry-when-rmmod-sata_fsl.patch b/queue-5.15/sata_fsl-fix-warning-in-remove_proc_entry-when-rmmod-sata_fsl.patch new file mode 100644 index 00000000000..bf7ae81bf58 --- /dev/null +++ b/queue-5.15/sata_fsl-fix-warning-in-remove_proc_entry-when-rmmod-sata_fsl.patch @@ -0,0 +1,78 @@ +From 6f48394cf1f3e8486591ad98c11cdadb8f1ef2ad Mon Sep 17 00:00:00 2001 +From: Baokun Li +Date: Fri, 26 Nov 2021 10:03:07 +0800 +Subject: sata_fsl: fix warning in remove_proc_entry when rmmod sata_fsl + +From: Baokun Li + +commit 6f48394cf1f3e8486591ad98c11cdadb8f1ef2ad upstream. + +Trying to remove the fsl-sata module in the PPC64 GNU/Linux +leads to the following warning: + ------------[ cut here ]------------ + remove_proc_entry: removing non-empty directory 'irq/69', + leaking at least 'fsl-sata[ff0221000.sata]' + WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 + .remove_proc_entry+0x20c/0x220 + IRQMASK: 0 + NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 + LR [c000000000338268] .remove_proc_entry+0x208/0x220 + Call Trace: + .remove_proc_entry+0x208/0x220 (unreliable) + .unregister_irq_proc+0x104/0x140 + .free_desc+0x44/0xb0 + .irq_free_descs+0x9c/0xf0 + .irq_dispose_mapping+0x64/0xa0 + .sata_fsl_remove+0x58/0xa0 [sata_fsl] + .platform_drv_remove+0x40/0x90 + .device_release_driver_internal+0x160/0x2c0 + .driver_detach+0x64/0xd0 + .bus_remove_driver+0x70/0xf0 + .driver_unregister+0x38/0x80 + .platform_driver_unregister+0x14/0x30 + .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] + ---[ end trace 0ea876d4076908f5 ]--- + +The driver creates the mapping by calling irq_of_parse_and_map(), +so it also has to dispose the mapping. But the easy way out is to +simply use platform_get_irq() instead of irq_of_parse_map(). Also +we should adapt return value checking and propagate error values. + +In this case the mapping is not managed by the device but by +the of core, so the device has not to dispose the mapping. + +Fixes: faf0b2e5afe7 ("drivers/ata: add support to Freescale 3.0Gbps SATA Controller") +Cc: stable@vger.kernel.org +Reported-by: Hulk Robot +Signed-off-by: Baokun Li +Reviewed-by: Sergei Shtylyov +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/sata_fsl.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/drivers/ata/sata_fsl.c ++++ b/drivers/ata/sata_fsl.c +@@ -1490,9 +1490,9 @@ static int sata_fsl_probe(struct platfor + host_priv->ssr_base = ssr_base; + host_priv->csr_base = csr_base; + +- irq = irq_of_parse_and_map(ofdev->dev.of_node, 0); +- if (!irq) { +- dev_err(&ofdev->dev, "invalid irq from platform\n"); ++ irq = platform_get_irq(ofdev, 0); ++ if (irq < 0) { ++ retval = irq; + goto error_exit_with_cleanup; + } + host_priv->irq = irq; +@@ -1567,8 +1567,6 @@ static int sata_fsl_remove(struct platfo + + ata_host_detach(host); + +- irq_dispose_mapping(host_priv->irq); +- + return 0; + } + diff --git a/queue-5.15/series b/queue-5.15/series index a8bda62073a..fbb6055d93d 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -49,3 +49,16 @@ perf-report-fix-memory-leaks-around-perf_tip.patch tracing-don-t-use-out-of-sync-va_list-in-event-print.patch net-smc-avoid-warning-of-possible-recursive-locking.patch acpi-add-stubs-for-wakeup-handler-functions.patch +net-tls-fix-authentication-failure-in-ccm-mode.patch +vrf-reset-ipcb-ip6cb-when-processing-outbound-pkts-in-vrf-dev-xmit.patch +kprobes-limit-max-data_size-of-the-kretprobe-instances.patch +alsa-hda-cs8409-set-pmsg_on-earlier-inside-cs8409-driver.patch +rt2x00-do-not-mark-device-gone-on-eproto-errors-during-start.patch +ipmi-move-remove_work-to-dedicated-workqueue.patch +cpufreq-fix-get_cpu_device-failure-in-add_cpu_dev_symlink.patch +iwlwifi-mvm-retry-init-flow-if-failed.patch +dma-buf-system_heap-use-for_each_sgtable_sg-in-pages-free-flow.patch +s390-pci-move-pseudo-mmio-to-prevent-mio-overlap.patch +fget-check-that-the-fd-still-exists-after-getting-a-ref-to-it.patch +sata_fsl-fix-uaf-in-sata_fsl_port_stop-when-rmmod-sata_fsl.patch +sata_fsl-fix-warning-in-remove_proc_entry-when-rmmod-sata_fsl.patch diff --git a/queue-5.15/vrf-reset-ipcb-ip6cb-when-processing-outbound-pkts-in-vrf-dev-xmit.patch b/queue-5.15/vrf-reset-ipcb-ip6cb-when-processing-outbound-pkts-in-vrf-dev-xmit.patch new file mode 100644 index 00000000000..485e2d5e76d --- /dev/null +++ b/queue-5.15/vrf-reset-ipcb-ip6cb-when-processing-outbound-pkts-in-vrf-dev-xmit.patch @@ -0,0 +1,51 @@ +From ee201011c1e1563c114a55c86eb164b236f18e84 Mon Sep 17 00:00:00 2001 +From: Stephen Suryaputra +Date: Tue, 30 Nov 2021 11:26:37 -0500 +Subject: vrf: Reset IPCB/IP6CB when processing outbound pkts in vrf dev xmit + +From: Stephen Suryaputra + +commit ee201011c1e1563c114a55c86eb164b236f18e84 upstream. + +IPCB/IP6CB need to be initialized when processing outbound v4 or v6 pkts +in the codepath of vrf device xmit function so that leftover garbage +doesn't cause futher code that uses the CB to incorrectly process the +pkt. + +One occasion of the issue might occur when MPLS route uses the vrf +device as the outgoing device such as when the route is added using "ip +-f mpls route add