]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
6.6-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 10 Jul 2025 14:51:42 +0000 (16:51 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 10 Jul 2025 14:55:58 +0000 (16:55 +0200)
added patches:
drm-exynos-exynos7_drm_decon-add-vblank-check-in-irq-handling.patch
eventpoll-don-t-decrement-ep-refcount-while-still-holding-the-ep-mutex.patch
series

queue-6.6/drm-exynos-exynos7_drm_decon-add-vblank-check-in-irq-handling.patch [new file with mode: 0644]
queue-6.6/eventpoll-don-t-decrement-ep-refcount-while-still-holding-the-ep-mutex.patch [new file with mode: 0644]
queue-6.6/series [new file with mode: 0644]

diff --git a/queue-6.6/drm-exynos-exynos7_drm_decon-add-vblank-check-in-irq-handling.patch b/queue-6.6/drm-exynos-exynos7_drm_decon-add-vblank-check-in-irq-handling.patch
new file mode 100644 (file)
index 0000000..6158cc2
--- /dev/null
@@ -0,0 +1,47 @@
+From b846350aa272de99bf6fecfa6b08e64ebfb13173 Mon Sep 17 00:00:00 2001
+From: Kaustabh Chakraborty <kauschluss@disroot.org>
+Date: Fri, 27 Jun 2025 00:50:30 +0530
+Subject: drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling
+
+From: Kaustabh Chakraborty <kauschluss@disroot.org>
+
+commit b846350aa272de99bf6fecfa6b08e64ebfb13173 upstream.
+
+If there's support for another console device (such as a TTY serial),
+the kernel occasionally panics during boot. The panic message and a
+relevant snippet of the call stack is as follows:
+
+  Unable to handle kernel NULL pointer dereference at virtual address 000000000000000
+  Call trace:
+    drm_crtc_handle_vblank+0x10/0x30 (P)
+    decon_irq_handler+0x88/0xb4
+    [...]
+
+Otherwise, the panics don't happen. This indicates that it's some sort
+of race condition.
+
+Add a check to validate if the drm device can handle vblanks before
+calling drm_crtc_handle_vblank() to avoid this.
+
+Cc: stable@vger.kernel.org
+Fixes: 96976c3d9aff ("drm/exynos: Add DECON driver")
+Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
+Signed-off-by: Inki Dae <inki.dae@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/exynos/exynos7_drm_decon.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
++++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+@@ -601,6 +601,10 @@ static irqreturn_t decon_irq_handler(int
+       if (!ctx->drm_dev)
+               goto out;
++      /* check if crtc and vblank have been initialized properly */
++      if (!drm_dev_has_vblank(ctx->drm_dev))
++              goto out;
++
+       if (!ctx->i80_if) {
+               drm_crtc_handle_vblank(&ctx->crtc->base);
diff --git a/queue-6.6/eventpoll-don-t-decrement-ep-refcount-while-still-holding-the-ep-mutex.patch b/queue-6.6/eventpoll-don-t-decrement-ep-refcount-while-still-holding-the-ep-mutex.patch
new file mode 100644 (file)
index 0000000..3c76561
--- /dev/null
@@ -0,0 +1,111 @@
+From 8c2e52ebbe885c7eeaabd3b7ddcdc1246fc400d2 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Wed, 9 Jul 2025 10:38:29 -0700
+Subject: eventpoll: don't decrement ep refcount while still holding the ep mutex
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 8c2e52ebbe885c7eeaabd3b7ddcdc1246fc400d2 upstream.
+
+Jann Horn points out that epoll is decrementing the ep refcount and then
+doing a
+
+    mutex_unlock(&ep->mtx);
+
+afterwards. That's very wrong, because it can lead to a use-after-free.
+
+That pattern is actually fine for the very last reference, because the
+code in question will delay the actual call to "ep_free(ep)" until after
+it has unlocked the mutex.
+
+But it's wrong for the much subtler "next to last" case when somebody
+*else* may also be dropping their reference and free the ep while we're
+still using the mutex.
+
+Note that this is true even if that other user is also using the same ep
+mutex: mutexes, unlike spinlocks, can not be used for object ownership,
+even if they guarantee mutual exclusion.
+
+A mutex "unlock" operation is not atomic, and as one user is still
+accessing the mutex as part of unlocking it, another user can come in
+and get the now released mutex and free the data structure while the
+first user is still cleaning up.
+
+See our mutex documentation in Documentation/locking/mutex-design.rst,
+in particular the section [1] about semantics:
+
+       "mutex_unlock() may access the mutex structure even after it has
+        internally released the lock already - so it's not safe for
+        another context to acquire the mutex and assume that the
+        mutex_unlock() context is not using the structure anymore"
+
+So if we drop our ep ref before the mutex unlock, but we weren't the
+last one, we may then unlock the mutex, another user comes in, drops
+_their_ reference and releases the 'ep' as it now has no users - all
+while the mutex_unlock() is still accessing it.
+
+Fix this by simply moving the ep refcount dropping to outside the mutex:
+the refcount itself is atomic, and doesn't need mutex protection (that's
+the whole _point_ of refcounts: unlike mutexes, they are inherently
+about object lifetimes).
+
+Reported-by: Jann Horn <jannh@google.com>
+Link: https://docs.kernel.org/locking/mutex-design.html#semantics [1]
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Jan Kara <jack@suse.cz>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/eventpoll.c |   12 +++++-------
+ 1 file changed, 5 insertions(+), 7 deletions(-)
+
+--- a/fs/eventpoll.c
++++ b/fs/eventpoll.c
+@@ -772,7 +772,7 @@ static bool __ep_remove(struct eventpoll
+       call_rcu(&epi->rcu, epi_rcu_free);
+       percpu_counter_dec(&ep->user->epoll_watches);
+-      return ep_refcount_dec_and_test(ep);
++      return true;
+ }
+ /*
+@@ -780,14 +780,14 @@ static bool __ep_remove(struct eventpoll
+  */
+ static void ep_remove_safe(struct eventpoll *ep, struct epitem *epi)
+ {
+-      WARN_ON_ONCE(__ep_remove(ep, epi, false));
++      if (__ep_remove(ep, epi, false))
++              WARN_ON_ONCE(ep_refcount_dec_and_test(ep));
+ }
+ static void ep_clear_and_put(struct eventpoll *ep)
+ {
+       struct rb_node *rbp, *next;
+       struct epitem *epi;
+-      bool dispose;
+       /* We need to release all tasks waiting for these file */
+       if (waitqueue_active(&ep->poll_wait))
+@@ -820,10 +820,8 @@ static void ep_clear_and_put(struct even
+               cond_resched();
+       }
+-      dispose = ep_refcount_dec_and_test(ep);
+       mutex_unlock(&ep->mtx);
+-
+-      if (dispose)
++      if (ep_refcount_dec_and_test(ep))
+               ep_free(ep);
+ }
+@@ -1003,7 +1001,7 @@ again:
+               dispose = __ep_remove(ep, epi, true);
+               mutex_unlock(&ep->mtx);
+-              if (dispose)
++              if (dispose && ep_refcount_dec_and_test(ep))
+                       ep_free(ep);
+               goto again;
+       }
diff --git a/queue-6.6/series b/queue-6.6/series
new file mode 100644 (file)
index 0000000..616c514
--- /dev/null
@@ -0,0 +1,2 @@
+eventpoll-don-t-decrement-ep-refcount-while-still-holding-the-ep-mutex.patch
+drm-exynos-exynos7_drm_decon-add-vblank-check-in-irq-handling.patch