From: Greg Kroah-Hartman Date: Thu, 10 Jul 2025 14:51:42 +0000 (+0200) Subject: 6.6-stable patches X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f42c9cb2360abb8f3719532aeccd705bd3f0734b;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches 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 --- 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 index 0000000000..6158cc2929 --- /dev/null +++ b/queue-6.6/drm-exynos-exynos7_drm_decon-add-vblank-check-in-irq-handling.patch @@ -0,0 +1,47 @@ +From b846350aa272de99bf6fecfa6b08e64ebfb13173 Mon Sep 17 00:00:00 2001 +From: Kaustabh Chakraborty +Date: Fri, 27 Jun 2025 00:50:30 +0530 +Subject: drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling + +From: Kaustabh Chakraborty + +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 +Signed-off-by: Inki Dae +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..3c76561bd3 --- /dev/null +++ b/queue-6.6/eventpoll-don-t-decrement-ep-refcount-while-still-holding-the-ep-mutex.patch @@ -0,0 +1,111 @@ +From 8c2e52ebbe885c7eeaabd3b7ddcdc1246fc400d2 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +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 + +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 +Link: https://docs.kernel.org/locking/mutex-design.html#semantics [1] +Cc: Alexander Viro +Cc: Christian Brauner +Cc: Jan Kara +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..616c514170 --- /dev/null +++ b/queue-6.6/series @@ -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