--- /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
+@@ -995,10 +995,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;
+
+@@ -1384,7 +1383,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),
+@@ -1547,7 +1546,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 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
+@@ -723,6 +723,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
+@@ -220,6 +220,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)
+ {
+@@ -1286,7 +1288,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)
+@@ -5161,6 +5163,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:
+@@ -5186,6 +5195,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 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
+@@ -155,6 +155,8 @@ struct kretprobe {
+ raw_spinlock_t lock;
+ };
+
++#define KRETPROBE_MAX_DATA_SIZE 4096
++
+ struct kretprobe_instance {
+ struct hlist_node hlist;
+ struct kretprobe *rp;
+--- a/kernel/kprobes.c
++++ b/kernel/kprobes.c
+@@ -2003,6 +2003,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;
+ rp->kp.fault_handler = NULL;
--- /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;
+ }
+
perf-hist-fix-memory-leak-of-a-perf_hpp_fmt.patch
perf-report-fix-memory-leaks-around-perf_tip.patch
net-smc-avoid-warning-of-possible-recursive-locking.patch
+vrf-reset-ipcb-ip6cb-when-processing-outbound-pkts-in-vrf-dev-xmit.patch
+kprobes-limit-max-data_size-of-the-kretprobe-instances.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
+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
+@@ -221,6 +221,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++;
+@@ -304,6 +305,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
