5.15-stable patches

added patches:
	filemap-avoid-truncating-64-bit-offset-to-32-bits.patch
	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.15/filemap-avoid-truncating-64-bit-offset-to-32-bits.patch b/queue-5.15/filemap-avoid-truncating-64-bit-offset-to-32-bits.patch
new file mode 100644 (file)
index 0000000..c3648cd
--- /dev/null
+++ b/queue-5.15/filemap-avoid-truncating-64-bit-offset-to-32-bits.patch
@@ -0,0 +1,35 @@
+From f505e6c91e7a22d10316665a86d79f84d9f0ba76 Mon Sep 17 00:00:00 2001
+From: Marco Nelissen <marco.nelissen@gmail.com>
+Date: Thu, 2 Jan 2025 11:04:11 -0800
+Subject: filemap: avoid truncating 64-bit offset to 32 bits
+
+From: Marco Nelissen <marco.nelissen@gmail.com>
+
+commit f505e6c91e7a22d10316665a86d79f84d9f0ba76 upstream.
+
+On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a
+64-bit value to 32 bits, leading to a possible infinite loop when writing
+to an xfs filesystem.
+
+Link: https://lkml.kernel.org/r/20250102190540.1356838-1-marco.nelissen@gmail.com
+Fixes: 54fa39ac2e00 ("iomap: use mapping_seek_hole_data")
+Signed-off-by: Marco Nelissen <marco.nelissen@gmail.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/filemap.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/filemap.c
++++ b/mm/filemap.c
+@@ -2818,7 +2818,7 @@ static inline loff_t page_seek_hole_data
+       do {
+               if (ops->is_partially_uptodate(page, offset, bsz) == seek_data)
+                       break;
+-              start = (start + bsz) & ~(bsz - 1);
++              start = (start + bsz) & ~((u64)bsz - 1);
+               offset += bsz;
+       } while (offset < thp_size(page));
+ unlock:

diff --git a/queue-5.15/fs-proc-fix-softlockup-in-__read_vmcore-part-2.patch b/queue-5.15/fs-proc-fix-softlockup-in-__read_vmcore-part-2.patch
new file mode 100644 (file)
index 0000000..b05e48e
--- /dev/null
+++ b/queue-5.15/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.15/gpiolib-cdev-fix-use-after-free-in-lineinfo_changed_notify.patch b/queue-5.15/gpiolib-cdev-fix-use-after-free-in-lineinfo_changed_notify.patch
new file mode 100644 (file)
index 0000000..0142e1b
--- /dev/null
+++ b/queue-5.15/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
+@@ -2506,9 +2506,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.15/series b/queue-5.15/series
index 24da8e140993cd8443b1f9c74212a53eedc205fe..4f140fc3b9f9615b53044ac6a9518cac0b1d8b75 100644 (file)
--- a/queue-5.15/series
+++ b/queue-5.15/series
@@ -106,3 +106,6 @@ 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
 vsock-prevent-null-ptr-deref-in-vsock_.patch
+filemap-avoid-truncating-64-bit-offset-to-32-bits.patch
+fs-proc-fix-softlockup-in-__read_vmcore-part-2.patch
+gpiolib-cdev-fix-use-after-free-in-lineinfo_changed_notify.patch