From: Greg Kroah-Hartman Date: Sat, 4 Dec 2021 11:07:31 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v4.4.294~44 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=e6fd6025abdba70f9dd233f5cbaebcf82a3e3958;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: cpufreq-fix-get_cpu_device-failure-in-add_cpu_dev_symlink.patch fget-check-that-the-fd-still-exists-after-getting-a-ref-to-it.patch ipmi-move-remove_work-to-dedicated-workqueue.patch kprobes-limit-max-data_size-of-the-kretprobe-instances.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.10/ata-libahci-adjust-behavior-when-storaged3enable-_ds.patch b/queue-5.10/ata-libahci-adjust-behavior-when-storaged3enable-_ds.patch deleted file mode 100644 index cdfbbc48e27..00000000000 --- a/queue-5.10/ata-libahci-adjust-behavior-when-storaged3enable-_ds.patch +++ /dev/null @@ -1,69 +0,0 @@ -From 4c8aefc159dde8ee5924bcfa6d3c6a22ece57850 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Fri, 12 Nov 2021 14:15:39 -0600 -Subject: ata: libahci: Adjust behavior when StorageD3Enable _DSD is set - -From: Mario Limonciello - -[ Upstream commit 7c5f641a5914ce0303b06bcfcd7674ee64aeebe9 ] - -The StorageD3Enable _DSD is used for the vendor to indicate that the disk -should be opted into or out of a different behavior based upon the platform -design. - -For AMD's Renoir and Green Sardine platforms it's important that any -attached SATA storage has transitioned into DevSlp when s2idle is used. - -If the disk is left in active/partial/slumber, then the system is not able -to resume properly. - -When the StorageD3Enable _DSD is detected, check the system is using s2idle -and DevSlp is enabled and if so explicitly wait long enough for the disk to -enter DevSlp. - -Cc: Nehal-bakulchandra Shah -BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214091 -Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro -Signed-off-by: Mario Limonciello -Signed-off-by: Damien Le Moal -Signed-off-by: Sasha Levin ---- - drivers/ata/libahci.c | 15 +++++++++++++++ - 1 file changed, 15 insertions(+) - -diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c -index fec2e9754aed2..d0d6efc9370d0 100644 ---- a/drivers/ata/libahci.c -+++ b/drivers/ata/libahci.c -@@ -2304,6 +2304,18 @@ int ahci_port_resume(struct ata_port *ap) - EXPORT_SYMBOL_GPL(ahci_port_resume); - - #ifdef CONFIG_PM -+static void ahci_handle_s2idle(struct ata_port *ap) -+{ -+ void __iomem *port_mmio = ahci_port_base(ap); -+ u32 devslp; -+ -+ if (pm_suspend_via_firmware()) -+ return; -+ devslp = readl(port_mmio + PORT_DEVSLP); -+ if ((devslp & PORT_DEVSLP_ADSE)) -+ ata_msleep(ap, devslp_idle_timeout); -+} -+ - static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg) - { - const char *emsg = NULL; -@@ -2317,6 +2329,9 @@ static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg) - ata_port_freeze(ap); - } - -+ if (acpi_storage_d3(ap->host->dev)) -+ ahci_handle_s2idle(ap); -+ - ahci_rpm_put_port(ap); - return rc; - } --- -2.33.0 - diff --git a/queue-5.10/cpufreq-fix-get_cpu_device-failure-in-add_cpu_dev_symlink.patch b/queue-5.10/cpufreq-fix-get_cpu_device-failure-in-add_cpu_dev_symlink.patch new file mode 100644 index 00000000000..dd71fca835d --- /dev/null +++ b/queue-5.10/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), +@@ -1553,7 +1552,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.10/fget-check-that-the-fd-still-exists-after-getting-a-ref-to-it.patch b/queue-5.10/fget-check-that-the-fd-still-exists-after-getting-a-ref-to-it.patch new file mode 100644 index 00000000000..379d661e647 --- /dev/null +++ b/queue-5.10/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 +@@ -834,6 +834,10 @@ loop: + file = NULL; + else if (!get_file_rcu_many(file, refs)) + goto loop; ++ else if (__fcheck_files(files, fd) != file) { ++ fput_many(file, refs); ++ goto loop; ++ } + } + rcu_read_unlock(); + diff --git a/queue-5.10/ipmi-move-remove_work-to-dedicated-workqueue.patch b/queue-5.10/ipmi-move-remove_work-to-dedicated-workqueue.patch new file mode 100644 index 00000000000..d05cd85119a --- /dev/null +++ b/queue-5.10/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 +@@ -203,6 +203,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) + { +@@ -1272,7 +1274,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) +@@ -5166,6 +5168,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: +@@ -5191,6 +5200,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.10/kprobes-limit-max-data_size-of-the-kretprobe-instances.patch b/queue-5.10/kprobes-limit-max-data_size-of-the-kretprobe-instances.patch new file mode 100644 index 00000000000..de1e1326389 --- /dev/null +++ b/queue-5.10/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 +@@ -155,6 +155,8 @@ struct kretprobe { + raw_spinlock_t lock; + }; + ++#define KRETPROBE_MAX_DATA_SIZE 4096 ++ + struct kretprobe_instance { + union { + struct hlist_node hlist; +--- a/kernel/kprobes.c ++++ b/kernel/kprobes.c +@@ -2137,6 +2137,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; diff --git a/queue-5.10/pinctrl-amd-fix-wakeups-when-irq-is-shared-with-sci.patch b/queue-5.10/pinctrl-amd-fix-wakeups-when-irq-is-shared-with-sci.patch deleted file mode 100644 index 0e58786e369..00000000000 --- a/queue-5.10/pinctrl-amd-fix-wakeups-when-irq-is-shared-with-sci.patch +++ /dev/null @@ -1,114 +0,0 @@ -From e90381ff9d708e67c3c5196e962566edd60e5e23 Mon Sep 17 00:00:00 2001 -From: Sasha Levin -Date: Sun, 31 Oct 2021 20:48:53 -0500 -Subject: pinctrl: amd: Fix wakeups when IRQ is shared with SCI - -From: Mario Limonciello - -[ Upstream commit 2d54067fcd23aae61e23508425ae5b29e973573d ] - -On some Lenovo AMD Gen2 platforms the IRQ for the SCI and pinctrl drivers -are shared. Due to how the s2idle loop handling works, this case needs -an extra explicit check whether the interrupt was caused by SCI or by -the GPIO controller. - -To fix this rework the existing IRQ handler function to function as a -checker and an IRQ handler depending on the calling arguments. - -BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1738 -Reported-by: Joerie de Gram -Signed-off-by: Mario Limonciello -Acked-by: Basavaraj Natikar -Link: https://lore.kernel.org/r/20211101014853.6177-2-mario.limonciello@amd.com -Signed-off-by: Linus Walleij -Signed-off-by: Sasha Levin ---- - drivers/pinctrl/pinctrl-amd.c | 29 ++++++++++++++++++++++++++--- - 1 file changed, 26 insertions(+), 3 deletions(-) - -diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c -index e20bcc835d6a8..54dfa0244422c 100644 ---- a/drivers/pinctrl/pinctrl-amd.c -+++ b/drivers/pinctrl/pinctrl-amd.c -@@ -520,14 +520,14 @@ static struct irq_chip amd_gpio_irqchip = { - - #define PIN_IRQ_PENDING (BIT(INTERRUPT_STS_OFF) | BIT(WAKE_STS_OFF)) - --static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id) -+static bool do_amd_gpio_irq_handler(int irq, void *dev_id) - { - struct amd_gpio *gpio_dev = dev_id; - struct gpio_chip *gc = &gpio_dev->gc; -- irqreturn_t ret = IRQ_NONE; - unsigned int i, irqnr; - unsigned long flags; - u32 __iomem *regs; -+ bool ret = false; - u32 regval; - u64 status, mask; - -@@ -549,6 +549,14 @@ static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id) - /* Each status bit covers four pins */ - for (i = 0; i < 4; i++) { - regval = readl(regs + i); -+ /* caused wake on resume context for shared IRQ */ -+ if (irq < 0 && (regval & BIT(WAKE_STS_OFF))) { -+ dev_dbg(&gpio_dev->pdev->dev, -+ "Waking due to GPIO %d: 0x%x", -+ irqnr + i, regval); -+ return true; -+ } -+ - if (!(regval & PIN_IRQ_PENDING) || - !(regval & BIT(INTERRUPT_MASK_OFF))) - continue; -@@ -574,9 +582,12 @@ static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id) - } - writel(regval, regs + i); - raw_spin_unlock_irqrestore(&gpio_dev->lock, flags); -- ret = IRQ_HANDLED; -+ ret = true; - } - } -+ /* did not cause wake on resume context for shared IRQ */ -+ if (irq < 0) -+ return false; - - /* Signal EOI to the GPIO unit */ - raw_spin_lock_irqsave(&gpio_dev->lock, flags); -@@ -588,6 +599,16 @@ static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id) - return ret; - } - -+static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id) -+{ -+ return IRQ_RETVAL(do_amd_gpio_irq_handler(irq, dev_id)); -+} -+ -+static bool __maybe_unused amd_gpio_check_wake(void *dev_id) -+{ -+ return do_amd_gpio_irq_handler(-1, dev_id); -+} -+ - static int amd_get_groups_count(struct pinctrl_dev *pctldev) - { - struct amd_gpio *gpio_dev = pinctrl_dev_get_drvdata(pctldev); -@@ -958,6 +979,7 @@ static int amd_gpio_probe(struct platform_device *pdev) - goto out2; - - platform_set_drvdata(pdev, gpio_dev); -+ acpi_register_wakeup_handler(gpio_dev->irq, amd_gpio_check_wake, gpio_dev); - - dev_dbg(&pdev->dev, "amd gpio driver loaded\n"); - return ret; -@@ -975,6 +997,7 @@ static int amd_gpio_remove(struct platform_device *pdev) - gpio_dev = platform_get_drvdata(pdev); - - gpiochip_remove(&gpio_dev->gc); -+ acpi_unregister_wakeup_handler(amd_gpio_check_wake, gpio_dev); - - return 0; - } --- -2.33.0 - diff --git a/queue-5.10/rt2x00-do-not-mark-device-gone-on-eproto-errors-during-start.patch b/queue-5.10/rt2x00-do-not-mark-device-gone-on-eproto-errors-during-start.patch new file mode 100644 index 00000000000..bef0227ce6a --- /dev/null +++ b/queue-5.10/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.10/s390-pci-move-pseudo-mmio-to-prevent-mio-overlap.patch b/queue-5.10/s390-pci-move-pseudo-mmio-to-prevent-mio-overlap.patch new file mode 100644 index 00000000000..9c69d465622 --- /dev/null +++ b/queue-5.10/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.10/sata_fsl-fix-uaf-in-sata_fsl_port_stop-when-rmmod-sata_fsl.patch b/queue-5.10/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.10/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.10/sata_fsl-fix-warning-in-remove_proc_entry-when-rmmod-sata_fsl.patch b/queue-5.10/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.10/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.10/series b/queue-5.10/series index 4567bed9ec4..9511d475832 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -10,7 +10,6 @@ mac80211-do-not-access-the-iv-when-it-was-stripped.patch net-smc-transfer-remaining-wait-queue-entries-during.patch atlantic-fix-oob-read-and-write-in-hw_atl_utils_fw_r.patch net-return-correct-error-code.patch -pinctrl-amd-fix-wakeups-when-irq-is-shared-with-sci.patch platform-x86-thinkpad_acpi-add-support-for-dual-fan-.patch platform-x86-thinkpad_acpi-fix-wwan-device-disabled-.patch s390-setup-avoid-using-memblock_enforce_memory_limit.patch @@ -20,7 +19,6 @@ scsi-iscsi-unblock-session-then-wake-up-error-handle.patch drm-amd-amdkfd-fix-kernel-panic-when-reset-failed-an.patch drm-amd-amdgpu-fix-potential-memleak.patch ata-ahci-add-green-sardine-vendor-id-as-board_ahci_m.patch -ata-libahci-adjust-behavior-when-storaged3enable-_ds.patch ethernet-hisilicon-hns-hns_dsaf_misc-fix-a-possible-.patch ipv6-check-return-value-of-ipv6_skip_exthdr.patch net-tulip-de4x5-fix-the-problem-that-the-array-lp-ph.patch @@ -30,3 +28,12 @@ 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 acpi-add-stubs-for-wakeup-handler-functions.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 diff --git a/queue-5.10/vrf-reset-ipcb-ip6cb-when-processing-outbound-pkts-in-vrf-dev-xmit.patch b/queue-5.10/vrf-reset-ipcb-ip6cb-when-processing-outbound-pkts-in-vrf-dev-xmit.patch new file mode 100644 index 00000000000..2317833a4a3 --- /dev/null +++ b/queue-5.10/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