--- /dev/null
+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);
+
--- /dev/null
+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;
+ }