5.10-stable patches

added patches:
	fs-proc-fix-softlockup-in-__read_vmcore-part-2.patch
	gpiolib-cdev-fix-use-after-free-in-lineinfo_changed_notify.patch

diff --git a/queue-5.10/fs-proc-fix-softlockup-in-__read_vmcore-part-2.patch b/queue-5.10/fs-proc-fix-softlockup-in-__read_vmcore-part-2.patch
new file mode 100644 (file)
index 0000000..b05e48e
--- /dev/null
+++ b/queue-5.10/fs-proc-fix-softlockup-in-__read_vmcore-part-2.patch
@@ -0,0 +1,49 @@
+From cbc5dde0a461240046e8a41c43d7c3b76d5db952 Mon Sep 17 00:00:00 2001
+From: Rik van Riel <riel@surriel.com>
+Date: Fri, 10 Jan 2025 10:28:21 -0500
+Subject: fs/proc: fix softlockup in __read_vmcore (part 2)
+
+From: Rik van Riel <riel@surriel.com>
+
+commit cbc5dde0a461240046e8a41c43d7c3b76d5db952 upstream.
+
+Since commit 5cbcb62dddf5 ("fs/proc: fix softlockup in __read_vmcore") the
+number of softlockups in __read_vmcore at kdump time have gone down, but
+they still happen sometimes.
+
+In a memory constrained environment like the kdump image, a softlockup is
+not just a harmless message, but it can interfere with things like RCU
+freeing memory, causing the crashdump to get stuck.
+
+The second loop in __read_vmcore has a lot more opportunities for natural
+sleep points, like scheduling out while waiting for a data write to
+happen, but apparently that is not always enough.
+
+Add a cond_resched() to the second loop in __read_vmcore to (hopefully)
+get rid of the softlockups.
+
+Link: https://lkml.kernel.org/r/20250110102821.2a37581b@fangorn
+Fixes: 5cbcb62dddf5 ("fs/proc: fix softlockup in __read_vmcore")
+Signed-off-by: Rik van Riel <riel@surriel.com>
+Reported-by: Breno Leitao <leitao@debian.org>
+Cc: Baoquan He <bhe@redhat.com>
+Cc: Dave Young <dyoung@redhat.com>
+Cc: Vivek Goyal <vgoyal@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/proc/vmcore.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/proc/vmcore.c
++++ b/fs/proc/vmcore.c
+@@ -396,6 +396,8 @@ static ssize_t __read_vmcore(char *buffe
+                       if (buflen == 0)
+                               return acc;
+               }
++
++              cond_resched();
+       }
+ 
+       return acc;

diff --git a/queue-5.10/gpiolib-cdev-fix-use-after-free-in-lineinfo_changed_notify.patch b/queue-5.10/gpiolib-cdev-fix-use-after-free-in-lineinfo_changed_notify.patch
new file mode 100644 (file)
index 0000000..1801f8f
--- /dev/null
+++ b/queue-5.10/gpiolib-cdev-fix-use-after-free-in-lineinfo_changed_notify.patch
@@ -0,0 +1,72 @@
+From 02f6b0e1ec7e0e7d059dddc893645816552039da Mon Sep 17 00:00:00 2001
+From: Zhongqiu Han <quic_zhonhan@quicinc.com>
+Date: Sun, 5 May 2024 22:11:56 +0800
+Subject: gpiolib: cdev: Fix use after free in lineinfo_changed_notify
+
+From: Zhongqiu Han <quic_zhonhan@quicinc.com>
+
+commit 02f6b0e1ec7e0e7d059dddc893645816552039da upstream.
+
+The use-after-free issue occurs as follows: when the GPIO chip device file
+is being closed by invoking gpio_chrdev_release(), watched_lines is freed
+by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
+chain failed due to waiting write rwsem. Additionally, one of the GPIO
+chip's lines is also in the release process and holds the notifier chain's
+read rwsem. Consequently, a race condition leads to the use-after-free of
+watched_lines.
+
+Here is the typical stack when issue happened:
+
+[free]
+gpio_chrdev_release()
+  --> bitmap_free(cdev->watched_lines)                  <-- freed
+  --> blocking_notifier_chain_unregister()
+    --> down_write(&nh->rwsem)                          <-- waiting rwsem
+          --> __down_write_common()
+            --> rwsem_down_write_slowpath()
+                  --> schedule_preempt_disabled()
+                    --> schedule()
+
+[use]
+st54spi_gpio_dev_release()
+  --> gpio_free()
+    --> gpiod_free()
+      --> gpiod_free_commit()
+        --> gpiod_line_state_notify()
+          --> blocking_notifier_call_chain()
+            --> down_read(&nh->rwsem);                  <-- held rwsem
+            --> notifier_call_chain()
+              --> lineinfo_changed_notify()
+                --> test_bit(xxxx, cdev->watched_lines) <-- use after free
+
+The side effect of the use-after-free issue is that a GPIO line event is
+being generated for userspace where it shouldn't. However, since the chrdev
+is being closed, userspace won't have the chance to read that event anyway.
+
+To fix the issue, call the bitmap_free() function after the unregistration
+of lineinfo_changed_nb notifier chain.
+
+Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info")
+Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
+Link: https://lore.kernel.org/r/20240505141156.2944912-1-quic_zhonhan@quicinc.com
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Bruno VERNAY <bruno.vernay@se.com>
+Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpiolib-cdev.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpio/gpiolib-cdev.c
++++ b/drivers/gpio/gpiolib-cdev.c
+@@ -2352,9 +2352,9 @@ static int gpio_chrdev_release(struct in
+       struct gpio_chardev_data *cdev = file->private_data;
+       struct gpio_device *gdev = cdev->gdev;
+ 
+-      bitmap_free(cdev->watched_lines);
+       blocking_notifier_chain_unregister(&gdev->notifier,
+                                          &cdev->lineinfo_changed_nb);
++      bitmap_free(cdev->watched_lines);
+       put_device(&gdev->dev);
+       kfree(cdev);
+ 

diff --git a/queue-5.10/series b/queue-5.10/series
index 5cc376f684a2299e2a85c864c41e6c8919ceea13..e8071bfa3d1e78ecb8988579e2a8b5d4dc76011b 100644 (file)
--- a/queue-5.10/series
+++ b/queue-5.10/series
@@ -104,3 +104,5 @@ x86-asm-make-serialize-always_inline.patch
 net-ethernet-xgbe-re-add-aneg-to-supported-features-in-phy-quirks.patch
 vsock-virtio-cancel-close-work-in-the-destructor.patch
 vsock-reset-socket-state-when-de-assigning-the-transport.patch
+fs-proc-fix-softlockup-in-__read_vmcore-part-2.patch
+gpiolib-cdev-fix-use-after-free-in-lineinfo_changed_notify.patch