linux-kernel - Re: [REGRESSION] Re: i915 driver crashes on T540p if docking station attached

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+55aFzsVMMpSeF3fG0FJ4Lhj1Tb6MY9LMfnmj7u1JyzM9aQuA@mail.gmail.com>
Date:	Wed, 29 Jul 2015 22:18:16 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Theodore Ts'o" <tytso@....edu>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	DRI <dri-devel@...ts.freedesktop.org>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Mani Nikula <jani.nikula@...ux.intel.com>,
	Ander Conselvan de Oliveira 
	<ander.conselvan.de.oliveira@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [REGRESSION] Re: i915 driver crashes on T540p if docking station attached

On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o <tytso@....edu> wrote:
>
> It's here:  https://goo.gl/photos/xHjn2Z97JQEw6k2C9

You didn't catch enough of the code line to decode the code, but it's
early enough in drm_crtc_index() (just five bytes in) that it's almost
certainly the very first dereference, so it's almost guaranteed to be
that

   crtc->dev

access as part of list_for_each_entry(), with crtc being NULL. And
yes, "->dev" is the very first field, so the offset is zero too (while
the "->mode_config" list access would not be at offset zero).

And it looks like it is called from drm_atomic_helper_check_modeset():
the reason it has a question mark in the backtrace is because the
fault happens before the stack frame has even been set up.

There are multiple calls to "drm_crtc_index()" from that function, I
can't tell which one it is. Looking at the code generation I get, I
think it's because update_connector_routing() gets inlined, and that
one does several calls. Most of them look like this:

                if (connector->state->crtc) {
                        idx = drm_crtc_index(connector->state->crtc);

ie they check that the crtc is non-NULL, but that last one does not:

        connector_state->best_encoder = new_encoder;
        idx = drm_crtc_index(connector_state->crtc);

        crtc_state = state->crtc_states[idx];
        crtc_state->mode_changed = true;

and I suspect the fix might be something like the attached. Totally
untested. Ted?

This whole "atomic modeset" series has been one royal fuck-up, guys.
We've had too many of these kinds of crap issues.

                           Linus

View attachment "patch.diff" of type "text/plain" (845 bytes)