linux-kernel - Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150713062222.GG3736@phenom.ffwll.local>
Date:	Mon, 13 Jul 2015 08:22:22 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jörg Otte <jrg.otte@...il.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	David Airlie <airlied@...ux.ie>,
	DRI <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Subject: Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer
 dereference

On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote:
> On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <jrg.otte@...il.com> wrote:
> >
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
> > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb
> 
> Ugh. Please enable KALLSYMS to get sane symbols.
> 
> But yes, "crtc_state->base.active" is at offset 9 from "crtc_state",
> so it's pretty clearly just that change frm
> 
> -       if (intel_crtc->active) {
> +       if (crtc_state->base.active) {
> 
> and "crtc_state" is NULL.
> 
> And the code very much knows that crtc_state can be NULL, since it's
> initialized with
> 
>         crtc_state = state->base.state ?
>                 intel_atomic_get_crtc_state(state->base.state,
> intel_crtc) : NULL;
> 
> Tssk. Daniel? Should I just revert that commit dec4f799d0a4
> ("drm/i915: Use crtc_state->active in primary check_plane func") for
> now, or is there a better fix? Like just checking crtc_state for NULL?

Indeed embarrassing. I've missed that we still have 1 caller left that's
using the transitional helpers, and those don't fill out
plane_state->state backpointers to the global atomic update since there is
no global atomic update for transitional helpers. Below diff should fix
this - we need to preferentially check crts_state->active and if that's
not set intel_crtc->active should yield the right result for the one
remaining caller (it's in the crtc_disable paths).

For cheap excuses why i915 is so crap in 4.2: Thanks to a hipshot decision
to transition to a different QA team ("we'll do this in 1 week without
upfront planing") I essentially don't have proper QA support for 1-2
months by now. The other trouble in this area specifically is that this
code is already completely changed in -next again, so any testing done on
integration trees (like -next or drm-intel-nightly) won't test any patches
for 4.2.
-Daniel

Oh and Signed-off-by: Daniel Vetter <daniel.vetter@...el.com> in case you
decide to apply this right away.
---
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ba9321998a41..85ac6d85dc39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13276,7 +13276,7 @@ intel_check_primary_plane(struct drm_plane *plane,
 	if (ret)
 		return ret;
 
-	if (crtc_state->base.active) {
+	if (crtc_state ? crtc_state->base.active : intel_crtc->active) {
 		struct intel_plane_state *old_state =
 			to_intel_plane_state(plane->state);
 
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/