--- /dev/null
+From 65cc4ad62a9ed47c0b4fcd7af667d97d7c29f19d Mon Sep 17 00:00:00 2001
+From: Stefan Binding <sbinding@opensource.cirrus.com>
+Date: Sun, 28 Nov 2021 11:55:58 +0000
+Subject: ALSA: hda/cs8409: Set PMSG_ON earlier inside cs8409 driver
+
+From: Stefan Binding <sbinding@opensource.cirrus.com>
+
+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 <sbinding@opensource.cirrus.com>
+Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
+Cc: <stable@vger.kernel.org> # v5.15+
+Link: https://lore.kernel.org/r/20211128115558.71683-1-vitalyr@opensource.cirrus.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
--- /dev/null
+From 2c1b5a84669d2477d8fffe9136e86a2cff591729 Mon Sep 17 00:00:00 2001
+From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+Date: Mon, 29 Nov 2021 16:02:48 +0800
+Subject: cpufreq: Fix get_cpu_device() failure in add_cpu_dev_symlink()
+
+From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+
+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 <wangxiongfeng2@huawei.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 679d94cd7d900871e5bc9cf780bd5b73af35ab42 Mon Sep 17 00:00:00 2001
+From: Guangming <Guangming.Cao@mediatek.com>
+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 <Guangming.Cao@mediatek.com>
+
+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 <Guangming.Cao@mediatek.com>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Cc: <stable@vger.kernel.org> # 5.11.*
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Reviewed-by: John Stultz <john.stultz@linaro.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20211126074904.88388-1-guangming.cao@mediatek.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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));
--- /dev/null
+From 054aa8d439b9185d4f5eb9a90282d1ce74772969 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+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 <torvalds@linux-foundation.org>
+
+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 <jannh@google.com>
+Acked-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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();
+
--- /dev/null
+From 1d49eb91e86e8c1c1614c72e3e958b6b7e2472a9 Mon Sep 17 00:00:00 2001
+From: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com>
+Date: Mon, 15 Nov 2021 15:16:45 +0200
+Subject: ipmi: Move remove_work to dedicated workqueue
+
+From: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com>
+
+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 <ioanna-maria.alifieraki@canonical.com>
+Message-Id: <20211115131645.25116-1-ioanna-maria.alifieraki@canonical.com>
+Signed-off-by: Corey Minyard <cminyard@mvista.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 5283dd677e52af9db6fe6ad11b2f12220d519d0c Mon Sep 17 00:00:00 2001
+From: Mordechay Goodstein <mordechay.goodstein@intel.com>
+Date: Wed, 10 Nov 2021 15:01:59 +0200
+Subject: iwlwifi: mvm: retry init flow if failed
+
+From: Mordechay Goodstein <mordechay.goodstein@intel.com>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <net/ieee80211_radiotap.h>
+ #include <net/tcp.h>
+
++#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;
+
--- /dev/null
+From 6bbfa44116689469267f1a6e3d233b52114139d2 Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Wed, 1 Dec 2021 23:45:50 +0900
+Subject: kprobes: Limit max data_size of the kretprobe instances
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+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 <zhangyue1@kylinos.cn>
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From 5961060692f8b17cd2080620a3d27b95d2ae05ca Mon Sep 17 00:00:00 2001
+From: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
+Date: Mon, 29 Nov 2021 17:32:12 +0800
+Subject: net/tls: Fix authentication failure in CCM mode
+
+From: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
+
+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 <tianjia.zhang@linux.alibaba.com>
+Cc: Vakul Garg <vakul.garg@nxp.com>
+Cc: stable@vger.kernel.org # v5.2+
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 +
--- /dev/null
+From ed53ae75693096f1c10b4561edd31a07b631bd72 Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <stf_xl@wp.pl>
+Date: Thu, 11 Nov 2021 15:10:03 +0100
+Subject: rt2x00: do not mark device gone on EPROTO errors during start
+
+From: Stanislaw Gruszka <stf_xl@wp.pl>
+
+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 <exuvo@exuvo.se>
+Fixes: e383c70474db ("rt2x00: check number of EPROTO errors")
+Cc: stable@vger.kernel.org
+Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20211111141003.GA134627@wp.pl
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 52d04d408185b7aa47628d2339c28ec70074e0ae Mon Sep 17 00:00:00 2001
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+Date: Thu, 4 Nov 2021 15:04:10 +0100
+Subject: s390/pci: move pseudo-MMIO to prevent MIO overlap
+
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+
+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 <pmorel@linux.ibm.com>
+Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 6c8ad7e8cf29eb55836e7a0215f967746ab2b504 Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun1@huawei.com>
+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 <libaokun1@huawei.com>
+
+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 <hulkci@huawei.com>
+Signed-off-by: Baokun Li <libaokun1@huawei.com>
+Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 6f48394cf1f3e8486591ad98c11cdadb8f1ef2ad Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun1@huawei.com>
+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 <libaokun1@huawei.com>
+
+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 <hulkci@huawei.com>
+Signed-off-by: Baokun Li <libaokun1@huawei.com>
+Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
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
--- /dev/null
+From ee201011c1e1563c114a55c86eb164b236f18e84 Mon Sep 17 00:00:00 2001
+From: Stephen Suryaputra <ssuryaextr@gmail.com>
+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 <ssuryaextr@gmail.com>
+
+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 <label> dev <vrf>" command.
+
+The problems seems to exist since day one. Hence I put the day one
+commits on the Fixes tags.
+
+Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
+Fixes: 35402e313663 ("net: Add IPv6 support to VRF device")
+Cc: stable@vger.kernel.org
+Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://lore.kernel.org/r/20211130162637.3249-1-ssuryaextr@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/vrf.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/net/vrf.c
++++ b/drivers/net/vrf.c
+@@ -497,6 +497,7 @@ static netdev_tx_t vrf_process_v6_outbou
+ /* strip the ethernet header added for pass through VRF device */
+ __skb_pull(skb, skb_network_offset(skb));
+
++ memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
+ ret = vrf_ip6_local_out(net, skb->sk, skb);
+ if (unlikely(net_xmit_eval(ret)))
+ dev->stats.tx_errors++;
+@@ -579,6 +580,7 @@ static netdev_tx_t vrf_process_v4_outbou
+ RT_SCOPE_LINK);
+ }
+
++ memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
+ ret = vrf_ip_local_out(dev_net(skb_dst(skb)->dev), skb->sk, skb);
+ if (unlikely(net_xmit_eval(ret)))
+ vrf_dev->stats.tx_errors++;
projects / thirdparty / kernel / stable-queue.git / commitdiff
